Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidia - Kantenglättung auf Tegra-GPUs - CSAA ohne MSAA
Ailuros
2011-10-31, 06:35:26
http://www.fudzilla.com/mobiles/item/24639-shadowgun-brings-quake-looking-games-to-phones
Nicht schlecht und der Preis sitzt auch.
On a big screen, you will suffer from lack of anti aliasing, but with Tegra 3, we believe that even this will be possible.
Wenn man auf T2 nicht CSAA zuschalten kann, dann ist es Schlamperei seitens des ISV und es wird auch auf T3 nichts bringen. Ueber MSAA ist keiner der beiden faehig.
robbitop
2011-10-31, 08:32:09
Wie soll CSAA ohne MSAA denn gehen?
LovesuckZ
2011-10-31, 11:23:08
Wie soll CSAA ohne MSAA denn gehen?
Genauso wie MSAA ohne SSAA funktioniert. ;)
Ailuros
2011-11-01, 06:14:34
Wie soll CSAA ohne MSAA denn gehen?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8835350&postcount=1241
Tegra CSAA nutzt nur 4 zusätzliche Coverage Samples. MSAA wird nicht unterstützt.
Deshalb auch wo immer anwendwar, quasi umsonst.
robbitop
2011-11-01, 09:50:37
CSAA ist doch nur die Gewichtung von mehreren Subsamples. Wenn keine Subsamples vorhanden sind, ist nichts zum Gewichten da. Mit SSAA würde das sicher auch gehen. Aber irgendein richtiges AA muss dazu aktiviert sein.
Mr. Lolman
2011-11-01, 10:38:45
Die PowerVR SGX (Galaxy S1) können dafür echtes MSAA, mit Chainfire3D sogar für jedes Spiel foricerbar. Der Mali vom SII angeblich sogar ohne Performanceverlust (zumindest hört man das von vielen SII Besitzern. Kann aber auch sein, dass die Performance hoch genug ist, und man deswegen den Verlust nicht merkt)
LovesuckZ
2011-11-01, 11:28:43
CSAA ist doch nur die Gewichtung von mehreren Subsamples. Wenn keine Subsamples vorhanden sind, ist nichts zum Gewichten da. Mit SSAA würde das sicher auch gehen. Aber irgendein richtiges AA muss dazu aktiviert sein.
Es gibt doch ein SubSample bei 1xMSAA, oder?
Ich kenne aber kein Spiel oder eine Anwendung, welches CSAA verwendet. Und wenn es die paar Tegra Spiele doch tun sollten, dann geht der Effekt fast gegen 0.
CSAA ist doch nur die Gewichtung von mehreren Subsamples. Wenn keine Subsamples vorhanden sind, ist nichts zum Gewichten da. Mit SSAA würde das sicher auch gehen. Aber irgendein richtiges AA muss dazu aktiviert sein.
Ich versteh's auch nicht. Wenn man pro Pixel nur eine Farbe hat, was gibt's dann zu verrechnen?
Oder nehmen sie evtl. die Farben von angrenzenden Pixeln?
robbitop
2011-11-01, 11:57:44
Es gibt doch ein SubSample bei 1xMSAA, oder?
Was willst du bei 1x Sample gewichten? ;)
Wenn man die Nachbarpixel nimmt, ist's Gepfusche und kein AA.
Nichtmal unbedingt. In dem Fall könnte der Chip ja auf "lieber gar kein AA" als "blur" zurückfallen, wenn die Nachbarpixel keine sinnvolle Farbe enthalten.
Es ist so gesehen intelligentes Quincunx.
LovesuckZ
2011-11-01, 12:31:30
nVidia verwendet nichts von den Nachbar-Pixel bei CSAA. Sie trennen nur die Coverage-Samples vom Rest.
robbitop
2011-11-01, 12:37:30
Nichtmal unbedingt. In dem Fall könnte der Chip ja auf "lieber gar kein AA" als "blur" zurückfallen, wenn die Nachbarpixel keine sinnvolle Farbe enthalten.
Es ist so gesehen intelligentes Quincunx.
Resultat wäre aber -wenn man das ganze Bild betrachtet- inhomogen und somit unschön. Dann lieber gar nix. ;)
nVidia verwendet nichts von den Nachbar-Pixel bei CSAA. Sie trennen nur die Coverage-Samples vom Rest.
Ohne echtes AA keine Subsamples. Ohne Subsamples kein CSAA. Zumindest nicht sinnvoll.
AFAIK kann Tegra von der HW her MSAA (und auch in Kombination mit CSAA).
nVidia verwendet nichts von den Nachbar-Pixel bei CSAA. Sie trennen nur die Coverage-Samples vom Rest.
Dann gäbe es kein AA auf Tegra. Eine Farbe pro Pixel erlaubt kein Anti-Aliasing. Das sollte jedem einleuchten, selbst dir.
LovesuckZ
2011-11-01, 12:49:29
Ohne echtes AA keine Subsamples. Ohne Subsamples kein CSAA. Zumindest nicht sinnvoll.
AFAIK kann Tegra von der HW her MSAA (und auch in Kombination mit CSAA).
Es gibt ein echtes Sample sowie 4 zusätzliche Coverage-Samples.
Ja und? Die Coverage Samples enthalten aber keine Farbe. Was willst du denn bitte zusammenrechnen?
Offensichtlich ist dir nichtmal klar, wie CSAA überhaupt funktioniert.
LovesuckZ
2011-11-01, 12:56:19
Ja und? Die Coverage Samples enthalten aber keine Farbe. Was willst du denn bitte zusammenrechnen?
Offensichtlich ist dir nichtmal klar, wie CSAA überhaupt funktioniert.
Ich habe davon überhaupt nichts geschrieben. :rolleyes:
Und wir wissen, dass Tegra 1 + 2 über kein echtes (MS)AA verfügt. Tu also nicht so, ob du der Alleinwisser hier bist.
Du hast behauptet:
nVidia verwendet nichts von den Nachbar-Pixel bei CSAA. Sie trennen nur die Coverage-Samples vom Rest.
Es gibt mit nur einem Color-Sample pro Pixel aber kein AA. Da kannst du 1 Mio. Coverage-Samples haben, wenn sie alle auf die selbe Farbe zeigen.
Damit müssen sie auf die Farben benachbarter Pixel zurückgreifen, oder es gibt mehr als ein Color-Sample.
Es gibt übrigens nicht "Coverage-Samples" und "den Rest", sondern nur Coverage-Samples und eine Color-Storage. Ein Coverage-Sample enthält die normalen Z-Daten und statt einer Farbe einen Index auf die Color-Storage.
robbitop
2011-11-01, 13:04:20
Es gibt ein echtes Sample sowie 4 zusätzliche Coverage-Samples.
Du hast CSAA nicht verstanden. (vermutlich MSAA auch nicht)
LovesuckZ
2011-11-01, 13:34:19
Du hast behauptet:
Es gibt mit nur einem Color-Sample pro Pixel aber kein AA. Da kannst du 1 Mio. Coverage-Samples haben, wenn sie alle auf die selbe Farbe zeigen.
Und über nichts anderes ist Tegra 2 fähig.
Damit müssen sie auf die Farben benachbarter Pixel zurückgreifen, oder es gibt mehr als ein Color-Sample.
Es gibt nicht mehr als ein Color-Sample und ihr Terminus bei der Erklärung im Tegra-GPU-Whitepaper bleibt konstant zwischen SS/MSAA und CSAA:
(When anti-aliasing is enabled, a pixel region is divided into a number of sub-pixel regions that correspond to the anti-aliasing level, such as four sub-pixel regions for 4xAA, and each sub-pixel region includes a sample location that can be are used to determine polygon coverage for calculating final pixel color).
...
CSAA further optimizes the AA process by decoupling simple coverage samples from color/z/stencil/coverage samples, thus reducing bandwidth and storage costs compared to MSAA and SSAA. CSAA uses more coverage samples to calculate coverage levels of the polygons within a given pixel area, thus creating a higher quality AA effect without incurring the memory and power costs of processing additional real color and Z samples.
The GeForce GPU core in the NVIDIA Tegra 2 mobile processor supports 5x CSAA (one real sample and four coverage samples)[...]
http://www.nvidia.com/content/PDF/tegra_white_papers/Bringing_High-End_Graphics_to_Handheld_Devices.pdf
Ich habe hier kein Bezug darauf genommen, ob es sich um "echtes" AA handelt oder ob es sinnvoll ist. Das nVidia CS"AA" bei nur einem Color-Sample verwenden kann, steht aber außer frage.
Das nVidia CS"AA" bei nur einem Color-Sample verwenden kann, steht aber außer frage.
Sag mal, bist du eigentlich wirklich so geistig zurückgeblieben um nicht verstehen zu können, dass es BEI EINER FARBE PRO PIXEL keine Zwischenstufen geben kann?
Nochmal die Frage an dein Hirn: Was willst du verrechnen?
Du hast offensichtlich nicht verstanden, wie CSAA funktioniert und versuchst uns hier zu belehren. Ernsthaft, ich werd hier sauer.
LovesuckZ
2011-11-01, 14:36:19
Nein, kann es nicht. EOD. Jeder mit einem minimalen technischen Verständnis wird mir da recht geben und mit dir zu diskutieren ist komplett sinnlos.
Und du brauchst mir CSAA ganz sicher nicht erklären. Versteh es lieber selber.
Dann lügt nVidia. So simpel.
Ich will dich überhaupt nicht belehren. Du scheinst nichtmal zu sehen, dass ich hier überhaupt nichts behaupte, sondern nur das wiedergebe, was nVidia über Tegra 2 veröffentlicht hat.
Sie lügen nicht. Das die Coverage innerhalb eines Pixel berechnet wird stimmt ja auch, das heißt aber noch lange nicht, dass die referenzierten Farben nicht woanders herkommen können.
Da man eh Quads rendert wäre das beispielsweise eine einfache Möglichkeit. Ein Quad hat 4 Color Samples und jedes Subpixel 5 Coverage Samples die auf diese verweisen. Irgend sowas müssen sie gebaut haben.
Captain Future
2011-11-01, 14:45:50
Anstatt dich immer darüber aufzuregen dass keiner so gut Bescheid weiß wie du, könntest du doch vielleicht mal erklären, was den anderen zum Verständnis fehlt. Schließlich ist das hier ein Forum und keine Podiumsdiskussion.
Ich verstehe das auch nicht, aber Lovesuckz hat als Beleg immerhin das Nvidia PDF, du hast nur ein "Ernsthaft, ich werd hier sauer".
Er interpretiert das NVIDIA-PDF aber mal wieder nach seinem Gusto und lässt erst überhaupt keine anderen Erklärungen zu.
Eine reelle Diskussion ist mit ihm einfach nicht möglich. War sie noch nie, wird sie nie sein.
Captain Future
2011-11-01, 15:13:25
Also ich hab jetzt mal in das PDF von oben reingeschaut und nach CSAA gegooglet.
Bei Nvidia steht:
"MSAA reduces the shader overhead of this operation by decoupling shaded samples from stored color and coverage; this allows applications using antialiasing to operate with fewer shaded samples while maintaining the same quality color/z/stencil and coverage sampling. CSAA further optimizes this process by decoupling coverage from color/z/stencil, thus reducing bandwidth and storage costs."
Du sagst, wir haben nur eine Farbe pro Pixel und das deswegen CSAA nicht funktioniert. Aber warum nicht? Wenn das Pixel, sagen wir, die Farbe Schwarz hat (das eine Color-Sample) hat und eine Coverage von 25%, könnte man dann nicht einfach ein 25% grau daraus schließen?
Die Coverage ist Pro Sample entweder ganz oder gar nicht, da gibt es keine Prozent.
Und selbst wenn, woher bildest du dir da das weiß ein?
Captain Future
2011-11-01, 15:36:47
Und wo ist der Unterschied? Wenn eins von vier Coverage Samples nun eine 1 hat und die drei anderen eine 0? Dann haben wir die Pixelfarbe klassisch berechnet wie sonst auch (das muss ja gehen, da das Rendering ansich ja funktioniert, oder?) und eben eine Farbabstufung von 25% - keine Ahnung wie das gemacht wird, wohl ähnlich wie bei Multisampling, oder? Da werden ja auch mehrere Abstufungen gebildet mit nur einem Color-Sample.
Tesseract
2011-11-01, 15:38:58
Du sagst, wir haben nur eine Farbe pro Pixel und das deswegen CSAA nicht funktioniert. Aber warum nicht? Wenn das Pixel, sagen wir, die Farbe Schwarz hat (das eine Color-Sample) hat und eine Coverage von 25%, könnte man dann nicht einfach ein 25% grau daraus schließen?
und was, wenn der hintergrund grün ist? das funktioniert so nicht.
damit du aus dem schwarz 25% grau machen kannst muss zumindest ein farbsample nicht auf das schwarz treffen sondern daneben und z.B. weiß ergeben - vorher kannst du das grau nicht mischen.
wenn ein coverage sample nicht auf das schwarz trift weißt du, dass du ein kantenpixel hast (bzw. wieviel % vom pixel hintergrund sind, je mehr samples umso genauer), aber du weißt nix über den hintergrund und kannst daher nichts mischen.
Captain Future
2011-11-01, 15:49:28
Ich habe jetzt noch weiter gelesen.
http://alt.3dcenter.org/artikel/multisampling_anti-aliasing/index3.php
"Beenden wir den Ausflug in die Optimierung-Strategien und verfolgen nun den Weg der Subpixel durch eine einzelne Pipeline. ... Sie erzeugt letztlich ein Textur-Sample, das für alle Subpixel gilt. Beim Multisampling gibt´s für jedes Subpixel einen eigenen Framebuffer. ... Beim Downfiltering werden alle vier Framebuffer gelesen und die Farbwerte gemittelt, um die finale Pixelfarbe zu bekommen. Hier ensteht dann auch die Glättung der Kanten."
CSAA klingt für mich so, als würde es genauso funktionieren, nur eben nicht mit Buffern, sondern Wahr/Falsch-Werten (0 und 1 meinetwegen). Woher weiß man denn beim Multisampling die Hintergrundfarbe?
Und wo ist der Unterschied? Wenn eins von vier Coverage Samples nun eine 1 hat und die drei anderen eine 0? Dann haben wir die Pixelfarbe klassisch berechnet wie sonst auch (das muss ja gehen, da das Rendering ansich ja funktioniert, oder?) und eben eine Farbabstufung von 25% - keine Ahnung wie das gemacht wird, wohl ähnlich wie bei Multisampling, oder? Da werden ja auch mehrere Abstufungen gebildet mit nur einem Color-Sample.
Vorsicht. Multisampling hat mehrere Color-Samples im Framebuffer. Da unterscheidet es sich überhaupt nicht von Supersampling. Es wird nur per Pixel nur ein Farbwert per Dreieck im Shader berechnet. Es können aber mit mehreren Dreiecken trotzdem bei bspw. 4x Multisampling vier verschiedene Farben für einen Pixel vorliegen. (Daher kommt auch deine "Hintergrundfarbe").
CSAA hat weniger Farben als Coverage-Samples im Framebuffer. Die Coverage-Samples indizieren diese Farben. Und am Ende werden die Farben anteilsmäßig nach der Anzahl ihrer Referenzen verrechnet. Wenn du nur eine Farbe hast gibt es aber nichts zu verrechnen. Da kannst du wie gesagt eine Mio. Coverage-Samples nehmen. Sie würden alle auf diese eine Farbe verweißen und man hätte keine Abstufungen.
Captain Future
2011-11-01, 15:58:03
Und woher kommen die, wenn bei MSAA auch nur ein Color-Sample genutzt wird?
Das habe ich bereits geschrieben. Mehrere Dreiecke pro Pixel.
Captain Future
2011-11-01, 16:04:54
Ja, das war noch nicht zu sehen, als ich auf den Antworten-Button geklickt habe.
Können diese Farb-Referenzen dann aus angrenzenden Pixeln gewonnen werden? So wie bei der Geforce 3 im Multisampling, wenn ich euren Antialiasing-Artikel den ich oben verlinkt habe richtig vertsehe?
http://alt.3dcenter.org/images/multisampling_anti-aliasing/spnv2025.gif
Das war doch gerade meine Vermutung, dass NVIDIA bei Tegra irgendwie die Farben der benachbarten Pixel bei CSAA mit verwendet.
Aber das lehnte LovesuckZ ja kategorisch ab.
Tesseract
2011-11-01, 16:06:18
im prinzip kann man schon AA nur mit coverage samples machen indem man sie nur für die deckungsprüfung nutzt und dann einfach das fragment anteilsmäßig mit dem alten framebufferwert verrechnet. schöner als postprocessing-AA ist das sicher in vielen fällen aber in ungünstigen hagelt es dann wohl artefakte durchs bild.
Müsste man dafür die Dreiecke nicht strikt von hinten nach vorne zeichnen wie bei Edge-Anti-Aliasing?
Tesseract
2011-11-01, 16:10:01
ja, oder man nimmt halt fehler in kauf. wenn das alte pixel im framebuffer eines ist, dass 100% aller coverage-tests bestanden hat müsste das ergebnis stimmen und das trifft wohl auf viele pixel zu so lange die geometrie grob ist.
LovesuckZ
2011-11-01, 16:11:38
Er interpretiert das NVIDIA-PDF aber mal wieder nach seinem Gusto und lässt erst überhaupt keine anderen Erklärungen zu.
Eine reelle Diskussion ist mit ihm einfach nicht möglich. War sie noch nie, wird sie nie sein.
Ich interpretiere dort überhaupt nichts rein. Im Grunde bist du es, der mehr aus dem PDF herausliest als ich. nVidia ist sehr eindeutig mit der Wortwahl und vorallem mit der Anzahl der verwendeten "real samples". Du bezeichnest mich als geistig zurückgeblieben, weil ich genau das auch so behaupte. Vielleicht bist du der jenige, der das "NVIDIA-PDF aber mal wieder nach seinem Gusto" interpretiere?
Ansonsten wäre es wesentlich sinnvoller mit dem zu argumentieren, dass ebenfalls von nVidia kommt - z.B. deren Eintrag in die (embedded) OpenGL Spezifikationen, u.a das:
Coverage sampling adds an additional high-precision geometric
coverage buffer to the framebuffer, which is used to produce
high-quality filtered results (with or without the presence of a
multisample buffer).
http://www.khronos.org/registry/egl/extensions/NV/EGL_NV_coverage_sample.txt
Coverage sampling may be used simultaneously
with multisampling; however, this is not required.
http://developer.download.nvidia.com/tegra/docs/tegra_gles2_development.pdf
Was soll's: Deine einzige Antwort wird sowieso wieder mal eine "geistige Behinderung" in meine Richtung sein, weil ich in die beiden Einträge "mehr hineininterpretiere" als dort wäre.
So what, es geht nicht, trotz der Behauptung von nVidia.
im prinzip kann man schon AA nur mit coverage samples machen indem man sie nur für die deckungsprüfung nutzt und dann einfach das fragment anteilsmäßig mit dem alten framebufferwert verrechnet. schöner als postprocessing-AA ist das sicher in vielen fällen aber in ungünstigen hagelt es dann wohl artefakte durchs bild.
Das ist dann genau das, was mit sehr feiner Geometrie ala Linie geschieht.
Ach schade, jetzt hatten wir gerade eine sinnvolle Diskussion und dann kommt der wieder.
LovesuckZ
2011-11-01, 16:20:21
Es tut mir leid, aber ich wollte nur nochmal Bezug auf die Ausgangsfrage nehmen. Okay, die Einträge belehren dich auch, aber entschuldige dieses Verhalten von mir, das dich so wütend macht. Ohne die Einträge und Verlinkung hätte ich nicht genauer darauf eingehen können.
Achja: CSAA ist ohne MS/SSAA möglich. Vielleicht sollte ich mir das in meine Signatur packen?
/edit: Vielleicht interessiert es ja dem einen - ein Bild aus Quake 3 mir 5xCSAA auf Tegra 1: http://www.hotchips.org/archives/hc20/2_Mon/HC20.25.331.pdf (Folie 13)
Gipsel
2011-11-01, 17:25:33
Also, denken wir mal nach.
Allgemein:
Pixel wird gerendert, generiert einen Farbwert, einen Z-Wert (beide haben eine Auflösung von einem Wert pro Pixel) und 4 Coverage-Bits pro Pixel, die mit den alten Werten im Z-, Frame- bzw. Coveragebuffer verglichen/geblendet werden.
Nomenklatur:
alt - bisherige Werte im Buffer
aktuell - Werte des gerade gerenderten Pixels
neu - neuer Wert im Buffer nach Update (neue Coverage Maske ergibt sich immer durch ein AND OR natürlich zwischen alter und aktueller)
Komplett ohne Artefakte wird das nicht abgehen, aber machen wir mal ein paar Szenarien auf:
(I)
Es steht noch kein Wert in den Buffern (Coverage komplett 0) => Pixel setzt Color-, Z- und Coverage-Werte
(II)
Es steht schon ein Wert mit voller Coverage im Framebuffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte => aktuelles Pixel wird verworfen
2) der aktuelle Z-Wert liegt näher zum Betrachter
2a) aktuelle Coverage ist ebenfalls voll => aktueller Farbwert ersetzt den alten
2b) teilweise Coverage => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der Coverage des aktuellen Pixels
(III)
Es steht bereits ein Wert mit teilweiser Coverage im Frame-Buffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte
1a) aktuelle Coverage erfaßt keinen unbelegten Subpixel => aktueller Pixel wird verworfen
1b) aktuelle Coverage erfaßt unbelegte Subpixel => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der durch den aktuellen Pixel hinzukommenden (im Vergleich zur alten bestehenden) Coverage des Pixels
2) der aktuelle Z-Wert liegt näher zur Kamera
2a) aktuelle Coverage ist voll => aktueller Farbwert ersetzt den alten
2b) aktuelle Coverage ist nur teilweise => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der aktuellen Coverage (im Vergleich zu der vom alten Wert übrig bleibenden/nicht "ersetzten")
Hmm, könnte meist halbwegs passabel funktionieren oder nicht? Die Blendingregeln und -gewichte lassen sich recht einfach aus dem Vergleich der Z-Werte und den beiden 4 Bit-Masken erzeugen (eine paar logische Verknüpfungen und 4 Bit SetBitCounts und man ist fertig), sollte also kein großes Problem sein.
Falls das so funktioniert, wäre das allerdings schon anders, als CSAA auf "normalen" GPUs.
LovesuckZ
2011-11-01, 17:43:22
Laut nVidia ist es auch eine Erweiterung des CSAA von den Geforce-GPUs ("Mobile Version"). Deswegen wohl auch die unterschiedlichen Einträge in der EGL und GL-Spezifikationsbeschreibung.
Captain Future
2011-11-01, 17:54:30
Also, denken wir mal nach.
Allgemein:
Pixel wird gerendert, generiert einen Farbwert, einen Z-Wert (beide haben eine Auflösung von einem Wert pro Pixel) und 4 Coverage-Bits pro Pixel, die mit den alten Werten im Z-, Frame- bzw. Coveragebuffer verglichen/geblendet werden.
Nomenklatur:
alt - bisherige Werte im Buffer
aktuell - Werte des gerade gerenderten Pixels
neu - neuer Wert im Buffer nach Update (neue Coverage Maske ergibt sich immer durch ein AND zwischen alter und aktueller)
Komplett ohne Artefakte wird das nicht abgehen, aber machen wir mal ein paar Szenarien auf:
(I)
Es steht noch kein Wert in den Buffern (Coverage komplett 0) => Pixel setzt Color-, Z- und Coverage-Werte
(II)
Es steht schon ein Wert mit voller Coverage im Framebuffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte => aktuelles Pixel wird verworfen
2) der aktuelle Z-Wert liegt näher zum Betrachter
2a) aktuelle Coverage ist ebenfalls voll => aktueller Farbwert ersetzt den alten
2b) teilweise Coverage => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der Coverage des aktuellen Pixels
(III)
Es steht bereits ein Wert mit teilweiser Coverage im Frame-Buffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte
1a) aktuelle Coverage erfaßt keinen unbelegten Subpixel => aktueller Pixel wird verworfen
1b) aktuelle Coverage erfaßt unbelegte Subpixel => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der durch den aktuellen Pixel hinzukommenden (im Vergleich zur alten bestehenden) Coverage des Pixels
2) der aktuelle Z-Wert liegt näher zur Kamera
2a) aktuelle Coverage ist voll => aktueller Farbwert ersetzt den alten
2b) aktuelle Coverage ist nur teilweise => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der aktuellen Coverage (im Vergleich zu der vom alten Wert übrig bleibenden/nicht "ersetzten")
Hmm, könnte meist halbwegs passabel funktionieren oder nicht? Die Blendingregeln und -gewichte lassen sich recht einfach aus dem Vergleich der Z-Werte und den beiden 4 Bit-Masken erzeugen (eine paar logische Verknüpfungen und 4 Bit SetBitCounts und man ist fertig), sollte also kein großes Problem sein.
Falls das so funktioniert, wäre das allerdings schon anders, als CSAA auf "normalen" GPUs.
Ja, so verstehe auch ich, wie das funktionieren könnte. Danke für die Erklärung.
II, 2b und III, 1b und 2b meinte ich übrigens oben.
Spasstiger
2011-11-01, 22:18:55
@Gipsel: Nach deinem Ansatz, den ich für durchaus denkbar halte, wird bei (Geometrie-)Kantenpixeln im Endeffekt doch mehr als ein Farbwert pro Pixel ermittelt. Der Unterschied zum MSAA läge im Resolve und im Speicherbedarf (keine MSAA-Buffer erforderlich).
Das ist quasi MSAA-Emulation für Hardware, die kein MSAA beherrscht oder auf der MSAA aufgrund des Speicherbedarfs oder aufgrund mangelhafter Resolve-Möglichkeiten in den ROPs oder Shadern effektiv nicht nutzbar ist.
Ailuros
2011-11-02, 08:17:28
Die PowerVR SGX (Galaxy S1) können dafür echtes MSAA, mit Chainfire3D sogar für jedes Spiel foricerbar. Der Mali vom SII angeblich sogar ohne Performanceverlust (zumindest hört man das von vielen SII Besitzern. Kann aber auch sein, dass die Performance hoch genug ist, und man deswegen den Verlust nicht merkt)
Mali behauptete schon seit sie noch eigenstaendig waren dass ihre tile based Architektur ueber single cycle 4xMSAA faehig ist. Bei single cores koennte es sein dass es nicht so ganz hinhaut. Ich hab leider nicht die blasseste Ahnung ueber wieviel z/stencil der Mali400MP4 im Exynos verfuegt. Der core besteht aus vier fragment cores (4 Vec4 FP16 PS ALUs), einem VS (1 Vec2 FP32 VS ALU) und 4 TMUs (1 TMU stets pro fragment core). Unter normalen Umstaenden wuerde ich mir vorstellen dass es auch 8 z/stencil pro fragment core sind. In dem Fall bei 32 z/stencil * 267MHz hat das Ding eine z/stencil Fuellrate von 8.5 GPixels/s.
In der Mehrzahl der Faelle haben embedded GPUs 8 z/stencil pro core; einzige Ausnahme sind die SGX543/544/554/545 die ueber 16 z/stencil pro core verfuegen. SGX cores die ueber nur 8 z/stencil verfuegbaren, haben einen groesseren Verlust als die vorerwaehnten Varianten, u.a. weil die Anzahl der z/stencil Einheiten limitiert. Tegras haben auch 8 z/stencil.
Alle tile based embedded GPUs (PowerVR, Mali, Adreno) unterstuetzen Multisampling und der Verlust fuer 4xMSAA ist in der Mehrzahl der Faelle gering von den bisherigen Messungen die ich gesehen habe (=/<10%). Da es aber generell an timedemos bzw. framecounters in mobilen Spielen fehlt, leg ich auch nicht meine Hand ins Feuer dass es immer und ueberall so ist. Eines der Gruende ist dass lower end Zeug wie OpenVG regelrecht nach antialiasing schreit und in dem Fall sind 4x samples bei weitem nicht genug. Malis unterstuetzen bis zu 16xMSAA, aber es kommt auch mit einem sehr hohen Verlust an Fuell-rate.
NV's Tegra ist eben nicht tile based und in solch einem Fall wuerde es einiges an Bandbreite bzw. Speicher kosten fuer Multi-sampling. Da sie ohnehin schon CSAA fuer den desktop hatten, haben sie einfach den dementsprechenden Algorithmus fuer embedded angepasst. CSAA kostet zwar nicht viel (oder fast gar nichts) auf Tegra, bringt aber auch keine vergleichbares anti-aliasing zu Multisampling und schon gar nicht 4x MSAA.
robbitop
2011-11-02, 09:09:58
Ich habe bei Anand gelesen, dass Adreno kein TBDR ist. Die sagten was von Tile Based - aber zwischen IMR und TBDR. Klingt für mich nach ner herkömmlichen GPU. Die arbeiten mit HSR und schreiben auch Tiles in den Framebuffer. Das war halt die Evolution der IMRs.
Aber ein wasch-echter TBDR? Ist Mail das? Ist Adreno das? (GMA9xx war einer - wenn auch ein schlechter) Ist SGX das überhaupt noch?
Bei SGX sehe ich bei normiert gleicher Rohleistung der Konkurrenz (Tegra, Adreno, Mali) keinen TBDR Vorsprung mehr. Die sind in etwa (wenn man die FPS in Benchmarks auf gleiche Rohleistung umrechnet) gleich schnell.
Zum "CSAA":
Würde das Verfahren nicht nur bei striktem Back-to-Front Rendering funktionieren? Bye-bye HSR und Effizienz!!
IMO ist es echt schlimm, was heute sich "AntiAliasing" schimpfen darf! Ohne echtes Mehrinformationen kann Aliasing nicht immer wirkungsvoll reduziert werden. Schlimmer noch, es verfälscht an genug Stellen.
Echtes AA wird immer kosten. Je besser desto teurer. (SGSSAA + guter Downsampling Filter ala CFAA - das ist AA!)
Ail sprach ja auch von Tile Based Renderer, das ist nicht das gleiche wie Tile Based Deferred Renderer.
Was gleich ist, ist das die Szene zunächst transformiert und in die Tiles eingeteilt wird. Ein TBR rendert dann ganz normal jedes Tile mit Forward Rendering in der gleichen Reihenfolge wie sonst auch (mit Overdraw). Ein TBDR entfernt vor dem Rendering für jedes Tile die nicht sichtbare Geometrie.
Beide Verfahren haben aber den Vorteil, dass sie beim Rendering keinerlei externe Bandbreite brauchen (außer für's rausschreiben danach), wodurch MSAA praktisch umsonst wird.
Soweit ich weiß baut nur PowerVR TBDRs, auch GMA900 war nur ein TBR.
robbitop
2011-11-02, 10:09:40
Klar.
Aber wo liegt der Vorteil darin, ohne vorgezogenes HSR, das Bild in Kacheln vor dem Rendern aufzuteilen? So muss ich Dreiecke, die auf mehreren Tiles liegen (Randdreiecke) sogar mehrfach betrachten.
Spart wie gesagt sehr viel externe Bandbreite. Außerdem kann man dann auch paralleles Rasterizing machen wie Larrabee, wobei das bei den SoCs keine Rolle spielen sollte.
Gipsel
2011-11-02, 11:24:18
@Gipsel: Nach deinem Ansatz, den ich für durchaus denkbar halte, wird bei (Geometrie-)Kantenpixeln im Endeffekt doch mehr als ein Farbwert pro Pixel ermittelt. Der Unterschied zum MSAA läge im Resolve und im Speicherbedarf (keine MSAA-Buffer erforderlich).Nun ein Farbwert pro Pixel und (möglicherweise sichtbarem, also nicht per early-Z verworfenem) Dreieck. Unter das kommst Du bei einem Immediate Mode Renderer schwerlich.
Zum "CSAA":
Würde das Verfahren nicht nur bei striktem Back-to-Front Rendering funktionieren? Bye-bye HSR und Effizienz!!
Das sollte unabhängig von der Renderreihenfolge funktionieren. Ich habe nicht umsonst alle möglichen Fälle in Abhängigkeit auch vom Z-Wert aufgeführt ;)
Gibt halt unter Umständen dann mehr oder weniger deutlich sichtbare Artefakte.
robbitop
2011-11-02, 12:02:13
Spart wie gesagt sehr viel externe Bandbreite. Außerdem kann man dann auch paralleles Rasterizing machen wie Larrabee, wobei das bei den SoCs keine Rolle spielen sollte.
Spart es externe Bandbreite, weil man den Inhalt des Tiles, der gerade gerendert wird, in den Tilebuffer schreiben (u. lesen) kann statt in den externen VRAM und erst wenn das Tile komplett ist in den VRAM?
Das ist ja einer der Hauptvorteile des TBDRs. Ich vermute mal, dass aktuelle Engines recht gut vorsortieren und das HSR eines IMRs eh das meiste herausfischen kann. Anders gefragt: Folgt daraus, dass ein TDBR heutzutage gar keinen großen Vorteil mehr ggü. einem IMR hat, wenn die Rechenleistung gleich ist?
Spart es externe Bandbreite, weil man den Inhalt des Tiles, der gerade gerendert wird, in den Tilebuffer schreiben (u. lesen) kann statt in den externen VRAM und erst wenn das Tile komplett ist in den VRAM?
Bitte nochmal.
robbitop
2011-11-02, 15:02:14
Bitte nochmal.
Ich stelle es mir so vor:
Ein herkömmlicher IMR liest und schreibt ständig auf den VRAM (Framebuffer und alle möglichen Buffer). Es wird mehrfach pro Pixel zugegriffen (lesen & schreiben) und die Zugriffe sind sehr fragmentiert (durch Caches sicher etw abgefedert).
Bedeutet hoher Bandbreitenaufwand.
Ein Deferedrenderer teilt die Szene in Kacheln auf und rendert Kachel für Kachel fertig. Hintereinander. Für eine Kachel bräuchte es nur wenig Speicher. Das geht On-Die.
Da er nur Kachel für Kachel rendert, könnte er viele Lese und Schreibzugriffe (zumindest Framebuffer) auf in diesen Tilecache durchführen, statt immer auf den VRAM zuzugreifen.
Wenn das Tile fertig gerendert ist, kann der gesamte Tilecache 1x in den VRAM geschoben werden.
Bedeutet niedrigerer Bandbreitenaufwand.
Man spart sich halt viele FB Zugriffe. Das wäre auf jeden Fall einer der Hauptvorteile eines TBDR gewesen.
Nachteil: Randdreiecke, die sich auf mehreren Tiles befinden, müssen mehrfach gerendert werden.
Stimmt das so in etwa?
Falls ja und falls aktuelle Engines sehr gute Vorsortierung der Objekte haben, erklärt das, dass ein TBDR wie SGX bei gleicher Rechenleistung wie die Konkurrenz nicht wirklich schneller ist.
Ja stimmt. Außerdem hat man halt den zusätzlichen Aufwand für's Binning.
Und ja, bei modernen Engines (mit z-pre-pass oder deferred renderern) ist TBDR nicht mehr so ein eindeutiger Win.
robbitop
2011-11-02, 15:39:33
Dann wäre das sicher ein guter Ansatz für AMD/Intel für APUs. (und sicher auch für SoCs von Konsolen) Die leiden ja immer an knapper externen Bandbreite. Ich würde sogar darauf tippen, dass die GPU von Sandy das bereits im LLC tut. (oder meinst du, dass bereits eh alle aktuellen GPUs das so tun?)
Also, denken wir mal nach.
Allgemein:
Pixel wird gerendert, generiert einen Farbwert, einen Z-Wert (beide haben eine Auflösung von einem Wert pro Pixel) und 4 Coverage-Bits pro Pixel, die mit den alten Werten im Z-, Frame- bzw. Coveragebuffer verglichen/geblendet werden.
Nomenklatur:
alt - bisherige Werte im Buffer
aktuell - Werte des gerade gerenderten Pixels
neu - neuer Wert im Buffer nach Update (neue Coverage Maske ergibt sich immer durch ein AND OR natürlich zwischen alter und aktueller)
Komplett ohne Artefakte wird das nicht abgehen, aber machen wir mal ein paar Szenarien auf:
(I)
Es steht noch kein Wert in den Buffern (Coverage komplett 0) => Pixel setzt Color-, Z- und Coverage-Werte
(II)
Es steht schon ein Wert mit voller Coverage im Framebuffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte => aktuelles Pixel wird verworfen
2) der aktuelle Z-Wert liegt näher zum Betrachter
2a) aktuelle Coverage ist ebenfalls voll => aktueller Farbwert ersetzt den alten
2b) teilweise Coverage => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der Coverage des aktuellen Pixels
(III)
Es steht bereits ein Wert mit teilweiser Coverage im Frame-Buffer
1) der aktuelle Z-Wert liegt weiter entfernt als der alte
1a) aktuelle Coverage erfaßt keinen unbelegten Subpixel => aktueller Pixel wird verworfen
1b) aktuelle Coverage erfaßt unbelegte Subpixel => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der durch den aktuellen Pixel hinzukommenden (im Vergleich zur alten bestehenden) Coverage des Pixels
2) der aktuelle Z-Wert liegt näher zur Kamera
2a) aktuelle Coverage ist voll => aktueller Farbwert ersetzt den alten
2b) aktuelle Coverage ist nur teilweise => neuer Farbwert ergibt sich aus Blending des aktuellen mit dem alten entsprechend der aktuellen Coverage (im Vergleich zu der vom alten Wert übrig bleibenden/nicht "ersetzten")
Hmm, könnte meist halbwegs passabel funktionieren oder nicht? Die Blendingregeln und -gewichte lassen sich recht einfach aus dem Vergleich der Z-Werte und den beiden 4 Bit-Masken erzeugen (eine paar logische Verknüpfungen und 4 Bit SetBitCounts und man ist fertig), sollte also kein großes Problem sein.
Falls das so funktioniert, wäre das allerdings schon anders, als CSAA auf "normalen" GPUs.Das wäre praktisch Z3-AA mit nur einem Farbwert, also "Z1-AA". Habe ich schon mal drüber nachgedacht und als Unsinn verworfen, da zu anfällig für falsche Zwischenfarben. Würde gerne mal AA-Bilder von diesem Tegra sehen.
LovesuckZ
2011-11-02, 18:07:23
Würde gerne mal AA-Bilder von diesem Tegra sehen.
Folie 13: http://www.hotchips.org/archives/hc20/2_Mon/HC20.25.331.pdf
Mehr gibt es anscheinend nicht...
Das letzte mal als Nvidia Quake 3 zur AA-Demonstration nutzte, war das für Quincunx auf der Geforce 3 :freak:
Wenn der Himmel zuerst gerendert wird, kann diese Säule in dieser Position auch brauchbare Ergebnisse zeigen. Die Frage ist natürlich wie es aussieht, wenn in falscher Reihenfolge gerendert wird. Wenn das so funktioniert wie ich denke, funktioniert das Tegra-AA solange nur zwei Dreiecke im Pixel sind und Dreiecke von hinten nach vorne sortiert gerendert werden.
Gipsel
2011-11-02, 20:27:56
Das letzte mal als Nvidia Quake 3 zur AA-Demonstration nutzte, war das für Quincunx auf der Geforce 3 :freak:
Wenn der Himmel zuerst gerendert wird, kann diese Säule in dieser Position auch brauchbare Ergebnisse zeigen. Die Frage ist natürlich wie es aussieht, wenn in falscher Reihenfolge gerendert wird. Wenn das so funktioniert wie ich denke, funktioniert das Tegra-AA solange nur zwei Dreiecke im Pixel sind und Dreiecke von hinten nach vorne sortiert gerendert werden.
Von vorne nach hinten geht auch. Und die Grenze bei 4 Coverage-Samples liegt auch bei 4 Dreiecken/Pixel. Es kann schon Artefakte geben, aber die sind bei back-to-front-Rendering sogar potentiell größer (weil mehr Dreiecke zur Pixelfarbe beitragen können, als am Ende überhaupt zu sehen sind) und bei striktem front-to back treten bei richtiger Implementation sogar gar keine auf ;)
Edit:
Die schlimmsten Artefakte dürften aber beim ungeordneten Rendern auftreten, weil der Z-Test dann (partiell) versagen kann. Solange aber die Geometrie recht grob ist, dürfte es akzeptabel sein.
PCGH_Carsten
2011-11-03, 12:16:53
Da man das „spezielle“ CSAA vom Tegra als Entwickler aber explizit anfordern muss, sollte das in der Praxis nur ein kleines Problem sein. Entweder, du richtest deine Anwendung darauf aus und es funktioniert, oder eben nicht (aber dann wirst du es wahrscheinlich eh gar nicht erst einbauen).
Wäre es nachträglich per Control Panel erzwingbar wie bei Desktop-Grafik, wäre das sicherlich problematischer.
LovesuckZ
2011-11-03, 12:25:50
Wäre es nachträglich per Control Panel erzwingbar wie bei Desktop-Grafik, wäre das sicherlich problematischer.
Es wäre interessant zu sehen, ob man CSAA per extra Tool ala Chainfire erzwingen könnte.
Dann wäre das sicher ein guter Ansatz für AMD/Intel für APUs. (und sicher auch für SoCs von Konsolen) Die leiden ja immer an knapper externen Bandbreite. Ich würde sogar darauf tippen, dass die GPU von Sandy das bereits im LLC tut. (oder meinst du, dass bereits eh alle aktuellen GPUs das so tun?)
Soweit ich weiß sind die aktuellen Intel-GPUs traditionelle IMRs. Der große Cache dahinter federt wohl aber sowieso viel ab.
Von vorne nach hinten geht auch. Und die Grenze bei 4 Coverage-Samples liegt auch bei 4 Dreiecken/Pixel. Es kann schon Artefakte geben, aber die sind bei back-to-front-Rendering sogar potentiell größer (weil mehr Dreiecke zur Pixelfarbe beitragen können, als am Ende überhaupt zu sehen sind) und bei striktem front-to back treten bei richtiger Implementation sogar gar keine auf ;)
Edit:
Die schlimmsten Artefakte dürften aber beim ungeordneten Rendern auftreten, weil der Z-Test dann (partiell) versagen kann. Solange aber die Geometrie recht grob ist, dürfte es akzeptabel sein.
Habe ich einen Denkfehler? Angenommen wir haben 4 C-Samples. Ein weißes Dreieck bedeckt das Pixel vollständig. Nun kommt ein neues Dreieck welches 1 C-Sample bedeckt, aber schwarz ist. Die Farbe wird nun auf 75% Grau gesetzt.
Jetzt kommt wiederum ein schwarzes Dreieck, welches eines der vier C-Samples bedeckt. Die neue Pixelfarbe ist dann ungefähr 56% Grau. Richtig wären 50% Grau oder weiterhin 75% Grau (fall dasselbe Coverage-Sample bedeckt wird, was das AA aber glaube ich an der Stelle nicht wissen kann.)
Wenn pro Sample nur Coverage geprüft wird und Z nur 1x pro Pixel, funktioniert das AA eh nur an Dreiecksrändern und nicht beim Sich-gegenseitig-Durchdringen (es sei denn ich mache gerade wieder einen Denkfehler.)
Gipsel
2011-11-03, 15:05:48
Jetzt kommt wiederum ein schwarzes Dreieck, welches eines der vier C-Samples bedeckt. Die neue Pixelfarbe ist dann ungefähr 56% Grau. Richtig wären 50% Grau oder weiterhin 75% Grau (fall dasselbe Coverage-Sample bedeckt wird, was das AA aber glaube ich an der Stelle nicht wissen kann.)Solange Du strikt sortiert renderst (egal ob von vorne oder von hinten) ist das Ergebnis des Z-Tests korrekt, das AA weiß also zumindest das genau.
Für Deinen Fall hast Du also ein 75% grau Pixel und es kommt ein zusätzliches schwarzes Subpixel dazu. Je nach Ergebnis des Z-Tests bleibst Du entweder bei 75% (front-to-back-Fall, der ist also korrekt, wie ich schon schrieb ;)), oder bei 56% (back-to-front-Fall), was eben gewissermaßen ein Artefakt ist, da man nicht mehr weiß, welches Subpixel (also ein weißes oder ein schwarzes) verdeckt ist und auch die Sache mit der Gewichtung dadurch nicht perfekt, sondern nur noch gemittelt funktioniert (und wie oben geschrieben dazu führen kann, daß mehr Dreiecke Farbwerte zum Pixel beitragen können, als eigentlich sein sollte, der Grund ist immer der selbe, nämlich die Unmöglichkeit nur mit der Coverage Maske alleine ohne dazugehörige Color-/Z-Werte die Verdeckung und Farbe subpixelgenau festzuhalten). Das Resultat ist wie erwähnt, daß es bei back-to-front-Rendering mehr Artefakte gibt als bei Front-to-back (da kann man die Mittelung mathematisch korrekt ausführen). Aber da Letzteres sowieso effizienter ist (zumindest für IMRs) und deswegen von den meisten Engines über eine Sortierung angestrebt wird, sehe ich kein größeres Problem.
Wenn pro Sample nur Coverage geprüft wird und Z nur 1x pro Pixel, funktioniert das AA eh nur an Dreiecksrändern und nicht beim Sich-gegenseitig-Durchdringen (es sei denn ich mache gerade wieder einen Denkfehler.)Ja.
Edit:
Der Trick beim front-to-back-Rendering ist, daß die Coverage-Masken komplett ungesetzt starten. Bei einem voll belegten Pixel tragen also alle weiteren Dreiecke nicht mehr bei (können also das Ergebnis nicht verfälschen) und bei nur partiell belegten Pixeln kann man anhand der Coverage-Masken eindeutig feststellen, wie viele Subpixel mit der aktuellen Pixelfarbe dazu kommen und die Mittelung mathematisch exakt ausführen.
Beispiel:
1 Dreieck belegt 2 Subpixel eines Dreiecks mit 100% weiß. Jetzt kommt ein zweites Dreieck (was dahinter liegt, also einen größeren Z-Wert aufweist) auch mit 2 Subpixel aber komplett schwarz dazu. Durch den Vergleich der alten Coverage-Maske mit der neuen kann man eindeutig feststellen, ob die 2 schwarzen Subpixel hinter den 2 weißen liegen (sich also nichts ändert), oder 1 bzw. beide schwarze Subpixel sichtbar sind. In jedem Fall kann man die neue Pixelfarbe durch Blending mit der alten korrekt ermitteln (bleibt 100% weiß oder (2*100%+1*0%)/3 = 66,7% weiß oder (2*100%+2*0%)/4 = 50% weiß) und auch die Coverage-Maske entsprechend anpassen (ist wie gesagt einfach coverage_neu = coverage_alt OR coverage_aktuell).
Bei dem mittleren Fall hätte man dann 3 belegte Subpixel und 66,7% weiß. Wird das verbliebende vierte Subpixel danach z.B. mit einem 50% weiß belegt (mehr Subpixel gehen ja nicht mehr), ergibt sich (3*66,7% + 50%)/4 = 62,5% weiß, exakt das Ergebnis wie bei Verwendung von Multisampling (2*100% + 1*0% + 1*50%)/4 = 62,5%, also keine Artefakte.
Ailuros
2011-11-03, 17:57:12
Ja stimmt. Außerdem hat man halt den zusätzlichen Aufwand für's Binning.
Und ja, bei modernen Engines (mit z-pre-pass oder deferred renderern) ist TBDR nicht mehr so ein eindeutiger Win.
Ist zwar verdammt OT, aber ich bin auch zu faul einen extra thread darueber aufzumachen: war es denn je ein wirklich eindeutiger win? Jede Seite hatte in der Vergangenheit ihre Vor- und Nachteile und IHVs sorgen eben (egal ob DR oder IMR) dass die Nachteile im schlimmsten Fall nur in sehr seltenen Eckfaellen auftauchen.
IMHO hat ein heutiger TBDR kleinere Vor- und Nachteile als in der Vergangenheit, eben weil fuer alle Seiten Technologie sich konstant weiterentwickelt.
Eins der Vorteile vom PowerVR ist dass er auf tile level rastert; andere TBRs wenden bounding box tiling an. Es reichen ein paar sehr duenne diagonal orientierte Dreiecke aus und schon ist die Bandbreite durch die ganze herumschreiberei im Eimer auf herkoemmlichen TBRs.
Die eigentlich brennende Frage waere was sie mit Tessellation bei Rogue genau angestellt haben fuer DX11. SGX selber duerfte sogar effizienter sein als heutige desktop GPUs mit sehr kleinen Dreiecken, aber das reicht noch nicht lange nicht aus fuer programmierbare Tessellation. Und ausser ich hab wieder mal einen brainfart koennte das letztere ziemlich zum pitfall werden fuer einen TBDR wenn nicht richtig implementiert. Ist aber alles Material fuer die Zukunft da die Daten ueber kommende Architekturen noch zu gering sind.
Am Rand da es eigentlich um AA geht: CSAA ist quasi eine Art den Bandbreiten- bzw. Speicherverbrauch eines TBDR mit Multisampling zu erreichen und dieses auch bei noch hoeherer CSAA sample Anzahl. Bleibt eben noch der Qualitaets-unterschied zwischen CSAA und MSAA.
Wenn man jedoch CSAA mit MSAA kombiniert wie im desktop und man koennte wie fuer Fermi versprochen alle CSAA samples fuer transparency MSAA dazuschalten fuer foliage waere es Gold wert ueberhaupt fuer die Zukunft im embedded Bereich. Leider wurde es in den Treibern fuer GF1xx nie eingeschaltet mit der Entschuldigung dass sich keiner in benchmarks ueber CSAA schehrt.
robbitop
2011-11-04, 10:03:48
TBRs (ohne "D") haben den Vorteil auch, dass MSAA extrem günstig wäre, da alle Zugriffe ja auf dem Tile-Cache landen würden.
Ailuros
2011-11-04, 18:11:16
TBRs (ohne "D") haben den Vorteil auch, dass MSAA extrem günstig wäre, da alle Zugriffe ja auf dem Tile-Cache landen würden.
Ob D oder nicht, kommt es auch stets auf die Anzahl der verwendenten MSAA Anzahl, die Anzahl der z/stencil bzw. ROPs usw. an. Sagen wir es mal so dass momentan IHVs fuer embedded mit 4xMSAA als Ziel ihre GPUs hauptsaechlich entwickeln und die hw bzw. Anzahl der Einheiten auch dementsprechend anpassen. Natuerlich koennte ein IHV eine Architektur z.B. auf single cycle 8xMSAA trimmen (wie der OpenVG only VGX150), aber fuer eine heutige embedded GPU waere es hw Verschwendung.
Wie schon gesagt ARM Mali ist ueber 16xMSAA faehig, nur kostet es eben 3/4 der Fuellrate (da je mehr samples desto mehr tiles). Ergo der Haarspalterei zu liebe, 2x bzw. 4xMSAA ist heutzutage extrem guenstig auf jeglicher tile based Architektur. Bei mehr samples kostet es schon und sogar einiges. Ich bezweifle dass IMG auf PS Vita mehr als 4xMSAA freigeschaltet hat, aber mit den 64 z/stencil Einheiten der 4 GPU cores koennte man so manchen bunte MSAA Anzahl auf die Beine stellen wenn man Fuellrate im Ueberschuss hat.
Gipsel,
Angenommen NV wuerde mehr als nur 5xCSAA samples in der Zukunft benutzen. Wuerden sie dann wirklich echtes Multisampling kombiniert mit CSAA brauchen oder glaubst Du dass Deine Theorie auch so wie bis jetzt bei hoeherer Anzahl von coverage samples alleine geht?
Gipsel
2011-11-04, 18:41:47
Angenommen NV wuerde mehr als nur 5xCSAA samples in der Zukunft benutzen. Wuerden sie dann wirklich echtes Multisampling kombiniert mit CSAA brauchen oder glaubst Du dass Deine Theorie auch so wie bis jetzt bei hoeherer Anzahl von coverage samples alleine geht?
Aufgrund der möglichen Artefakte bringt es meiner Meinung nach nicht so viel, die CSAA-Sampleanzahl zu steigern (gehen würde es, aber die Artefakte verhindert man damit nicht).
Es ist billig (für die Hardware und die Performance) und funktioniert vielleicht in vielen Fällen halbwegs okay. Aber ab irgendeinem Punkt/Qualitätsanspruch müssen einfach mehr Color-/Z-Samples pro Pixel her. Aber es verbietet ihnen ja keiner, z.B 4xMSAA mit 16 Coverage-Samples (also 4 pro "echtem" Sample) zu kombinieren, um mehr Zwischenstufen bei der Glättung zu haben, also das wie bei den Desktop-Karten zu machen.
Ailuros
2011-11-04, 18:44:11
Ja aber bei einem hypothetischen MSAA Zuschuss waere es dann wohl auch angebrachter auf tile-based zu gehen.
nicolauz23
2012-08-02, 18:44:41
Ich hab CSAA zum laufen gebraucht auf nem TrimSlice.
Es sieht gar nicht so schlecht aus (mit MSAA kann es nicht mithalten, aber besser wie nichts)
Das Problem das ich allerdings habe ist das ich CSAA auf nem FBO brauche (der rest application benötigt kein AA)
Ich habe mir aus dieser spec:
http://www.khronos.org/registry/egl/extensions/NV/EGL_NV_coverage_sample.txt
alles zusammengesucht und es sieht ganz gut aus.
... Ich erstelle den FBO, generier mir n renderbuffer mit GL_COVERAGE_COMPONENT4_NV und attache den zum FBO mit GL_COVERAGE_ATTACHMENT_NV
Ausserdem sind nach dem binden des FBO die Werte von GL_COVERAGE_BUFFERS_NV==1 und GL_COVERAGE_SAMPLES_NV==4
Laut spec ist das genau der zustand bei dem beim rasterizing CSAA angewendet wird ... super sache ... ABER CSAA wird nicht angewendet.
... auf grund von tests weis ich wie das ergebnis aussehen wuerde ... d.h. ich bin mir 100% sicher das kein CSAA beim rasterizing genutz wird.
Irgendwer ne Idee?
p.s.:
Keine Ahnung ob das hier das richtige forum ist ... aber nvidia wird mir nicht helfen und bei CompuLab mach ich mir wenig Hoffnung das es dort jemand gibt der sich mit den nvidia treibern auskennt ;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.