"Coverage Sampling Anti-Aliasing Explained"

[Simon]

Guten Morgen,

gerade bei Nvidia gefunden, vielleicht interessiert es ja wen: Coverage Sampling Anti-Aliasing Explained (http://developer.nvidia.com/object/coverage-sampled-aa.html)

[Wuge]

Danke für den Link!

[Chris Lux]

ok, viel erklärt ist da ja nicht ;)
deshalb jetzt folgende fragen.

wie werden die beiden teile (multisample anteil und coverage anteil) verrechnet zum endgültigen sample? angenommen wir haben 4xmultisampling und 16xcovergesampling. als ergebnis bekommen wir eben 4 color sample und einen coverage anteil von 0.3125 (5 von 16 samples liegen in in der aktuellen primitive), wie kommen wir zu endergebnis? oder wird der coverage anteil für jedes color sample ermittelt?

thx

[Gast]

Soweit ich weiß, wird die Coverage nur binär gespeichert.

[Gast]

wie werden die beiden teile (multisample anteil und coverage anteil) verrechnet zum endgültigen sample? angenommen wir haben 4xmultisampling und 16xcovergesampling. als ergebnis bekommen wir eben 4 color sample und einen coverage anteil von 0.3125 (5 von 16 samples liegen in in der aktuellen primitive), wie kommen wir zu endergebnis? oder wird der coverage anteil für jedes color sample ermittelt?



meine vermutung wäre folgende:

es wird quasi ein "normaler" Z/Color-buffer (in der auflösung des MSAA-anteils) gespeichert, wobei die farb/z-werte allerdings keine direkte zuordnung zu ihrer position im pixel haben.

zusätzlich wird die coverage-maske gespeichert, wobei jedes C-Sample auf auf eine der color/z-informationen für den pixel zeigt.
dadurch wird zustätzlich zum multisample-buffer nur 2 bzw. 3bit für jedes coverage-sample gebraucht (je nach dem ob 4x oder 8x MSAA die basis ist)

mangels näherer informationen ist das natürlich nur eine der möglichen spekulationen.

[Spasstiger]

meine vermutung wäre folgende:

[...]

mangels näherer informationen ist das natürlich nur eine der möglichen spekulationen.
Klingt für mich aber plausibel. Aths weiß ja leider auch nix Genaues, zumal er sich nicht sonderlich für CSAA interessiert.

[ScottManDeath]

meine vermutung wäre folgende:

es wird quasi ein "normaler" Z/Color-buffer (in der auflösung des MSAA-anteils) gespeichert, wobei die farb/z-werte allerdings keine direkte zuordnung zu ihrer position im pixel haben.

zusätzlich wird die coverage-maske gespeichert, wobei jedes C-Sample auf auf eine der color/z-informationen für den pixel zeigt.
dadurch wird zustätzlich zum multisample-buffer nur 2 bzw. 3bit für jedes coverage-sample gebraucht (je nach dem ob 4x oder 8x MSAA die basis ist)

mangels näherer informationen ist das natürlich nur eine der möglichen spekulationen.

Hört sich plausibel an

[Spasstiger]

Ich hab mal das Bild mit den CSAA-Samples genommen und die MSAA-Samplepositionen (von 8xQ) drübergelegt:
http://img157.imageshack.us/img157/9774/16xqcsaary2.png

Römische Zahlen (I bis VIII) = MSAA-Sample-Positionen (also color/z)
Hex-Zahlen (1 bis F) = Coverage-Sample-Positionen

[Gast]

Laut Beyond3d.com hat 16xQCSAA nur 8 zusätzliche Coverage - Samples.

[Spasstiger]

Laut Beyond3d.com hat 16xQCSAA nur 8 zusätzliche Coverage - Samples.
Hm, ich hab halt einfach die MSAA-Samples von 8xQ-MSAA drübergelegt. Sind die MSAA-Sample-Positionen bei 16xQ-AA wirklich anders?

[Gast]

Hm, ich hab halt einfach die MSAA-Samples von 8xQ-MSAA drübergelegt. Sind die MSAA-Sample-Positionen bei 16xQ-AA wirklich anders?

Siehe hier: http://www.beyond3d.com/reviews/nvidia/g80-iq/index.php?p=02

[Spasstiger]

Siehe hier: http://www.beyond3d.com/reviews/nvidia/g80-iq/index.php?p=02
Ok, die MSAA-Samples liegen bei 16xQ wirklich anders als bei 8xQ. Thx für den Link generell btw., der passt doch auch gut in den Thread hier.
Interessanterweise stimmen die Samplepositionen bei Beyond3D auch nicht mit denen im Bild von Nvidia überein.

Jetzt würde mich auch mal konkret der Speicher- und Bandbreitenbedarf der CSAA-Modi interessieren.

Erstmal 16xQ-CSAA:
http://www.beyond3d.com/reviews/nvidia/g80-iq/images/aa/b3d/g80-16xQ.png
Die 8 color/z/coverage-Samples verbrauchen ja jeweils 32 Bit (kein HDR-Rendering). Dazu kommen 8 weitere coverage-Samples, die jeweils auf ein color/z-Sample zeigen, für die also jeweils 3 Bit gespeichert werden müssen. Außerdem muss irgendwie angezeigt werden, ob das coverage-Sample überhaupt auf ein color/z-Sample zeigen darf, ob es z.B. überhaupt auf einem Dreieck liegt. Ergo 4 Bit für die coverage-Samples.
Macht zusammen 8*32 Bit + 8*4 Bit = 288 Bit

Jetzt 16xCSAA:
http://www.beyond3d.com/reviews/nvidia/g80-iq/images/aa/b3d/g80-16x.png
Es sind 4 color/z/coverage-Samples mit 32 Bit und 12 zusätzliche coverage-samples, die jeweils einem von vier color/z-Samples zugeordnet sind. Ergo 2+1 Bit für die coverage-Samples.
Macht zusammen 4*32 Bit + 12*3 Bit = 164 Bit

Analog für 8xCSAA:
4*32 Bit + 4*3 Bit = 140 Bit

Das vollwertige 8xMSAA (8xQ) bräuchte 8*32 Bit = 256 Bit.

Stimmt ihr mir da zu?

[R300]

Mal ne Frage:
Ich kenne mich nicht so besonders gut in der Sub Pixel Verteilung vom AA aus aber kann es sein, dass die Verteilung bei nVidia in manchen Fällen unvorteilhaft ist?

Wenn ich z.B. Call of Duty 2 mit 16Q AA spiele wird alles ziemlich perfekt vom AA erfast bis auf die Wasserrinnen an den Häusern und die Kabel. Die Flimmern bei 16Q AA doch noch ziemlich stark in Bewegung.

Und wenn ich das von meiner alten Radeon 9700Pro noch halbwegs richtig in Erinnerung habe, war das AA irgendwie gleichmäßiger. Die Glättung allgemein kam zwar nicht an die des G80 ran, aber die Kabel und die Dachrinnen wurden von der Radeon genauso geglättet wie der Rest des Bildes.
Habe leider keine Screenshots vom AA meiner Radeon, aber meiner Meinung nach werden beim G80 halt die erwähnten Dachrinnen und die Leitungen schlechter geglättet als auf der alten Radeon, aber der Rest des Bildes deutlich besser. (16QAA vs 6AA, ich glaube 4AA war auch noch besser)

Hier mal 2 Screenshots mit 16Q TSAA:
http://www.r300.nggt.net/Bilder/16qtsaa.jpg
http://www.r300.nggt.net/Bilder/16qtsaa2.jpg

Kann mir jemand etwas dazu sagen?^^

[Gast]

Ok, die MSAA-Samples liegen bei 16xQ wirklich anders als bei 8xQ. Thx für den Link generell btw., der passt doch auch gut in den Thread hier.
Interessanterweise stimmen die Samplepositionen bei Beyond3D auch nicht mit denen im Bild von Nvidia überein.

Jetzt würde mich auch mal konkret der Speicher- und Bandbreitenbedarf der CSAA-Modi interessieren.

Erstmal 16xQ-CSAA:
http://www.beyond3d.com/reviews/nvidia/g80-iq/images/aa/b3d/g80-16xQ.png
Die 8 color/z/coverage-Samples verbrauchen ja jeweils 32 Bit (kein HDR-Rendering). Dazu kommen 8 weitere coverage-Samples, die jeweils auf ein color/z-Sample zeigen, für die also jeweils 3 Bit gespeichert werden müssen. Außerdem muss irgendwie angezeigt werden, ob das coverage-Sample überhaupt auf ein color/z-Sample zeigen darf, ob es z.B. überhaupt auf einem Dreieck liegt. Ergo 4 Bit für die coverage-Samples.
Macht zusammen 8*32 Bit + 8*4 Bit = 288 Bit

Jetzt 16xCSAA:
http://www.beyond3d.com/reviews/nvidia/g80-iq/images/aa/b3d/g80-16x.png
Es sind 4 color/z/coverage-Samples mit 32 Bit und 12 zusätzliche coverage-samples, die jeweils einem von vier color/z-Samples zugeordnet sind. Ergo 2+1 Bit für die coverage-Samples.
Macht zusammen 4*32 Bit + 12*3 Bit = 164 Bit

Analog für 8xCSAA:
4*32 Bit + 4*3 Bit = 140 Bit

Das vollwertige 8xMSAA (8xQ) bräuchte 8*32 Bit = 256 Bit.

Stimmt ihr mir da zu?


(http://www.3declipse.com):

8xQ ist 8xMSAA
16xQ ist 8xMSAA + 16xCSAA
16xAA ist 4xMSAA + 16xCSAA
8xAA ist 4xMSAA + 8CSAA

Hier noch als Bildchen: http://www.3declipse.com/images/stories/G80/AA/coveragesamplechart.png

[Spasstiger]

(http://www.3declipse.com):

8xQ ist 8xMSAA
16xQ ist 8xMSAA + 16xCSAA
16xAA ist 4xMSAA + 16xCSAA
8xAA ist 4xMSAA + 8CSAA

Hier noch als Bildchen:[...]
Was willst du mir damit jetzt sagen?
Jedes color/z-Sample wird auch als coverage-Sample genutzt.

[Gast]

Kann mir jemand etwas dazu sagen?^^

Gamma-Correction aktiviert?

[R300]

Ja, mit und ohne getestet...Ich sehe keinen Unterschied beim Gamma AA:|

[Spasstiger]

Deine Bilder sind ja leider stark artefaktbehaftet, aber nachdem was ich da sehe, ist die Kantenglättung an den Stromleitungen schon nahe am Optimum. Problem ist, dass die Leitung nur einen Pixel breit, der Winkel dazu recht ungünstig ist und der farbliche Kontrast zum Hintergrund sehr hoch ist.
Selbst mit einem mathematisch perfekten AA-Algorithmus erzielt man kein viel besseres Ergebniss. Habs selber ausprobiert und da kommen gerade mal noch ein bis zwei Farbstufen mehr bei raus. Sieht qualitativ fast genauso aus.
Schau mal hier, die Linie hab ich mit Paint.Net und dem dort verwenden AA-Algorithmus (dürfte wohl ein Integralverfahren zur Farbbestimmung verwenden) erstellt:
http://img402.imageshack.us/img402/9705/16qtsaavf8.png

Glatter gehts wahrscheinlich nicht mehr ohne die Pixel ineinander verschwimmen zu lassen (was ja dann kein AA mehr wäre, sondern das Gegenteil, nämlich Informationsverlust).

[R300]

Mhm ok, ich kanns ja leider nicht mehr objektiv Vergleichen, da ich die Radeon nicht mehr habe.
Scheint nur mein Subjektiver Eindruck zu sein, weil mir die Leitungen sofort ins Auge gesprungen sind beim Spielen.