Anti-Aliasing... so far

[Jawed]

tED found this super patent application:

http://v3.espacenet.com/textdes?DB=EPODOC&IDX=US2005179700&F=0&QPN=US2005179700

Which keeps only the "most relevant" AA samples for a pixel.

This allows the GPU to use more sample positions per pixel, whilst effectively limiting the number of triangles multi-sampled within a single pixel.

An upper limit of, say, four triangles within a pixel, but 8 sample positions should look really tasty.

I wrote at length about it:

http://www.beyond3d.com/forum/showpost.php?p=562592&postcount=1425

etc. in that thread.

Jawed

 

[Dave Baumann]

Wouldn't framebuffer compression more or less screw up that regularity?

No. colour/Z compression only compresses for bandwidth purposes, not for size - the "pixels" are still in the same location in memory as they would have been if they are uncompressed.

 

[Ailuros]

I was asking Eric Demers about AA over the Ibiza weekend and just mentioning how it appears to have stagnated - there's been very little advancement on it since MSAA was introduced. He made the point that MSAA is very predicable and most other schemes, certainly ones that store different numbers of samples dependant on the requirements of a pixel, just trash the memory and screws up the access patterns - the point about MSAA is that you know what its going to do to the memory and performance can be built around that.

On the flipside of things sample densities haven't increased in the past few years most likely because framebuffer and bandwidth consumption are as predictable with MSAA. What I still fail to understand is how a R520 with an a lot smaller performance drop than former product families with 6xAA (and a lot more bandwidth) wasn't set to reach 8x sparse MSAA.

 

[arjan de lumens]

No. colour/Z compression only compresses for bandwidth purposes, not for size - the "pixels" are still in the same location in memory as they would have been if they are uncompressed.

But surely their representation in memory must be rather different than without compression, or else there would be no way for the memory controller to cut bandwidth in the first place? I would guess that the compression scheme would work on blocks of pixels, with each whole block (rather than each pixel) having its memory location unchanged?

 

[Simon F]

I would guess that the compression scheme would work on blocks of pixels, with each whole block (rather than each pixel) having its memory location unchanged?

Blocks of pixels.

 

[Jawed]

What I still fail to understand is how a R520 with an a lot smaller performance drop than former product families with 6xAA (and a lot more bandwidth) wasn't set to reach 8x sparse MSAA.

Particularly in light of the patent application I linked

Ah well, maybe R600.

Jawed

 

[Ailuros]

Particularly in light of the patent application I linked

Ah well, maybe R600.

Jawed

Research takes time. It's about enough for an excellent seeming idea to fail in one case to require even more research. Doesn't have to be connected to that one necessarily.

 

[Geo]

Why hasn't someone picked up Matrox FAA and combined it with other techniques? Maybe now that we've got both NV and ATI doing AAA "in spots" there will be a little more willingness to try those kind of things (i.e. mixing in different parts of the scene?).

 

[arjan de lumens]

The patent Jawed linked to looks like yet another MSAA-with-lossy-compression scheme. Given that an ordinary polygon mesh will frequently contain vertices with more than 4 polygons attached to then (*average* is about 6 for triangular meshes), you will actually rather frequently need to reject or combine 'unimportant' polygons for some pixels. Intuitively, I would expect that this scheme would cause 1-pixel rendering errors near such vertices if you do 2-pass rendering (that is, submitting the same geometry twice, only with different textures/colors/shaders) or at random locations if you supply multiple layers of transparent high-poly meshes on top of each other. PROVING that algorithms like this doesn't produce such errors is surprisingly hard, and if you don't work out all such proofs at hardware design time, you don't really have the right to be surprised when the silicon comes back from the fab and Doom3 is a horrible sparklefest.

 

[Ailuros]

Why hasn't someone picked up Matrox FAA and combined it with other techniques? Maybe now that we've got both NV and ATI doing AAA "in spots" there will be a little more willingness to try those kind of things (i.e. mixing in different parts of the scene?).

I don't think it's all that simple; FAA couldn't anti-alias polygon intersections and had some trouble with stenciling (no idea if they've fixed any of it in the meantime). Plus that it had only a 4*4 EER.

If there would be a chance to see higher sample densities in the future with whatever method, I'd rather prefer to see for N amount of samples N*N grids.

Personally I'd prefer if IHVs (or ISVs) would concentrate more on texture and/or shader aliasing; side-effects there are far more annoying than polygon edge/intersection aliasing.

 

[Jawed]

The patent Jawed linked to looks like yet another MSAA-with-lossy-compression scheme. Given that an ordinary polygon mesh will frequently contain vertices with more than 4 polygons attached to then (*average* is about 6 for triangular meshes), you will actually rather frequently need to reject or combine 'unimportant' polygons for some pixels.

Ah, but the point with the patent is that with current 4xMSAA, the maximum number of triangles that can be sampled in a single pixel is 4.

So we are already living with this "problem".

With current 6xMSAA, obviously there's support for upto 6 triangles meeting in a single pixel.

At some point the number of triangles becomes so intense that neighbouring-pixel anti-aliasing (e.g. for the eight pixels that surround the single pixel where the triangles all meet) becomes more important than the centre-pixel's own AA quality.

I don't know what the point of diminishing returns is. The patent application bases its examples on 4 triangles, but...

Jawed

 

[Jawed]

Personally I'd prefer if IHVs (or ISVs) would concentrate more on texture and/or shader aliasing; side-effects there are far more annoying than polygon edge/intersection aliasing.

Pages 22-28, and 35-38

http://www.ati.com/developer/gdc/D3DTutorial01_3_0_Shaders.pdf

It's happening. This is stuff that's running in the Toyshop demo.

Jawed

 

[arjan de lumens]

Ah, but the point with the patent is that with current 4xMSAA, the maximum number of triangles that can be sampled in a single pixel is 4.

So we are already living with this "problem".

And MY point is that the combination or rejection algorithm that limits the number of polygons sampled in the pixel to less than the number of sample locations in the pixel is likely to cause actual rendering errors (not just reduced AA quality, but rendering that looks directly wrong).

E.g. if you combine the Z values of two samples into one, then run a second pass of 2-pass rendering with the Z-compare function set to EQUAL (this is quite common) then the Z-compare will unexpectedly fail for one of the samples, causing a 1-sample glitch (which is likely to be very visible) - this glitch wouldn't be there with 'ordinary' Multisampling.

 

[Jawed]

E.g. if you combine the Z values of two samples into one,

I don't think the patent does that. It discards triangles that have "only 1 sample" if a new triangle appears with 2 samples. It has nothing to do with whether the new triangle's samples coincide with the now-discarded triangle's sample.

But it's absolutely ages since I read the patent closely and I've been caught out before by not having any understanding of Z-compare mode, so I'm not going to argue this point with you!

In summary, the patent doesn't "share" samples between multiple triangles, it discards triangles' samples on the basis of those having the least impact on the finally resolved pixel (in terms of total samples covered by that triangle).

Jawed

 

[arjan de lumens]

Hmmmph. If it (for the pixel) just plain discards a polygon that actually owns a sample, then it would actually need to pick data for the sample from one of the other polygons that cover the pixel. When you do that, the invariances needed to make 2-pass rendering work will break down and you get rendering errors.

 

[Jawed]

I think you're getting way too nit-picky.

For example, if you compare 4X rotated grid sample positions with ATI's 4x sparse sample positions you can see, quite trivially, how four triangles meeting in a single pixel will be rendered differently by the two algorithms - depending on the precise angles involved.

Additionally it's not hard to draw up scenarios in which one of the four triangles doesn't cover any samples. In either sampling scheme.

Although, having said that in the end every sample should end up being covered, even if it's just "invalid". (Actually, in this case, the algorithm actually discards "invalid" samples entirely from the AA resolve - so if it's 8xMSAA, then the pixel is actually reduced to 7xMSAA if a single sample is set to "invalid".)

The fact is 4xMSAA is pretty coarse-grained, so there will be plenty of occasions when triangles get under-sampled or ignored at vertices. With movement, vertex under-sampling is just another factor in "AA crawl".

But as I said earlier, if there are peculiarities that arise from Z-compare then I'm way out of my depth, so erm...

Maybe some clever sausage will put together a nice little java applet to demonstrate this algorithm and compare it with conventional MSAA.

Jawed

 

[arjan de lumens]

I think you're getting way too nit-picky.

For example, if you compare 4X rotated grid sample positions with ATI's 4x sparse sample positions you can see, quite trivially, how four triangles meeting in a single pixel will be rendered differently by the two algorithms - depending on the precise angles involved.

That is not the problem I am griping about. The problem I am trying to highlight in your algorithm is not related to the number and placement of the sample points, it's a problem in the way it discards information.

If I feed in two polygons to the rasterizer (out from the vertex shader, into the same frame) with EXACT same XYZ coordinates, then I expect the two polygons to cover the EXACT same samples in the EXACT same pixels, and I expect the Z value for each sample to match EXACTLY what happens to be in the Z buffer. This is an absolute correctness requirement that is absolutely necessary for a large number of games, including Doom3, to work correctly - game developers have been relying on this particular invariance for a decade or so to do multi-pass rendering. The exact pattern of samples that is covered by the polygons, and the exact values stored in the Z buffer, are not terribly important - they just have to match exactly. If you fail this correctness requirement you will get pixel popping rendering errors in the interior of your models, not just microscopic off-by-1-sample errors along the model's silhouette - in Doom3 this would probably be a small number of gray, sparkling pixels on a monster otherwise hidden in the shadow.

 

[Xmas]

Akenine-Moller and Ström did some interesting work on combining samples and filters
http://www.cs.lth.se/home/Tomas_Akenine_Moller/pubs/flipquad_tr.pdf
and
http://www.cs.lth.se/home/Tomas_Akenine_Moller/pubs/fliptri_tr.pdf

Somewhat better than quincunx and quite inexpensive, but nothing that I'd like to see replace ordinary multisampling. And choosing which colors to use for which samples can be a bit tricky.



Arjan, as far as I understand the patent, the samples of multiple passes will exactly match - or be discarded for every pass.

 

[Simon F]

Somewhat better than quincunx and quite inexpensive, but nothing that I'd like to see replace ordinary multisampling. And choosing which colors to use for which samples can be a bit tricky.

Well, I'll explain another alternative to you in person sometime later, if you like

 

[Jawed]

I can only suggest you read the patent - it's not very long or difficult. The worked examples seem pretty easy to follow.

While I understand the basics (erm... ), I'll happily admit that I don't know enough about this topic to be able to give you a complete answer as to how the proposed method avoids the problem you're describing.

Jawed