Does NV40 support programmable AA patterns?

[Luminescent]

I didn't read anything about programmable AA patterns, such as on R3x0. Anyone with additional information?

 

[Arun]

Considering the simplicity of their 4x RGMSAA sample patterns (0.125 precision), I'd be greatly surprised if it was programmable.

Uttar

 

[DemoCoder]

I think not.

 

[KimB]

Programmable sample patterns would be somewhat pointless without greater than 4x multisampling.

 

[MrGaribaldi]

Programmable sample patterns would be somewhat pointless without greater than 4x multisampling.

I thought Dave B made a very good case here for why it would've made sense to have programmable patterns...

 

[ERP]

I wouldn't expect the sample patterns to be adaptive, but I'm basing this on how they used to do Z compresion. If it hasn't changed from NV20/30 adaptive patterns would make the Z compression a lot more complex or a lot less effective.

 

[KimB]

Programmable sample patterns would be somewhat pointless without greater than 4x multisampling.

I thought Dave B made a very good case here for why it would've made sense to have programmable patterns...

That only states that there is no per-pixel programmable pattern. It doesn't rule out the possibility of a global sample pattern being definable by the drivers (as is apparently the case with the R3xx).

But, still, without higher than 4x multisampling, there really wouldn't be much reason to go for a programmable pattern. That is, unless one could devise a 4x MS/2x SS mode that would give decent edge quality by selecting a clever 4x pattern.

 

[MrGaribaldi]

Programmable sample patterns would be somewhat pointless without greater than 4x multisampling.

I thought Dave B made a very good case here for why it would've made sense to have programmable patterns...

That only states that there is no per-pixel programmable pattern. It doesn't rule out the possibility of a global sample pattern being definable by the drivers (as is apparently the case with the R3xx).

But if that was the case, would it not then be possible to do what you outline below? Unless of course you can only choose from a list of predefined patterns...

But, still, without higher than 4x multisampling, there really wouldn't be much reason to go for a programmable pattern. That is, unless one could devise a 4x MS/2x SS mode that would give decent edge quality by selecting a clever 4x pattern.

And I still think that since there are (legal, good) optimisations which could be done, if it had that support, is good enough reason for it to have it.

 

[KimB]

I think ERP had the best argument: a general pattern might break compression. On the other hand, if it is capable of doing what I outlined, then it could just be that it is not yet exposed in the drivers. Don't hold your breath, though. I expect the sample pattern is not programmable.

 

[Simon F]

I'd say the reason is because a programmable pattern is a lot more expensive to implement.

Anyway, if an application coder really wanted to do an arbitrary pattern, (s)he could use an accumulation buffer approach.

 

[Luminescent]

I have not yet understood why Nvidia limited its RGMSAA to 4x. Dave wrote the following with respect to this in his B3D Geforce 6800 preview:

Unlike ATI, only one loop is therefore allowed through the ROP which continues to restrict NV4x to a native Multi-Sample AA of 4X – modes greater than 4X still require combined Super-Sampling and Multi-Sampling.

Can anyone guess why it wouldn't be able to loop 3 times for six subsamples, like Ati? Would it be a driver or hardware restriction?

 

[KimB]

Can anyone guess why it wouldn't be able to loop 3 times for six subsamples, like Ati? Would it be a driver or hardware restriction?

The nVidia implementation doesn't loop at all, and so only supports as many subsamples per pixel as it supports z-tests per pixel, as far as I know.

So adding looping to the multisampling algorithm would certainly allow higher-sample MSAA, but it may not be easy to do without fully-programmable sample patterns.