Zukuenftige AA Moeglichkeiten/Methoden

[Ailuros]

Ok, eine A-Buffer Variante ist da schon was anderes. Aber Z3 kann zum Beispiel kein Verlustfreies AA sicherstellen. Solange die Anzahl der Dreiecke pro Pixel kleiner gleich der die Anzahl der Mask-Slots per Pixel ist geht das ja gut. Wenn es mehr werden gibt es zwangsläufig Verluste. Wenn man aber nun genauso viele Slots pro Pixel hat wie bisher AA-Samples wird das ergebniss besser. Allerdings braucht ein Slot auch mehr Speicherplatz als ein AA-Sample. Erschwerend kommt hinzu das man zum Beispiel bei der Z3 Methode noch keine Lösung für den Stencilbuffer hat. Wobei man wohl mit einer ähnlichen Methode arbeiten könnte.

Frage: kann die Accuview/Intellisample Methode verlustfreies AA sicherstellen? Waere der framebuffer "on-chip" dann sehe ich wenig Grund warum Z3 keine verlustfreie AA Moeglichkeit bieten koennte (na der Satz war wohl von mir zu erwarten ;) ).

Ich hab schon lange nicht mehr in Z3 whitepapers rumgestoebert, aber wieso ist stenciling unmoeglich mit Z3?

Hier ist ein Ausschnitt der von einer Moeglichkeit einer Kombination von Z3 und FAA spricht:

You could keep the advantages of FAA without it's problems by using a modification of Z3.

In this case you would segregate pixels that had a partially occupied front sample mask as AAed pixels, rather than use fragment edges as the determining factor. You would save all AAed pixels to the AA store and non-AA pixels to the frame buffer much the same as FAA. To improve performance further you would also modify Z3 by not waiting for the masks in a pixel to fill before combining fragments into a common mask. Instead you would combine the fragments whenever the AND of their masks is null (meaning no overlap) and (nearly) matching Zs, which indicate the fragments are most likely part of the same surface.

This should have better performance than FAA and should easily extend to 32x or better AA (simply more bits in the mask) without much additional performance hit. It would also have significantly better performance and lower memory requirements than standard Z3.

As a side benefit you could get order-independent antialiased transparency in the same manner as standard Z3. Stenciling would also not pose a problem.

I would definitely keep the spare matrix sampling pattern that Z3 uses as well.

Nicht verbunden mit der A-buffer Variante, aber nur weil ich mich wundere wieso behauptet wird dass stenciling kein Problem mit Z3 waere, oder wenigstens interpretiere ich es so.

[Demirug]

Originally posted by Ailuros


Frage: kann die Accuview/Intellisample Methode verlustfreies AA sicherstellen? Waere der framebuffer "on-chip" dann sehe ich wenig Grund warum Z3 keine verlustfreie AA Moeglichkeit bieten koennte (na der Satz war wohl von mir zu erwarten ;) ).
Ja Accuview stellt im gegebenen Rahmen ein verlustfreies AA da. Wenn man zum Beispiel mit 4 AA-Sample pro Pixel arbeitet so ist sichergestellt das auch alle 4 Sample in den engültigen Pixelwert ohne Verlust eingehen.

nehmen wir nun das Z3 Verfahren. 8 Samples aber nur 3 Speicherslots. Wenn sich in dem Pixel nur mehr als 3 Dreiecke überschneiden muss das Z3 Verfahren die Farbwerte von mehrern dieser Dreiecke zusammenrechnen. Dies kann nun im Verhältniss zu einem normalen AA zu verlusten führen.

Das soll jetzt aber nicht heissen das ich Z3 nicht gut finden. Bei etwa dem gleichem Speicherverbrauch wie 4xAA müsste das Verfahren eine viel besseres Bild als 4xAA erzeugen. 8xAA mit 8 vollständige Samples würde aber noch besser aussehen aber auch mehr Speicher verbrauchen. Ein guter Kompromiss zwischen Speicherverbrauch und Qualität ist Z3 auf jeden Fall.

Und bei einem framebuffer on Chip (ich habe den Wink verstanden ;)) braucht man doch solche verrenkungen nicht zu machen. Letzendlich geht es doch immer nur darum möglichst viele AA-Samples in möglichst wenig Speicher unterzubringen. Und da bei einem framebuffer on Chip hat man ja solche Probleme nicht wirklich.

Ich hab schon lange nicht mehr in Z3 whitepapers rumgestoebert, aber wieso ist stenciling unmoeglich mit Z3?

Nicht unmöglich nur geht das Papier auf die Probleme die sich ergeben nicht wirklich ein. Der Vorschlag zu jedem der Samples im Speicher einfach auch noch einen Stencilwert zu speicher scheint mir nicht unbedingt gut durchdacht.

[Ailuros]

Und bei einem framebuffer on Chip (ich habe den Wink verstanden ) braucht man doch solche verrenkungen nicht zu machen. Letzendlich geht es doch immer nur darum möglichst viele AA-Samples in möglichst wenig Speicher unterzubringen. Und da bei einem framebuffer on Chip hat man ja solche Probleme nicht wirklich.

Ja schon nur wuerde dann theoretisch in diesem Fall eine Z3 oder aehnliche Methode mehr samples als normales MSAA erlauben, oder nicht?

Nicht unmöglich nur geht das Papier auf die Probleme die sich ergeben nicht wirklich ein. Der Vorschlag zu jedem der Samples im Speicher einfach auch noch einen Stencilwert zu speicher scheint mir nicht unbedingt gut durchdacht.

Tja das waer wohl ein Thema zur Aufklaerung mit SA auf B3D, falls Du interessiert sein solltest, denn er erscheint sich aeusserst mit dem Algorithmus auszukennen. Ich vermisse die ernsthaften Diskussionen dort drueben, und der ganze "politische" IHV Wirrwarr geht mir so langsam auf die Nerven. Ich hab leider nicht das knowhow bei so einer Diskussion mitzuhalten, bin aber ein guter Leser ;)

Frage: was haelst Du von dem Vorschlag einer theoretischen Kombination von Z3 und FAA? Wuerde Fragment AA - ohne die Probleme der Implementation von Matrox - nicht eine bessere und schnellere Loesung darstellen? Wie steht es uebrigens mit sampling Positionen und FAA; ist da auch sparsely sampled z.B. moeglich oder nur stinknormales ordered grid?

[aths]

FAA sollte beliebige Muster erlauben. Das ist IIC eine Frage des Triangle Setups und natürlich der AA-Pipeline.

Das Z3-Prinzip halte ich für nicht schlecht, aber das wichtigste ist doch, Bandbreite zu sparen und nicht unbedingt RAM. Will sagen, 8x FSAA erfordert zwar sehr viel RAM, aber die RAM-Größe ist unkritischer als die Bandbreite. MSAA mit Framebuffer-"Komprimierung" ist imo die beste Lösung. Mehr als 8x AA ist bei gutem Sample-Pattern imo nicht wirklich sinnvoll, und der RAM dafür sollte da sein (spätestens auf Karten mit 256 MB.)

[Demirug]

Originally posted by Ailuros


Ja schon nur wuerde dann theoretisch in diesem Fall eine Z3 oder aehnliche Methode mehr samples als normales MSAA erlauben, oder nicht?

Nein, den die Samples müssen so oder so erzeugt werden. Soll heissen das man genügend AA-Sampler pro Pipeline braucht. Das ich das sture Erhöhen der AA-Sampler Anzahl pro Pipeline aber nicht als sinnvoll erachte habe ich ja schon gesagt. Bei einem Verfahren wie Z3 geht es nur darum den Speicherverbrauch im Grafikspeicher zu begrenzen und damit auch die Bandbreite die verbraucht wird. Beides Problem die man bei einem Framebuffer on Chip ja gar nicht hat weil die AA-Sample werte ja niemals in den Grafikspeicher geschreiben werden.

Tja das waer wohl ein Thema zur Aufklaerung mit SA auf B3D, falls Du interessiert sein solltest, denn er erscheint sich aeusserst mit dem Algorithmus auszukennen. Ich vermisse die ernsthaften Diskussionen dort drueben, und der ganze "politische" IHV Wirrwarr geht mir so langsam auf die Nerven. Ich hab leider nicht das knowhow bei so einer Diskussion mitzuhalten, bin aber ein guter Leser ;)

Frage: was haelst Du von dem Vorschlag einer theoretischen Kombination von Z3 und FAA? Wuerde Fragment AA - ohne die Probleme der Implementation von Matrox - nicht eine bessere und schnellere Loesung darstellen? Wie steht es uebrigens mit sampling Positionen und FAA; ist da auch sparsely sampled z.B. moeglich oder nur stinknormales ordered grid?

Bei B3D halte ich mich eigentlich raus. Mein englisch ist leider nicht das beste was dazu führt das ich für das abfassen eines Posts mehr über die englische Gramatik und Wortwahl nachdenke als über den Inhalt.

Ich sehe eigentlich nicht wirklich grosse Berührungspunkte zwischen Z3 und FAA. Beide Verfahren habe zwar das gleiche Ziel gehen aber grundsätzlich verschiedene Wege. Wobei Z3 das durchaus durchdachtere Verfahren darstellt. Denn einzigen Punkt den ich sehe da noch etwas zu kombinieren wäre beim Z3 Verfahren auch grundsätzlich erst mal nur ein Sample pro Pixel zu speichern und bei bedarf Zusätzliche in einem Überlaufbereich. Wenn dieser Bereich dann voll ist müsste man zwei Samples (von einem Pixel) ach dem Z3 Verfahren zu einem neuen kombinieren. Das Problem dabei ist nur das diese sache nicht sehr gut mit der Speichertechnologie harmoniert. Und im Falle das der Überlaufbuffer voll ist es sehr aufwendig ist die richtige Wahl bezüglich der zu kombinierenden Samples zu treffen.

Man könnte auch beim einem FAA etwas anderes als ein OG benutzten. Dadurch wird aber die Logik kompliziert (= mehr Transitoren).

[Demirug]

Originally posted by aths
FAA sollte beliebige Muster erlauben. Das ist IIC eine Frage des Triangle Setups und natürlich der AA-Pipeline.

Das Z3-Prinzip halte ich für nicht schlecht, aber das wichtigste ist doch, Bandbreite zu sparen und nicht unbedingt RAM. Will sagen, 8x FSAA erfordert zwar sehr viel RAM, aber die RAM-Größe ist unkritischer als die Bandbreite. MSAA mit Framebuffer-"Komprimierung" ist imo die beste Lösung. Mehr als 8x AA ist bei gutem Sample-Pattern imo nicht wirklich sinnvoll, und der RAM dafür sollte da sein (spätestens auf Karten mit 256 MB.)

aths, du musst das volgendermassen sehen. Für den Speicherbedarf von etwa 4xMSAA bekommt man für die meisten Pixel die Qualität von 8xMSAA. Für den Speicherverbrauch von 8xMSAA ist es dann schon die Qualität von 16xMSAA und so weiter. Egal wie viel Speicher man hat mit einem Z3 Verfahren kann man mit den verfügbaren Speichermengen immer noch ein Plus an Qualität herausholen. Und es spricht ja auch nicht dagegen Z3 in Verbindung mit einer Kompressionstechnik zu nutzen. Das Z3 Paper betrachtet die Sache ja nur auf Pixelebene. Auf Tileebene gibt es da sicherlich noch mehr Ansatzpunkt welche auch zur weiteren Qualitätsteigerung benutzt werden könnten. Und aufgrund der Speichertechnologie kommt man ja um Tiles sowieso kaum noch herum.

[Ailuros]

Bei B3D halte ich mich eigentlich raus. Mein englisch ist leider nicht das beste was dazu führt das ich für das abfassen eines Posts mehr über die englische Gramatik und Wortwahl nachdenke als über den Inhalt.

An was mich das wohl erinnert...Es wird aber besser nach einiger Zeit. So etwa liegt es auch momentan mit meinem Deutsch; wenn ich es aber weiterhin vernachlaessige, dann vergess ich so langsam auch das wenige an das ich mich noch dran erinnern kann.

Ich hab Deine Antworten bei B3D vor einiger Zeit durchgelesen; gut verstehen konnte man es auf jeden Fall. Natuerlich verstehe ich die ganze Umstaendlichkeit der Sache so wie Du es darstellst. Stell Dir mal vor wie schwer es fuer einen Griechen wie mich ist, fuer beide Sprachen ;)

[Demirug]

Originally posted by Ailuros


An was mich das wohl erinnert...Es wird aber besser nach einiger Zeit. So etwa liegt es auch momentan mit meinem Deutsch; wenn ich es aber weiterhin vernachlaessige, dann vergess ich so langsam auch das wenige an das ich mich noch dran erinnern kann.

Ich hab Deine Antworten bei B3D vor einiger Zeit durchgelesen; gut verstehen konnte man es auf jeden Fall. Natuerlich verstehe ich die ganze Umstaendlichkeit der Sache so wie Du es darstellst. Stell Dir mal vor wie schwer es fuer einen Griechen wie mich ist, fuer beide Sprachen ;)

Ja, ich kann mir das durchaus vorstellen. Leider war ich nie ein grosses Sprachgenie. Mir fällt es nun mal viel leichter technische Zusammenhänge zu verstehen als die Unlogik einer Sprache in meinen Kopf zu bekommen.

[aths]

Originally posted by Demirug
aths, du musst das volgendermassen sehen. Für den Speicherbedarf von etwa 4xMSAA bekommt man für die meisten Pixel die Qualität von 8xMSAA. Für den Speicherverbrauch von 8xMSAA ist es dann schon die Qualität von 16xMSAA und so weiter. Egal wie viel Speicher man hat mit einem Z3 Verfahren kann man mit den verfügbaren Speichermengen immer noch ein Plus an Qualität herausholen.Aber immer mit der Möglichkeit, dass es nicht ganz "korrekt" ist. Für schnelle Spiele, wie Shooter, mag das eine gute Idee sein: Ca. 8x AA zum "Preis" von nur 4x AA. Jede Karte sollte imo auch garantiert verlustfreies AA anbieten.

Eine EER von > 4x4 halte ich btw für nicht mehr sooo unbedingt wichtig. Die 8xS-Maske mit reinem Multisampling zu realisieren, würde z.B. die Vorteile von RG und OG vereinen, und eine insgesamt imo völlig ausreichende Kantenglättung bieten - wenn denn gammakorrektes Downfiltering gewährleistet wäre.

[Unregistered]

Sprache => :(

Zum Z3. Bei 32 x Z3 und nur 3 Samples pro Pixel erreicht Z3 laut dem PDF schon die Qualität von 14-16 x Sparse MSAA (oder SSAA ?). Z3 sollte deshalb selbst ohne Kompression bei gleicher Qualität mit weniger Bandbreite auskommen als MSAA; vom Speicherbedarf ganz zu schweigen.

[Demirug]

Originally posted by aths
Aber immer mit der Möglichkeit, dass es nicht ganz "korrekt" ist. Für schnelle Spiele, wie Shooter, mag das eine gute Idee sein: Ca. 8x AA zum "Preis" von nur 4x AA. Jede Karte sollte imo auch garantiert verlustfreies AA anbieten.

Definiere bitte "nicht ganz korrekt" in Verbidung mit AA.

Ein Z3 Verfahren welches die gleiche Anzahl von Samples wie das entsprechende MS-AA Verfahren speichert wird dem MS Verfahren in der Qualität immer überlegen sein. Vorrausgesetzt das die verwendeten Grids vergleichbar sind.

[aths]

Originally posted by Demirug
Definiere bitte "nicht ganz korrekt" in Verbidung mit AA.Wenn du für 8 Samples nur 3 Farben speicherst, müssen u.U. Werte zusammengefasst werden. Die Folge ist eine "Treppen-Stufe", die nicht dem reinen MSAA entspricht.

[Demirug]

Originally posted by aths
Wenn du für 8 Samples nur 3 Farben speicherst, müssen u.U. Werte zusammengefasst werden. Die Folge ist eine "Treppen-Stufe", die nicht dem reinen MSAA entspricht.

ja sicher, reines 8xMSAA ist natürlich etwas besser als Z3 mit 8/3. Aber in den Speicher den man für 8xMSAA braucht könnte man ja auch mehr Z3 Samples pro Pixel pressen was die Qualität wieder erhöhen würde weil man mit mehr gespeicherten Samples ja auch die Anzahl der Samples pro Pixel erhöhen könnte.

Was mir aber noch eingefallen ist.

Bisher haben wir ja immer nur von gespeicherten Samples pro Pixel gesprochen. Wenn wir aber nun mal von gespeicherten Samples pro Tile sprechen wird ein Z3 Verfahren durchaus noch interesanter.

Also bei einer 8*8 Tile mit 3 Samples pro Pixel hätte man in der Tile 192 Samples zur Verfügung. Wenn 50% der Pixel nicht auf einer Kante liegen hätte man für die restlichen 50% der Pixel jeweils 5 Samples zur Verfügung. Der Preis wären allerdings 6 zusätzliche Bit pro Sample. Wenn man bedenkt das bei üblichen Szene nur ein Bruchteil der Pixel überhaupt von MSAA profitieren kann erscheint mir die Idee ungenutze Samples auf Pixel umzuschichten die damit mehr anfangen können gar nicht mal so schlecht.

[Ailuros]

Also bei einer 8*8 Tile mit 3 Samples pro Pixel hätte man in der Tile 192 Samples zur Verfügung.

Was mich aber zur Frage fuehrt: was wenn irgendeine hierarchische Form von "tiling" benutzt wird?

a) Waere es problemlos bei ATI's Hyper-Z?

b) Muesste man dann theoretisch die Berechnung nicht auf Basis der Samples auf dem kleinsten Tile berechnen um das "worst case scenario" nicht auszuschliessen?

c) Wird in dem Sinn AA auf macro oder micro tiles theoretisch angelegt?

[Demirug]

Originally posted by Ailuros


Was mich aber zur Frage fuehrt: was wenn irgendeine hierarchische Form von "tiling" benutzt wird?

a) Waere es problemlos bei ATI's Hyper-Z?

b) Muesste man dann theoretisch die Berechnung nicht auf Basis der Samples auf dem kleinsten Tile berechnen um das "worst case scenario" nicht auszuschliessen?

c) Wird in dem Sinn AA auf macro oder micro tiles theoretisch angelegt?

In anbetracht des heutiegen technischen stands tendiere ich ja sowieso dazu den Z, Stencil und Framebuffer jeweils getrennt zu speichern und dort mit den typischen Daten angepassten Verfahren zu arbeiten.

a) Da eine Hir-Z Lösung ja für die höhren Level der Z-Pyramide eigene Speicherbereiche nutzt und das ganze relative unabhängig vom Rest funktioniert gibt es da wenig Berührungspunkte mit dem genauen AA-Verfahren

b) Ich versteh die Frage nicht ganz. Wenn man definiert das der Framebuffer in Tiles a 8*8 Pixel verwaltet und gespeichert wird gibt es keine kleineren Tiles im System. Die grösse der Tile sollte dabei natürlich nicht so einfach aus der Luft gegriffen werden sondern auf die Burst-Fetch Grösse eines Memorykanals abgestimmt sein.

c) Wie gesagt gibt es ja für den Frambuffer nur eine Tilegrösse aufgrund der starken abweichungen von Pixel zu Pixel in den Werten macht es auch nicht viel Sinn dort mit unterschiedlichen Tilegrössen zu arbeiten. Für den Z und Stencilbuffer kann man durchaus auch eine Pyramide mit unterschiedlichen Tilegrössen bauen. Das Hir-Z von ATI muss ja etwas in der Art tun.

[Ailuros]

Ich versteh die Frage nicht ganz. Wenn man definiert das der Framebuffer in Tiles a 8*8 Pixel verwaltet und gespeichert wird gibt es keine kleineren Tiles im System. Die grösse der Tile sollte dabei natürlich nicht so einfach aus der Luft gegriffen werden sondern auf die Burst-Fetch Grösse eines Memorykanals abgestimmt sein.

Ich haette was anders fragen sollen, bevor ich zu diesen Fragen kam...

Angenommen es gibt eine Pyramide von 8*8 > 4*4 > 2*2, so wie bei R300 (?):

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page4.inc#hyper

Um selber aus meiner Verwirrung herauszukommen wo wird da theoretisch AA angelegt? (daher kommt auch meine Frage wie man in solchen Faellen die Anzahl von Samples pro Pixel ausrechnet).

[Demirug]

Originally posted by Ailuros


Ich haette was anders fragen sollen, bevor ich zu diesen Fragen kam...

Angenommen es gibt eine Pyramide von 8*8 > 4*4 > 2*2, so wie bei R300 (?):

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page4.inc#hyper

Um selber aus meiner Verwirrung herauszukommen wo wird da theoretisch AA angelegt? (daher kommt auch meine Frage wie man in solchen Faellen die Anzahl von Samples pro Pixel ausrechnet).

Das mit einer Hir-Z Pyramide ist etwas komplexer. Man muss hier ganz streng zwischen der Pyramide im Chip und der Pyramide im Speicher unterschieden.

Schauen wir uns zuerst die Daten im Chip an.

Auf der Spitze der Pyramide gibt es genau einen Wert. Auf der Ebene darunter sind es dann 2*2 Werte es geht weiter mit 4*4, 8*8 und so weiter bis man auf der Pixelebene angekommen ist. Beim R300 ist bei 8*8 schluss. Da die Unterlagen aber nur von einer 4*4 Tile bei Hir-Z sprechen muss man davon ausgehen das man pro Tile entweder 4 Pyramiden benutzt oder eine ohne Spitze. Unter der Pixel ebene liegt dann noch mindestens eine Ebene für die AA-Samples (aber nur wenn AA Aktiv ist). Der Einsatz von mehr als einer AA-Sample Ebene macht beim derzeitigen Aufbau von 3D-Chips aber nicht viel Sinn.

Im Speicher wird aber nun nicht die Pyramide gespeichert sonder die Daten aller Pyramiden ebene für ebene. Für das AA ist dabei aber nur die unterste Ebene von Interesse. Da der R300 Chip wohl immer mit einer Tilesize von 8*8 arbeitet ergibt sich die Anzahl der AA-Sample pro Tile also aus dem gwählten AA Modus:

0xAA = 64 Samples
2xAA = 128 Samples
4xAA = 256 Samples
6xAA = 384 Samples

[Ailuros]

Ah danke. Jetzt ist der Groschen endlich gefallen :)