Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum kein Edge Anti-Aliasing?
Tigerchen
2004-01-17, 13:49:32
Edge Anti-Alising war ja der Knüller beim ersten Tomb Raider Spiel. Und es war mit einer aus heutiger Sicht popeligen Voodoo machbar. Als jemand der beim Programmieren beim Z-80A stehengeblieben ist frage ich mich ob das zu schwierig zu programmieren war um Standart für alle zu werden? Oder lag es daran daß die Hersteller und Microsoft sich nicht einig werden konnten dieses Verfahren zum alleinigen Standart zu machen? Oder hat Edge sonstige Nachteile von denen ich noch nichts weiß aber über die mir die Gurus hier berichten könnten? Wer weiß also mehr?
StefanV
2004-01-17, 14:22:54
nujo, das Problem ist ja, daß der Entwickler das (irgendwie) 'aufwändig' implementieren muss...
Leider 'dürfen' die Entwickler das verm. nicht oder aber sie sehen keinen Nutzen dadrin...
Endorphine
2004-01-17, 14:28:28
Multisample Antialiasing ist doch ein echtes edge-AA. Und derzeit ausgesprochen populär, sowohl bei NV als auch bei ATI. :)
Tigerchen
2004-01-17, 14:36:10
Original geschrieben von Endorphine
Multisample Antialiasing ist doch ein echtes edge-AA. Und derzeit ausgesprochen populär, sowohl bei NV als auch bei ATI. :)
Ist denn Multisampling so optimal daß es auch auf einer Voodoo machbar wäre oder ließen sich mit Edge nicht doch gewaltig Resourcen einsparen?
StefanV
2004-01-17, 14:43:28
Original geschrieben von Tigerchen
Ist denn Multisampling so optimal daß es auch auf einer Voodoo machbar wäre oder ließen sich mit Edge nicht doch gewaltig Resourcen einsparen?
Ich denke, daß EdgeAA für die Hardware billiger wäre, da der Progger gezielt die Kanten glätten (lassen) kann, die es nötig habne...
Demirug
2004-01-17, 14:53:31
Edge-AA ist sehr Fehleranfällig und aufwendig zu programmieren. Von der Qualität kommt es auch bei weitem nicht an MSAA oder SSAA heran.
Soweit ich das verstanden habe muss bei edge aa, alles von hinten nach vorne gerendert werden und das macht sämtliche hardware occ features unbrauchbar (HyperZ usw..)
Außerdem is das bei multi million Szenen schon allein von der CPU Zeit unpraktikabel
Demirug
2004-01-17, 15:19:39
Original geschrieben von Coda
Soweit ich das verstanden habe muss bei edge aa, alles von hinten nach vorne gerendert werden und das macht sämtliche hardware occ features unbrauchbar (HyperZ usw..)
Außerdem is das bei multi million Szenen schon allein von der CPU Zeit unpraktikabel
Nein, Edge-AA funktioniert anders.
Zuerst rendert man alles ganz normal. Danach lässt man von der CPU alle Aussen-Kanten errechnen die man glätten möchte. Diese Kanten übergibt man als Linienzüge dem Chip. Dort wieder jeser Pixel der auf einem Linenzug liegt dann geblurt. Fertig ist das Edge-AA. Wird aber heute AFAIK von keinem Chip mehr unterstützt.
Tigerchen
2004-01-17, 16:30:33
Original geschrieben von Demirug
Edge-AA ist sehr Fehleranfällig und aufwendig zu programmieren. Von der Qualität kommt es auch bei weitem nicht an MSAA oder SSAA heran.
Danke sehr. So ist das also. :)
Exxtreme
2004-01-17, 17:13:39
Original geschrieben von Coda
Soweit ich das verstanden habe muss bei edge aa, alles von hinten nach vorne gerendert werden und das macht sämtliche hardware occ features unbrauchbar (HyperZ usw..)
Naja, beim TBDR hat die Sortierreihenfolge keine Auswirkung. Beim IMR werden die Occlusion-Features tatsächlich sehr ineffektiv.
Demirug
2004-01-17, 17:32:02
Original geschrieben von Exxtreme
Naja, beim TBDR hat die Sortierreihenfolge keine Auswirkung. Beim IMR werden die Occlusion-Features tatsächlich sehr ineffektiv.
Auch bei einem TBDR kann die Reihenfolge eine Auswirkung haben. Jetzt nicht geraden bei den Kyros aber das ist ja nicht die einzige möglichkeit einen TBDR zu bauen.
Original geschrieben von Demirug
Nein, Edge-AA funktioniert anders.
Zuerst rendert man alles ganz normal. Danach lässt man von der CPU alle Aussen-Kanten errechnen die man glätten möchte. Diese Kanten übergibt man als Linienzüge dem Chip. Dort wieder jeser Pixel der auf einem Linenzug liegt dann geblurt. Fertig ist das Edge-AA. Wird aber heute AFAIK von keinem Chip mehr unterstützt.
:???:
Unter Edge-AA verstehe ich das was Voodoo1 schon konnte, nämlich für die Kantenpixel der entsprechenden Kanten (3 Flags) Alpha-Werte zu errechnen, welche man dann zum Alpha-Blending verwenden kann.
Glättungs-Qualität: fast perfekt.
Probleme: Muss Back-to-Front gerendert werden (sehr langsam), Alpha Blending kostet Bandbreite (ist aber bei heutigen Chips mit FB-Kompression nicht mehr so dramatisch, zumal "Kanten-Tiles" sowieso in den Tilecache gelesen werden müssen). Und es gibt ein paar Situationen, in denen man unvermeidlich Bildfehler bekommt.
Wie genau soll das denn mit dem Blurren von einzelnen Pixeln funktionieren?
Demirug
2004-01-17, 19:48:40
Xmas, so war Edge-AA bei DX definiert. Das Bluren funktioniert so wie man es immer macht. Die Umgebungspixel werden gewichtet verrechnet.
Original geschrieben von Demirug
Xmas, so war Edge-AA bei DX definiert. Das Bluren funktioniert so wie man es immer macht. Die Umgebungspixel werden gewichtet verrechnet.
Das ist dann aber ein bisschen aufwändig in Hardware zu realisieren (und ist qualitativ, gelinde gesagt, Müll). Gibt es überhaupt einen Chip der das unterstützt?
Original geschrieben von Demirug
Xmas, so war Edge-AA bei DX definiert.
*verwirrt*
Wie jetzt? Hatte ich doch irgendwie recht?
Demirug
2004-01-17, 21:15:25
Original geschrieben von Coda
*verwirrt*
Wie jetzt? Hatte ich doch irgendwie recht?
Scheinbar gibt es zwei verfahren die sich beide Edge-AA nennen.
Das DX-Verfahren und das Glide Verfahren.
Also das 3Dfx Verfahren ist ja eher ein Edge-Blur dann...
Genauso gut wie das "trilineare" dithering der Voodoo 2 :D
Naja beide sind heute ja wohl nicht mehr praktikabel
Original geschrieben von Coda
Also das 3Dfx Verfahren ist ja eher ein Edge-Blur dann...
Du meinst das DX Verfahren, oder?
Das Glide Verfahren (also Alphawerte für die Ränder berechnen) ist doch auch das ursprüngliche OpenGL Verfahren, mittels glEnable(GL_POLYGON_SMOOTH);
Beim N64 war immer von AntiAliasing die Rede (habe leider keins, um das mal genauer zu begutachten), was wurde da denn gemacht?
Du meinst das DX Verfahren, oder?
Nein. Wenn DX das Back-to-Front Verfahren benützt, dann is das kein Blur.
Die line list von Glide hingegen schon ...
Das Glide Verfahren (also Alphawerte für die Ränder berechnen) ist doch auch das ursprüngliche OpenGL Verfahren, mittels glEnable(GL_POLYGON_SMOOTH);
Das ist laut Demi eben nicht das Glide Verfahren
Beim IMR werden die Occlusion-Features tatsächlich sehr ineffektiv.
Bei reinem back-to-front ist die Performance damit sogar schlechter als ohne
Sagt mal kommt nur mir das so vor oder ist Parhelia's 16x AA auch nichts anderes als Edge AA? Das würde auch die Fehler erklären die an manchen Stellen auftreten.
Original geschrieben von Coda
Nein. Wenn DX das Back-to-Front verfahren benützt, dann is das kein Blur.
Die line list von Glide hingegen schon ...
Andersherum. Glide und OpenGL benutzen Alpha-Blending.
Tigerchen
2004-01-18, 03:05:55
Original geschrieben von Coda
Sagt mal kommt nur mir das so vor oder ist Parhelia's 16x AA auch nichts anderes als Edge AA? Das würde auch die Fehler erklären die an manchen Stellen auftreten.
Interessante Frage!
Original geschrieben von Tigerchen
Interessante Frage!Die ist längst beantwortet, dachte ich.
http://www.3dcenter.org/artikel/multisampling_anti-aliasing/index6.php
Allerdings hat FAA Probleme mit Alpha Blending.
_Eine_ Art von EdgeAA :
Discontinuity Edge Overdraw (http://people.deas.harvard.edu/~pvs/research/overdraw/)
Die PowerPoint - Präsentation (http://research.microsoft.com/~hoppe/overdraw.ppt)
Das PDF-File (http://research.microsoft.com/~hoppe/overdraw.pdf)
Original geschrieben von Xmas
Andersherum. Glide und OpenGL benutzen Alpha-Blending.
Also irgendwas bekommst du durcheinander. Demi sagte das Glide ne Line List benützt um die Edges zu bluren.
Alpha Blending ist aber kein Blur. Und OpenGL und D3D benützen eben dieses
Hm wie jetzt, benützt Glide ne Line List oder Direct3D
Verwirrend war wohl Demis "Xmas, so war Edge-AA bei DX definiert.", womit er sich auf das bezog, was er selber vorher erklärt hat und nicht auf Xmas Erklärung.
MadManniMan
2004-01-19, 03:49:59
Original geschrieben von Gast
_Eine_ Art von EdgeAA :
Discontinuity Edge Overdraw (http://people.deas.harvard.edu/~pvs/research/overdraw/)
Die PowerPoint - Präsentation (http://research.microsoft.com/~hoppe/overdraw.ppt)
Das PDF-File (http://research.microsoft.com/~hoppe/overdraw.pdf)
Hm, die Glättung ist sehr gut, nur leider "verdickt" das Verfahren alle Objekte. Somit ist es nur eine Abwandlung von Blur-Filtern.
MadManniMan
2004-01-19, 03:53:11
Achja: jetzt bin ich verwirrt! TR lief dereinst bei CannedCaptain mit seiner V2 unter Glide und die Kanten waren herrlich(tm) geglättet. Populous lief AFAIR unter D3D und hatte ebenso herrliche(tm) Kanten, dafür litt die Performance merklich. Zudem produzierten manche "Hotspots" Artefakte. Was war denn jetzt was? Und wie um Himmels willen blürrte das Blürr-Verfahren? Namen sich die Kantenpixel einfach die Infos aus den umliegenden Pixeln? Das wär Schranz!
zeckensack
2004-01-20, 06:15:04
Glide:
Name
grAADrawTriangle – draw an anti-aliased triangle
C Specification
void grAADrawTriangle( GrVertex *a, GrVertex *b, GrVertex *c,
FxBool antialiasAB, FxBool antialiasBC, FxBool antialiasCA)
Parameters
a Vertex a.
b Vertex b.
c Vertex c.
antialiasAB If FXTRUE, anti-alias the AB edge.
antialiasBC If FXTRUE, anti-alias the BC edge.
antialiasCA If FXTRUE, anti-alias the CA edge.
Description
Glide draws a triangle with the specified edges anti-aliased by setting up the alpha iterator so that it represents pixel coverage. grAlphaCombine must select iterated alpha and grAlphaBlendFunction should select GR_BLEND_SRC_ALPHA, GR_BLEND_ONE_MINUS_SCR_ALPHA as the RGB blend functions and GR_BLEND_ZERO, GR_BLEND_ZERO as the alpha blend functions if sorting from back to front and GR_BLEND_ALPHA_SATURATE, GR_BLEND_ONE as the RGB blend functions and GR_BLEND_SATURATE, GR_BLEND_ONE as the alpha blend functions if sorting from front to back. Opaque anti-aliased primitives must set alpha=255 in the vertex data. Transparent anti-aliased primitives are drawn by setting alpha to values less than 255; this alpha value is multiplied by the pixel coverage to obtain the final alpha value for alpha blending.
________________
Es handelt sich hierbei also um Edge-AA der Marke "Coverage". Für die Kanten, die der Programmierer als Aussenkanten deklariert hat, wird ein Überdeckungsgrad berechnet, der mit dem Alpha-Wert des Pixels multipliziert wird. Wenn Blending aktiv ist, werden die Kantenpixel entsprechend dieses Überdeckungsgrads transparent, wodurch sich der AA-Effekt ergibt.
Die Qualität ist vergleichbar zu Matrox FAA (wie Multisampling, aber Schnittkanten können nicht behandelt werden). Allerdings erfordert es wie bereits erwähnt eine Sortierung aller Flächen.
OpenGL kann das auch:
glEdgeFlag gibt pro Vertex an, ob dieser eine zu glättende Aussenkante beendet.
glEnable(GL_POLYGON_SMOOTH) aktiviert die Coverage-Berechnung.
Auch hier muss wieder explizit Blending aktiviert werden, damit sich das ganze auswirkt.
Und auch hier muss wieder sortiert werden, um Fehler zu vermeiden.
Apropos Fehler:
Die Sortierung ist notwendig, weil sonst zB "weiter vorne" liegende, halbtransparente Kantenpixel 'dank' Z-Test das Rendern weiter hinten liegender Pixel verhindert. Dabei will man sie ja gerade mit weiter hinten liegenden Pixeln vermischen, um den AA-Effekt zu erreichen. Das heisst also, dass sie mit potentiell falschen Farben vermischt werden, wenn nicht strikt sortiert wird.
Ailuros
2004-01-21, 04:33:10
Ist es ueberhaupt moeglich mit edge or fragment AA fuer N samples einen N*N grid zu erreichen?
Wenn nicht dann wuerde ich eher fragen: wozu ueberhaupt edge AA?
Ich kann nicht einsehen warum 64x sample F/edge-AA mehr bringen sollte, als ein 8x sparse MSAA Algorithmus momentan.
Original geschrieben von Ailuros
Ist es ueberhaupt moeglich mit edge or fragment AA fuer N samples einen N*N grid zu erreichen?
Für FAA: Natürlich geht das, man kann genau dieselben Pattern verwenden wie bei Multisampling. Denn es ist im Prinzip nur Multisampling für Kantenpixel (und es scheint ein bisschen sparsam bei Z/Stencil zu sein).
Edge AA benutzt gar keine Samples, sondern berechnet den Coverage-Wert quasi analytisch (wenn auch nicht besonders präzise).
Ailuros
2004-01-21, 05:38:01
Danke. Was genau meinst Du mit quasi-analytisch?
Original geschrieben von Ailuros
Danke. Was genau meinst Du mit quasi-analytisch?
Zum Beispiel nach Art des Wu Antialiasing (http://freespace.virgin.net/hugo.elias/graphics/x_wuline.htm).
loewe
2004-01-23, 18:26:26
Ist zwar ein bischen offtopic, aber sagt euch non maskable irgend etwas im Zusammenhang mit MSAA?
Original geschrieben von loewe
Ist zwar ein bischen offtopic, aber sagt euch non maskable irgend etwas im Zusammenhang mit MSAA?
Ja. DirectX9 unterscheidet zwischen "maskable" und "non-maskable" Antialiasing-Modi.
Wenn eine Anwendung nur Antialiasing will, fordert sie non-maskable Antialiasing an. Dafür gibt es Qualitätsstufen: Der Treiber liefert die Anzahl der unterstützten AA-Modi über DX-Caps zurück, und die Anwendung kann die Qualität von 0 (kein AA) bis zu dieser Zahl wählen. Der Treiber ordnet dann entsprechend den Zahlen die AA-Modi zu. So wäre z.B. bei R300 0 = kein AA, 1 = 2xAA, 2 = 4xAA, 3 = 6xAA.
Wenn eine Anwendung jedoch irgendwelche Effekte über Multisample-Buffer realisieren will, braucht man mehr Kontrolle darüber, nämlich Masking. Das heißt, dass man das Schreiben in einen oder mehrere MS-Buffer unterdrückt. So kann man z.B ein Bild in einen MS-Buffer rendern, dann ändert man die Maske und rendert ein anderes in einen anderen MS-Buffer. Die MSAA-Filterlogik sorgt nun automatisch dafür dass die beiden Bilder zusammengeblendet werden, so wie es mit AA-Samples geschieht.
Beim maskable AA muss man explizit angeben, dass man N Samples (= N MS-Buffer) möchte.
Es gibt nun AA-Modi, die nicht maskable sind (Supersampling in fast allen Implementationen, FAA, auch beim Multisampling könnte man sich vorstellen dass ein Chiphersteller die Masking-Möglichkeit weglässt). Diese kann die Anwendung nur über den "non-maskable-Weg" aktivieren.
Demirug
2004-01-23, 19:04:01
Original geschrieben von loewe
Ist zwar ein bischen offtopic, aber sagt euch non maskable irgend etwas im Zusammenhang mit MSAA?
Ja, natürlich.
Wobei man das nicht auf MSAA begrenzen kann sondern alle Arten von AA betroffen sind. Neben "non maskable" gibt es natürlich auch noch "maskable". Der unterschied zwischen diesen beiden Varianten ist das man bei "maskable" noch eine zusätzliche Maske zur Verfügung hat die angibt welche Suppixel in den Buffer geschrieben werden können. Hat man also ein 4xAA das "maksable" ist hat man eine Make mit 4 Bit. Beim "non maskable" fällt diese Maske weg.
Wenn es nur um die glättungswirkung geht reicht ein "non maskable" AA völlig aus. Ein Maskable AA braucht man nur wenn spezielle Sachen machen möchte. Wie zum Beispiel mein Alpha-Test MSAA Trick. Auch Motion-Blur über den MS-Buffer fällt unter diese Sachen.
EDIT: Xmas war schneller.
Demirug
2004-01-23, 19:10:44
Original geschrieben von Xmas
Es gibt nun AA-Modi, die nicht maskable sind (Supersampling in fast allen Implementationen, FAA, auch beim Multisampling könnte man sich vorstellen dass ein Chiphersteller die Masking-Möglichkeit weglässt). Diese kann die Anwendung nur über den "non-maskable-Weg" aktivieren.
Im Prinzip spricht aber nichts gegen ein Maskable Super-Sampling oder FAA. Wobei beim FAA wahrscheinlich dann der Speicher Probleme machen wird. Aber zumindestens auf der GF1 war das Supersampling auch Maskabel. Dagegen gibt es mit neueren Treibern für die GF4 überhaupt keine maskeable AA-Modies mehr.
MS bevorzugt es allerdings sowieso das man nach Möglichkeit nur die "non maskable" AA-Modies nutzen soll.
loewe
2004-01-23, 19:31:00
Ok, danke!
Ist also eine ganz normale DX Funktion, wobei bis zu 8 Qualitätsstufen beim non maskable AA und bis zu 16 Samples beim maskable AA durch DX9 unterstützt werden.
Original geschrieben von Demirug
Im Prinzip spricht aber nichts gegen ein Maskable Super-Sampling oder FAA. Wobei beim FAA wahrscheinlich dann der Speicher Probleme machen wird.
Klar, Supersampling kann man genauso behandeln wie Multisampling. Nur wird ja nicht selten einfach eine größere Auflösung runtergerechnet, ohne dass Hardware vorhanden ist die maskieren könnte. FAA würde man dann ja effektiv zum MSAA machen. Z3 u.ä. ist natürlich auch nicht maskable weil verlustbehaftet.
Aber zumindestens auf der GF1 war das Supersampling auch Maskabel. Dagegen gibt es mit neueren Treibern für die GF4 überhaupt keine maskeable AA-Modies mehr.
Erstaunlich. Bei GF1 gibt es dann wohl eine programmierbare "Pipe-Maske", die ja dann der Subpixelmaske entspricht.
Demirug
2004-01-23, 19:41:43
Original geschrieben von loewe
Ok, danke!
Ist also eine ganz normale DX Funktion, wobei bis zu 8 Qualitätsstufen beim non maskable AA und bis zu 16 Samples beim maskable AA durch DX9 unterstützt werden.
Wie kommst du jetzt auf 8 Qualitätsstufen? Eigentlich gibt es da kein Limit. Das gleich gilt übrigens auch für das Maskable AA. Neben der Anzahl der Samples kann es hier auch noch jeweils mehrer Qualitätsstufen geben. Wobei ich bis jetzt noch keinen Treiber gesehen haben der Maskable AA mit mehr als einer Stufe im Angebot hatte.
Demirug
2004-01-23, 19:43:21
Xmas, beim Z3 Verfahren könnte man ja eine 3 Sample Maske benutzten. Würde aber wohl doch ein recht heftiges Gefummel so das man es besser bleiben lässt.
Original geschrieben von Demirug
Wobei ich bis jetzt noch keinen Treiber gesehen haben der Maskable AA mit mehr als einer Stufe im Angebot hatte.
Das erstaunt mich jetzt aber. In den DX-SDK Demos kann ich NoAA, Non-Maskable (mit Qualitätsstufen 0-2?), 2, 4 und 6 Sample AA auswählen.
Cat3.7, wenn ich mich nicht irre.
edit: ich habe gerade festgestellt, dass meine Beschreibung oben nicht ganz korrekt war. 0 entspricht der "schlechtesten" AA-Stufe über NoAA, also 2x. Entsprechend 1=4x, 2=6x. Und ja, alle drei maskable Modi funktionieren so wie sie sollten.
Demirug
2004-01-23, 19:57:20
Original geschrieben von Xmas
Das erstaunt mich jetzt aber. In den DX-SDK Demos kann ich NoAA, Non-Maskable (mit Qualitätsstufen 0-2?), 2, 4 und 6 Sample AA auswählen.
Cat3.7, wenn ich mich nicht irre.
edit: ich habe gerade festgestellt, dass meine Beschreibung oben nicht ganz korrekt war. 0 entspricht der "schlechtesten" AA-Stufe über NoAA, also 2x. Entsprechend 1=4x, 2=6x. Und ja, alle drei maskable Modi funktionieren so wie sie sollten.
Ich glaube wir haben uns da missverstanden. Ich meinte nicht das es keine Treiber gibt die sowohl Non-Maskable und Maskable Modies haben. Die gibt es auf jeden Fall.
Was ich meinte ist das ich noch keinen Treiber gesehen abe der bei einem Maskable Modus mehr als eine Qualitätstufe hatte.
Original geschrieben von Demirug
Ich glaube wir haben uns da missverstanden. Ich meinte nicht das es keine Treiber gibt die sowohl Non-Maskable und Maskable Modies haben. Die gibt es auf jeden Fall.
Was ich meinte ist das ich noch keinen Treiber gesehen abe der bei einem Maskable Modus mehr als eine Qualitätstufe hatte.
Achso, du meist also z.B. 2xMSAA = 0, Quincunx = 1 bei D3DMULTISAMPLE_2_SAMPLES. Hm, ich ging bisher davon aus dass das gar nicht vorgesehen ist, sprich Quality Level beeinflusst nur non-maskable.
Demirug
2004-01-23, 20:53:21
Original geschrieben von Xmas
Achso, du meist also z.B. 2xMSAA = 0, Quincunx = 1 bei D3DMULTISAMPLE_2_SAMPLES. Hm, ich ging bisher davon aus dass das gar nicht vorgesehen ist, sprich Quality Level beeinflusst nur non-maskable.
Wenn sich das nicht wieder geändert hat ist es erlaubt auch bei Maskable AA mehr als einen Quality Level anzubieten.
Ailuros
2004-01-24, 12:23:37
Moeglicherweise sehr dumme Frage:
Was spricht eigentlich dagegen dass man ungerade Anzahlen von MSAA benutzt? Im Durchschnitt zu viel Aufwand im Vergleich zum Qualitaetsgewinn?
loewe
2004-01-24, 18:17:48
Original geschrieben von Demirug
Wie kommst du jetzt auf 8 Qualitätsstufen? Eigentlich gibt es da kein Limit. Das gleich gilt übrigens auch für das Maskable AA. Neben der Anzahl der Samples kann es hier auch noch jeweils mehrer Qualitätsstufen geben. Wobei ich bis jetzt noch keinen Treiber gesehen haben der Maskable AA mit mehr als einer Stufe im Angebot hatte.
Aha, also ist es Sache des Herrstellers, wenn er auf 8 und 16 begrenzt!
Danke, ihr habt wir wirklich geholfen.
Original geschrieben von Ailuros
Moeglicherweise sehr dumme Frage:
Was spricht eigentlich dagegen dass man ungerade Anzahlen von MSAA benutzt? Im Durchschnitt zu viel Aufwand im Vergleich zum Qualitaetsgewinn?
Der Aufwand dürfte sich eigentlich in Grenzen halten. Bei der Framebuffer-Kompression müsste man evtl. ein bisschen was ändern, ebenso beim Downsampling (Samples mit 1/2 oder 1/4 zu gewichten ist sehr einfach; allerdings hat man bei 1/6 ein ähnliches Problem).
Nun kommt aber hinzu dass z.B. R3x0 IIRC nur 2 ROPs pro Pipeline haben und für weitere Samples loopen müssen. Um bei ungeraden Zahlen immer noch volle Auslastung zu haben, müsste man hier wohl einiges umbauen.
Außerdem ist das einzig brauchbare Samplemuster für 3x mit ein paar ungünstigen Winkeln behaftet, und 5x lohnt nicht recht, wenn man 4x und 6x zur Auswahl hat.
Ailuros
2004-01-25, 02:50:20
Ich hab ein bisschen mehr in Richtung NVIDIA/3x MSAA gedacht und nur im Fall wo sie nicht an Quincunx gedacht haetten.
Bei allem ausser ordered grid kann ich mir fuer 3xMSAA, 2*3, 3*2 oder sogar 3*3 vorstellen, was theoretisch sogar effektiver in der Mehrheit als 4xOGMS sein sollte. In diesem spezifischen Fall ist der Leistungsverlust zwischen 2x und 4xMSAA in den extremsten Faellen sowieso gering, was wohl nicht auf loops mit 2x samples deutet. Noch weiter haette man doch bei FX fuer Quincunx von 2x sparse zu 3x sparse + 5-tap filter erweitern koennen oder? (obwohl ich wirklich kein grosser Anhaenger von blur-filtern bin; nur fuer sehr wenige Aussnahmen).
Was ATI R3xx betrifft ist mir das schon klar, obwohl man vielleicht doch durch geniales sample-positioning etwas herausholen koennte. Der Vergleich zwischen Aufwand und tradeoff gilt hier aber eher wenn fuer 2x - 2*2 und fuer 4x - 4*4 schon bereit steht.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.