Archiv verlassen und diese Seite im Standarddesign anzeigen : Besseres Multisampling?
Asmodeus
2005-01-02, 12:42:52
Vor einiger Zeit hab ich in einem anderen Thread folgendes gelesen:
...
Pixar hat z.B. AFAIK einen hauseigenen 64x sample stochastischen Algorithmus fuer FSAA und motion blur.
...
Dazu würde ich jetzt gern noch einiges wissen. Bei heutigen Grafikkarten gibt es ja inzwischen eine Menge Variationen was die Multisample-Modi anbelangt (Unterschiede in Anzahl und Anordnung der Samples). Wenn ich da richtig informiert bin stellt eine Rotated Grid Methode visuell meist einen Vorteil gegenüber einer Ordered Grid Methode dar. Allen gemeinsam ist ja aber jedoch, dass die Samples in allen "Zellen" gleich angeordnet sind. Bei einer wie auch immer gearteten "stochastischen Methode" wäre dies ja nicht der Fall. Oder ist mit dem "stochastischen Algorithmus" etwas ganzt anderes gemeint? Aber was würde das für Vorteile bringen, und welche Nachteile handelt man sich damit eventuell ein? Und dann würde mich noch interessieren, was zum jetzigen Zeitpunkt implementationstechnisch dagegen spricht, sagen wir mal ein 4- oder 8-faches "stochastisches" Multisampling in Grafikkarten zu integrieren (Schaltungsaufwand ?, Bandbreitenverlust ? usw.)
Gruss, Carsten.
"Stochastisches" Multisampling ist nach meinem Dafürhalten ein Irrweg. Es lohnt erst ab 16, eher ab 32 Samples, sonst wird das Rauschen zu stark. Man kann aber mit einer "sparsed" Maske schon mit 8 Samples hervorragende Glättung erzeugen.
Asmodeus
2005-01-02, 22:32:06
"Stochastisches" Multisampling ist nach meinem Dafürhalten ein Irrweg. Es lohnt erst ab 16, eher ab 32 Samples, sonst wird das Rauschen zu stark. Man kann aber mit einer "sparsed" Maske schon mit 8 Samples hervorragende Glättung erzeugen.
Ist denn bekannt, wie mit so einer stochastischen Sampleanordnung gearbeitet wird? Wirs sie einmal erzeugt und dann einfach immer verwendet, oder anders gefragt, wird sie geupdatet und wenn ja, wann, pro Frame, einmal pro Sekunde, oder ist sie eben konstant?
Und gilt die stochasitsche Verteilung eben nur pro "Zelle" (also alle Subpixel eines Pixels) und alle Zellen besitzen dann wieder die gleiche Sampleverteilung, oder gilt die stochastische Verteilung über alle Zellen? Und wie wäre es, wenn man eine Sampleverteilung hätte, welche die Fläche gut approximiert, nicht regelmäßig ist (also keine Gitterstruktur aufweist) und Minimalabstände garantiert, z.B. eine Poison Verteilung oder allgemein voronoi-relaxierte Verteilungen?
Gruss, Carsten
Ist denn bekannt, wie mit so einer stochastischen Sampleanordnung gearbeitet wird? Wirs sie einmal erzeugt und dann einfach immer verwendet, oder anders gefragt, wird sie geupdatet und wenn ja, wann, pro Frame, einmal pro Sekunde, oder ist sie eben konstant?
Normalerweise sollte sie nicht konstant sein, um ein Muster zu verhindern.
Um Rauschen mit niedriger Sampleanzahl zu verhindern, kann mans aber auch teilweise konstant halten.
Und gilt die stochasitsche Verteilung eben nur pro "Zelle" (also alle Subpixel eines Pixels) und alle Zellen besitzen dann wieder die gleiche Sampleverteilung, oder gilt die stochastische Verteilung über alle Zellen? Und wie wäre es, wenn man eine Sampleverteilung hätte, welche die Fläche gut approximiert, nicht regelmäßig ist (also keine Gitterstruktur aufweist) und Minimalabstände garantiert, z.B. eine Poison Verteilung oder allgemein voronoi-relaxierte Verteilungen?
Ohje.
Das ist ein mathematisch komplexes Gebiet.
Es gibt Quasizufallsfolgen, die im Grenzfall eine entsprechende Voronoiverteilung haben etc.
Einen guten Überblick was praktisch angewendet wird findest du in dem Paper (http://www.uni-kl.de/AG-Heinrich/EMS.pdf).
Irgendwo hab ich auch noch eine Papersammlung dadrüber von der Siggraph rumfliegen.
Ist halt ein Gebiet an dem viel geforscht wird (auch wenn Aths es für nen Irrweg hält :rolleyes:)...
Als Grundlage muss eigentlich die ganze Signaltheorie sehen. Deswegen frag ich mich immer wie man überhaupt nen Artikel über Aliasing schreiben kann ohne auf ne Fouriertransformation einzugehen.
Alles andere durch rumprobieren und "Punkteversetzen" zu en optimales Ergebnis zu kommen empfinde ich mal als Irrweg. :biggrin:
Exxtreme
2005-01-03, 00:04:04
Oder ist mit dem "stochastischen Algorithmus" etwas ganzt anderes gemeint? Aber was würde das für Vorteile bringen, und welche Nachteile handelt man sich damit eventuell ein? Und dann würde mich noch interessieren, was zum jetzigen Zeitpunkt implementationstechnisch dagegen spricht, sagen wir mal ein 4- oder 8-faches "stochastisches" Multisampling in Grafikkarten zu integrieren (Schaltungsaufwand ?, Bandbreitenverlust ? usw.)
Gruss, Carsten.
Ein stochastischer Algo hat den Vorteil, daß er Moiré-Effekte recht gut unterdrückt. Aber wie aths schon schrieb, lohnt sich das erst bei vielen Samples da ansonsten das Rauschen stark werden könnte.
Deswegen frag ich mich immer wie man überhaupt nen Artikel über Aliasing schreiben kann ohne auf ne Fouriertransformation einzugehen.
Alles andere durch rumprobieren und "Punkteversetzen" zu en optimales Ergebnis zu kommen empfinde ich mal als Irrweg. :biggrin:Würde ich mit der Fouriertransformation kommen, würde das praktisch keiner mehr lesen. Aliasing lässt sich am besten (da sehr einfach) im Frequenzbereich erklären, aber die notwendige Mathematik um erst mal dorthin zu kommen bringt hier kaum einer mit.
Einfach höher abzutasten und runterzufiltern ist eine leicht anwendbare Methode. Das Ergebnis muss ja nicht vollständig korrekt sein, wenns dafür schnell genug ist.
Außerdem sehe ich nicht alles als "sinnvoll Fouriertransformierbar" an. Ansonsten wäre der beste Texturfilter der Spalt-Rekonstruktionsfilter. Imo ist aber alles was über Bilinear hinausgeht, "gelogen".
Würde ich mit der Fouriertransformation kommen, würde das praktisch keiner mehr lesen. Aliasing lässt sich am besten (da sehr einfach) im Frequenzbereich erklären, aber die notwendige Mathematik um erst mal dorthin zu kommen bringt hier kaum einer mit.
Dadrüber kann man sich streiten.
Es gibt genug Leute die wenigstens ungefähr verstehen sollten, was da vor sich geht.
Außerdem sehe ich nicht alles als "sinnvoll Fouriertransformierbar" an. Ansonsten wäre der beste Texturfilter der Spalt-Rekonstruktionsfilter. Imo ist aber alles was über Bilinear hinausgeht, "gelogen".
Was ist "sinnvoll Fouriertransformierbar" ?
Es es schlicht eine Transformation. Also kann man da iom schlecht zwischen sinnvoll und nicht sinnvoll unterscheiden.
Oder meinst du wegen der Laufzeit einer FFT?
Dadrüber kann man sich streiten.
Es gibt genug Leute die wenigstens ungefähr verstehen sollten, was da vor sich geht.Imo reicht das nicht. Ich selbst habe erst vor Wochen das Wesen der Transformation verstanden. Was es ungefähr ist, wie man es mathematisch formuliert und was es mathematisch bedeutet wusste ich vorher auch schon. Aber dann kommt man schnell in eine selbstgefällige Position wo man glaubt, es verstanden zu haben und mitreden zu können.
Was ist "sinnvoll Fouriertransformierbar" ?
Es es schlicht eine Transformation. Also kann man da iom schlecht zwischen sinnvoll und nicht sinnvoll unterscheiden.Ein Rechtecksignal zu tranformieren ist hier nicht sinnvoll. Bei der Rekonstruktion des analogen Signals bekommt man diese "Überschwinger" rein. Nur Funktionen ohne Sprungstellen sind sinnvoll fourier-tranformierbar.
Oder meinst du wegen der Laufzeit einer FFT?FFT geht ja fix.
Ein Rechtecksignal zu tranformieren ist hier nicht sinnvoll. Bei der Rekonstruktion des analogen Signals bekommt man diese "Überschwinger" rein. Nur Funktionen ohne Sprungstellen sind sinnvoll fourier-tranformierbar.
Du hast noch nicht praktisch mit Fouriertransformationen gearbeitet oder? :biggrin:
Klar hat man Boundary Errors. Aber die kann man in den Griff kriegen. Ausserdem ist der Frequenzbereich, bei dem das Problem auftritt, so hoch, dass er eh über unserer Wahrnehmung liegt.
Das Auge ist gegen Rauschen recht unempfindlich.
Das Hauptproblem bei FT für irgendwelche Filter ist hauptsächlich die globale Wirkung aufs ganze Bild. Lokal was zu ändern ist nicht möglich.
Dafür nimmt man halt dann auch besser Wavelets :)
FFT geht ja fix.
Es liegt immer noch in n*log( n ) mit nem Faktor vornedran.
Ausserdem ists normalerweise auf 2er Potenzen bei der Bildgrösse beschränkt.
Für andere Abmessungen sind zwar auch möglich, aber damit wirds auch wieder en gutes Stück langsamer...
Wir werden jetzt hier aber glaub ich zu Offtopic ;)
Asmodeus
2005-01-03, 17:02:08
...
Wir werden jetzt hier aber glaub ich zu Offtopic ;)
...
Hab mich auch schon kurz gefragt, was z.B. Fragen zur Verteilung von Samples mit Rechtecksignalen zu tun haben. ;)
Ich bin bisher meist davon ausgegangen, dass im Zusammenhang mit dem Finden von "optimalen" Verteilung von Samplepunkten, Analysen der statistischen Eigenschaften im Frequenzraum ganz hilfreich sind, und man somit natürlich nicht an Fouriertransformationen vorbeikommt.
Aber worauf ich eigentlich noch hinaus wollte, die Arbeit von Alexander Keller fand ich ziemlich interessant (auch wenn mir durch das Lesen jetzt erst so richtig klar wurde, was er mir und einigen Anderen damals in kleiner Runde zu erklären versuchte ;) ) Und meine Frage ist halt immernoch, wo die Herausforderungen und Probleme liegen, diese Ansätze in Hardware umzusetzen.
Gruss, Carsten.
Aber worauf ich eigentlich noch hinaus wollte, die Arbeit von Alexander Keller fand ich ziemlich interessant (auch wenn mir durch das Lesen jetzt erst so richtig klar wurde, was er mir und einigen Anderen damals in kleiner Runde zu erklären versuchte ;) ) Und meine Frage ist halt immernoch, wo die Herausforderungen und Probleme liegen, diese Ansätze in Hardware umzusetzen.
Mhh die Probleme.
Man muss daran arbeiten, dass es nicht zu Kantenflimmern kommt.
Das kann man entweder über ne entsprechend hohe Sampleanzahl erreichen oder über Bedingungen an die Verteilung im Vergleich zur letzten Verteilung an der selben Stellen. Ersteres kann man entsprechenden Verfahren drücken, wie man in dem Paper von Keller sieht. Zu zweiterem hab ich bisher noch nicht wirklich was gefunden. Es ist aber wohl klar, dass wenn die Änderung zum vorherigen Frame in Grenzen hält es nicht so stark flimmern kann. Allerdings lässt sich das wohl schlecht in Hardware realisieren.
Imo wäre schon möglich es ohne grossen Kantenflimmern in Hardware zu realisieren. Temperal AA von ATi flimmert ja selbst bei niedriger Samplezahl relativ wenig. Man müsste halt nen Zufallsverteilung in Hardware gießen.
Aber dafür müsste man viel Geld in die Forschung stecken, das die Hersteller lieber sonstwo rausschmeissen. Von denen darf man nicht viel mehr erwarten als Brute-Force bis es nicht mehr anders geht.
Ailuros
2005-01-03, 23:34:09
AFAIK verwendet Pixar Supersampling.
Imo wäre schon möglich es ohne grossen Kantenflimmern in Hardware zu realisieren. Temperal AA von ATi flimmert ja selbst bei niedriger Samplezahl relativ wenig.
Erstens fehlt ATI's "temporal" die notwendige back buffer Unterstuetzung (dass es wohl eine reine SW-Loesung sollte ja bekannt sein) und zweitens flimmert genug in manchen Anteilen einer Szene (ja selbst wenn die Camera stillsteht) dass ich mich fragte ob AA nun eingeschaltet ist oder nicht.
Die Methode ist aber auch um einiges von wahrem stochastischem AA entfernt (ATI temporal AA = sample merging in the temporal dimension). Schau mal hier unter den Artikeln nach und lese Eric Demer's Interview nochmal genau durch, was er zu der Anzahl der samples zu sagen hatte fuer solche Faelle.
crusader4
2005-01-04, 00:11:49
@aths: ist zwar Off-Topic hier, aber ich hätte schon Interesse an einem Artikel zum Thema Fourier-Transformation und andere Grundlagen der DSV in Bezug auf Bildverarbeitung.
Ich bin zwar ein "Signalanalyst", aber nur auf Audio-(Sprach-)signale beschränkt (Student der E-Technik - Informationstechnik an der Uni). Ich weiß was Aliasing ist, mir fehlt aber der Zusammenhang zu Bildern. Und welchen Ansatz Antialiasing hier verfolgt (Tiefpaß?, aber an welcher Stelle der Verarbeitungskette).
Und vielleicht bringen auch andere eine ähnliche mathematische Vorbildung mit, aber ist so theoretisch verblendet (ist hier auf mich bezogen) das er es nicht mit der Bildverarbeitung in Zusammenhang bringen kann. Da würde ich mich über Erleuchtung freuen. Natürlich kannst du mich zu recht auf wahrscheinlich haufenweise hervorragende Techdocs verweisen, aber ich denke du könntest das auch hier als Grundlagenartikel anbringen (weil es ja für das Thema der Seite und des Forums fundamental ist), es könnte dann als eine Art Referenz dienen.
Aber für mich ist es hier leicht, Forderungen aufzustellen, ich kann mir vorstellen du hast sehr viel zu tun. War auch nur ne Anregung.
Grüße, Crusader
Erstens fehlt ATI's "temporal" die notwendige back buffer Unterstuetzung (dass es wohl eine reine SW-Loesung sollte ja bekannt sein) und zweitens flimmert genug in manchen Anteilen einer Szene (ja selbst wenn die Camera stillsteht) dass ich mich fragte ob AA nun eingeschaltet ist oder nicht.
Sollte nur als Beispiel dienen, dass eine stark wechselnde Samplingmaske auch mit wenig Flimmern benutzt werden kann.
Anscheinend reagieren die Leute auch ziemlich unterschiedlich auf das Flimmern.
Die Methode ist aber auch um einiges von wahrem stochastischem AA entfernt (ATI temporal AA = sample merging in the temporal dimension). Schau mal hier unter den Artikeln nach und lese Eric Demer's Interview nochmal genau durch, was er zu der Anzahl der samples zu sagen hatte fuer solche Faelle.
Ich weiss was ATI temporal AA ist, was stochastisches AA ist und was Eric Demer im Interview gesagt hatte.
Trotzdem bleib ich bei meiner Meinung, dass wenn man genug Arbeit da rein stecken würde eine brauchbare und bessere Lösung als jetzt herauskommen würde.
Ob man mit nem anderen Weg vielleicht mit weniger Arbeit bessere Ergebnisse erzielen kann ist ne andere Sache. Ich seh da immer noch adaptives Supersampling, womit ich schon sehr positive Erfahrungen gemacht hab.
@aths: ist zwar Off-Topic hier, aber ich hätte schon Interesse an einem Artikel zum Thema Fourier-Transformation und andere Grundlagen der DSV in Bezug auf Bildverarbeitung.Hab zu viel anderes zu tun.
Hab mich auch schon kurz gefragt, was z.B. Fragen zur Verteilung von Samples mit Rechtecksignalen zu tun haben. ;)
Ich bin bisher meist davon ausgegangen, dass im Zusammenhang mit dem Finden von "optimalen" Verteilung von SamplepunktenIn einem Artikel zum Thema habe ich versucht, Kriterien dafür zu finden: http://www.3dcenter.org/artikel/anti-aliasing-masken/
Es liegt immer noch in n*log( n ) mit nem Faktor vornedran.
Ausserdem ists normalerweise auf 2er Potenzen bei der Bildgrösse beschränkt.
Für andere Abmessungen sind zwar auch möglich, aber damit wirds auch wieder en gutes Stück langsamer...Bleibt aber schneller als DFT :)
Mhh die Probleme.
Man muss daran arbeiten, dass es nicht zu Kantenflimmern kommt.
Das kann man entweder über ne entsprechend hohe Sampleanzahl erreichen oder über Bedingungen an die Verteilung im Vergleich zur letzten Verteilung an der selben Stellen.Um eine gegebene Sample-Zahl bestmöglich auszunutzen, sollte sie sowohl "sparsed" verteilt, auch auch möglichst die gleichen Abstände zu den jeweiligen Nachbarsamples aufweisen. (Pseudo-) Zufallsverteilungen erfüllen weder das eine noch das andere Kriterium. Warum also sich überhaupt erst auf diese Schiene begeben? 8x sparsed (mit gamma-korrektem Downfiltering) liefert bereits sehr, sehr gute Glättung.
Von "temporalem" AA, welches das Rauschen durch mehr oder minder stochastische Masken ja mildert, halte ich nichts. Ansonsten könnte man auch den 16-Bit-Framebuffer wiede einführen, nur dass das Ditheringraster jeweils um 1 versetzt wird, um mit der Display-Trägheit Mischfarben zu erzeugen.
Ailuros
2005-01-04, 11:19:31
Sollte nur als Beispiel dienen, dass eine stark wechselnde Samplingmaske auch mit wenig Flimmern benutzt werden kann.
Anscheinend reagieren die Leute auch ziemlich unterschiedlich auf das Flimmern.
Bemerkbares Flimmern eliminiert IMHO den eigentlichen Sinn von AA. Wenn ich stellenweise jeglichen Grad von Flimmer ertragen soll, kann ich auch beruhigt AA gleich abstellen und die Aufloesung noch weiter erhoehen.
Trotzdem bleib ich bei meiner Meinung, dass wenn man genug Arbeit da rein stecken würde eine brauchbare und bessere Lösung als jetzt herauskommen würde.
Auf jeden Fall nicht unter 16x samples-vonwasauchimmer. Die naechsten beiden Gedanken aber danach sind Speichergroesse und Bandbreite. Ich koennte mir leicht vorstellen dass 4x stochastic sogar schlimmer im Durchschnitt aussehen wuerde als einfaches 4x ordered grid, ueberhaupt was moire betrifft.
Ob man mit nem anderen Weg vielleicht mit weniger Arbeit bessere Ergebnisse erzielen kann ist ne andere Sache. Ich seh da immer noch adaptives Supersampling, womit ich schon sehr positive Erfahrungen gemacht hab.
Fuellrate noch dazu bei Supersampling was die vorigen Gedanken betrifft. Mit trilinearem quad texturing und brute-force 16xSSAA bekomme ich gerade noch 88 MPixels/sec mit 4 quads@350MHz. Wieviel genau kann mir an Fuellrate die Adaptivitaet noch dazustecken?
Wie waere es mit einer Kombination von fragment und coverage mask AA?
http://www.beyond3d.com/forum/viewtopic.php?p=11325&highlight=coverage+mask#11325
Uebrigens coverage mask und TBDRs:
There is one notable difference when it comes to AA though between coverage mask techniques and typical TBRs. Typical TBRs are capable of rendering super-sampled AA at high sample densities (say 16x) while coverage mask techniques must use multi-sampling. This is because TBR's do not render the color on the first pass, but only when the tile is rendered. Since coverage mask AA renders colors on the first pass, it can only afford to render one color per fragment, since rendering a color for each sample would lose most of the benefits.
This may not be much of an advantage in actual practice though, since a TBR would be limited by pixel shader performance, even though it is not restricted by external memory bandwidth. Super-sampling each sample when running a sophisticated pixel shader is simply impractical. The computational resources could be put to much better use and multi-sampled AA is good enough
http://www.beyond3d.com/forum/viewtopic.php?p=129946&highlight=coverage+mask#129946
Ich hatte zwar bis jetzt nicht das Vergnuegen mir als Laie solche Methoden in Echtzeit ansehen zu koennen, aber coverage mask klingt tatsaechlich nach einem "dual pass mechanism" fuer antialiasing. Falls man alle moeglichen Schwaechen beseitigen kann und man eine verrueckt hohe Sample-Anzahl mit minimalem Bandbreiten- und Framebuffer-Verbrauch anwenden koennte, dann kommt man tatsaechlich wohl schnell auf TBDR-Niveau was die Einsparung von Resourcen betrifft.
Demirug
2005-01-04, 11:43:18
Ich hatte zwar bis jetzt nicht das Vergnuegen mir als Laie solche Methoden in Echtzeit ansehen zu koennen, aber coverage mask klingt tatsaechlich nach einem "dual pass mechanism" fuer antialiasing. Falls man alle moeglichen Schwaechen beseitigen kann und man eine verrueckt hohe Sample-Anzahl mit minimalem Bandbreiten- und Framebuffer-Verbrauch anwenden koennte, dann kommt man tatsaechlich wohl schnell auf TBDR-Niveau was die Einsparung von Resourcen betrifft.
coverage mask ist ein Begriff der in Verbindung mit MSAA schon immer benutzt wird. Er gibt lediglich an welcher der einen Pixel zugeordenen Samples von dem gerade berechneten Primitive (Punkt, Linke, Dreieck) auch bedeckt werden. Die Maske wird in der Regel vom Rasterisierer erzeugt und von den ROPs ausgewertet. Sie kann aber auch durchaus in der Pixelpipeline selbst zum Einsatz kommen um zum Beispiel beim Centroid Sampling die richtige Position zu bestimmen.
Asmodeus
2005-01-04, 12:06:40
In einem Artikel zum Thema habe ich versucht, Kriterien dafür zu finden: http://www.3dcenter.org/artikel/anti-aliasing-masken/
Naja, ich glaube, genau dies meinte RLZ mit "rumprobieren und Samples verschieben" ;)
Ich hab nochmal kurz gekramt und eines unserer Paper gefunden, in denen auch mal bildlich einige Analysen von Sampleverteilungen zu sehen sind (z.B. auf der letzten Seite die Fouriertransformation von drei Verteilungen)
Link (http://www.cgmi.inf.uni-konstanz.de/publications/pdf/VMV_tiles_blue_noise_samples.pdf)
Leider wurden dort natürlich keine Standardverfahren verglichen, wie sie heute in Grafikkarten implementiert sind. Aber vielleicht sollte man das einfach mal machen, um etwas zum "mathematischen" Vergleichen zu haben. Wenn ich nächste Woche wieder auf Arbeit bin, werd ich mal sehen, mit wie viel Aufwand das verbunden ist. Wäre, denke ich, schon mal interessant, alle gängigen Modi auf diese Weise zu analysieren.
EDIT:
Oder existieren im Netz schon irgendwo vielleicht solche Analysen?
Gruss, Carsten
Um eine gegebene Sample-Zahl bestmöglich auszunutzen, sollte sie sowohl "sparsed" verteilt, auch auch möglichst die gleichen Abstände zu den jeweiligen Nachbarsamples aufweisen. (Pseudo-) Zufallsverteilungen erfüllen weder das eine noch das andere Kriterium. Warum also sich überhaupt erst auf diese Schiene begeben? 8x sparsed (mit gamma-korrektem Downfiltering) liefert bereits sehr, sehr gute Glättung.
Bei stochastischem AA kann man sich für die Verteilungen Bedingungen bauen.
Auch das etwas wie sparsed rauskommt.
bemerkbares Flimmern eliminiert IMHO den eigentlichen Sinn von AA. Wenn ich stellenweise jeglichen Grad von Flimmer ertragen soll, kann ich auch beruhigt AA gleich abstellen und die Aufloesung noch weiter erhoehen.
Jedes Bild das von einem A/D-Wandler erzeugt beinhaltet flimmern. Damit kannst du auch kein zB auch kein Fernsehn mehr schauen.
Vollkommene Rauschfreiheit ist übrigends recht unnatürlich....
Fuellrate noch dazu bei Supersampling was die vorigen Gedanken betrifft. Mit trilinearem quad texturing und brute-force 16xSSAA bekomme ich gerade noch 88 MPixels/sec mit 4 quads@350MHz. Wieviel genau kann mir an Fuellrate die Adaptivitaet noch dazustecken?
Die Rechnung kannst bei adaptivem SSAA nicht machen. Es wird nur das mit mehr Samples berechnet was es auch nötig hat. Wie sie das bei einem Hardwarerasterizer realisieren ist mir eigentlich egal. Dafür haben die Leute in der Entwicklung.
Scheinbar stellt ihr den ganzen Sinn vom stochastischem AA in Frage. :|
Vielleicht deswegen mal etwas zur Mathematik....
Ein Pixel sollte das Integral einer 2D-Funktion darstellen, das über die Fläche des Pixels geht. Dieses stellt immer den Grenzwert dar, den wir durch den ganzen AA Kram erreichen wollen.
Numerische Integration ist nichts neues. Feste Sampleanordnung haben alle im allgemeinen ihre Schwächen, so dass tatsächlich Zufallsanordnungen allgemein am schnellsten gegen den Grenzwert konvergieren (wenn ihr das Gegenteil beweisen wollt viel Spass ;)) und das nicht nur bei extrem hohen Samplingzahlen. Das Prinzip zufällig irgendwelche Samplepunkte zu nehmen nennt sich MonteCarlo-Integration. Damit werden ganze Bücher und Vorlesungen gefüllt.
Da diese MC-Integration auch ihre Schwächen hat (zB dass alle Punkte auf einem Klotz sitzen können) hat man nun die Quasi-MC-Integration eingeführt. Dabei versucht man eine möglichst gleichverteilte Anordnung der Samples zu erreichen (sie zb Paper das ich oben verlinkt hatte). Der Grenzwert dafür ist zb eine voronoi-relaxierte Verteilung.
Wenn man noch irgendwelche Randbedingungen hat (sparsed, Bedingung für Rauschfreiheit etc), dann steht es einem frei dies noch in die Zufallsverteilung einzubauen.
Ich hab auch nie behauptet, dass es leicht ist ein flimmerfreies stochastisches AA mit niedriger Sampleanzahl zu erreichen, aber ich sehe keinen Grund warum es nicht möglich sein sollte.
Wenn jemand noch ne Gegenbegründung hat, wäre mal was Anderes als ein Interviewfetzen oder ein "es ist aber jetzt doch schon gut genug" ganz interessant.
Asmodeus
2005-01-04, 13:35:41
...
Wie sie das bei einem Hardwarerasterizer realisieren ist mir eigentlich egal. Dafür haben die Leute in der Entwicklung.
...
Ja, genau das war eigentlich der Grund für meine Erstellung dieses Threads. Wir haben einen Ist-Zustand bei Grafikkarten, was die verwendeten Multisamplingmethoden anbelangt. Dieser Zustand ist sicher noch weit vom "optimalen Endzustand" entfernt. Auf der einen Seite gibt es nun ne Menge "mathematisch-theoretische" Ansätze um die Sache zu verbessern. Auf der anderen Seite ist die Frage der Implementierbarkeit. Ich habe etwas Ahnung und ne halbwegs brauchbare Vorstellung, was die mathematische Schiene anbelangt und leider keine Ahnung, was die Implementationsproblematik anbelangt. Und deshalb wollt ich hier sozusagen von der "anderen Seite" hören, welche von den "theoretischen" Ansätzen implementationsspezifisch am vielversprechensten wären. Und da finde ich es wie RLZ auch eher bissel kontraproduktiv, auf dem Standpunkt zu verweilen, "Das was wir haben, noch bissel verbessert reicht doch schon." ;)
Gruss, Carsten
Meine Aussage bezog sich auf das adaptive Supersampling.
Da gibts nämlich ein riesen Problem. Afaik gibts noch keine Möglichkeit während oder vor dem Rendern zu bestimmen, was wirklich eine höhere Auflösung benötigt.
Normalerweise jagt man nach dem Rendervorgang über das Bild ne Erkennung drüber und rendert die entsprechenden Stellen in einer höheren Auflösung nach.
Rasterizer mögens aber nun garnicht nur einzelne kleine Stellen im Bild zu rendern :(
Aber als Multipass wäre es wohl schon möglich.
Zum stochastischen AA hätte ich 2 "einfache" Ideen.
1. ne vorher bestimmte Abfolge von Masken, die mit möglichst wenig Flimmern eine möglichst gute Filterwirkung erzielen.
Problem dabei ist nur die Konstruktion dieser Masken. Eine Lösung wäre einfach mit Bruteforce ne riesige Menge guter stochastischer Masken zu erzeugen und dann mit nem Cluster ne Maskenfolge zu finden, die alle geforderten Bedingungen erfüllt. Die Laufzeit ist aber wohl jenseits von Gut und Böse. Da müssten schon ordentliche Algorithmen zur schnellen Erkennung der Bedingungen her.
2. man nimmt eine herkömmliche Maske und lässt sie um nen bestimmten Drehwinkel zittern. Solange man den Winkel nicht zu gross wählt, wirds nicht viel flimmern, aber die Filterwirkung wird gleichmässiger verteilt.
Asmodeus
2005-01-04, 15:57:46
...
Zum stochastischen AA hätte ich 2 "einfache" Ideen.
1. ne vorher bestimmte Abfolge von Masken, die mit möglichst wenig Flimmern eine möglichst gute Filterwirkung erzielen.
Problem dabei ist nur die Konstruktion dieser Masken. Eine Lösung wäre einfach mit Bruteforce ne riesige Menge guter stochastischer Masken zu erzeugen und dann mit nem Cluster ne Maskenfolge zu finden, die alle geforderten Bedingungen erfüllt. Die Laufzeit ist aber wohl jenseits von Gut und Böse. Da müssten schon ordentliche Algorithmen zur schnellen Erkennung der Bedingungen her.
...
Naja, wäre da ein aperiodischer Tilingansatz nicht z.B. auch ganz gut geeignet? Man hätte eine überschaubare Anzahl an Tiles (z.B. 8 oder 16) und es gibt ja dann nicht nur eine Möglichkeit, diese Tiles anzuordnen. Das Anordnen selbst würde dann aber sicher die Herausforderung in Hardware darstellen.
Gruss, Carsten
Naja, wäre da ein aperiodischer Tilingansatz nicht z.B. auch ganz gut geeignet? Man hätte eine überschaubare Anzahl an Tiles (z.B. 8 oder 16) und es gibt ja dann nicht nur eine Möglichkeit, diese Tiles anzuordnen. Das Anordnen selbst würde dann aber sicher die Herausforderung in Hardware darstellen.
Wenn du dann noch Flimmerfreiheit gewährleisten kannst ja.
Wäre übrigends en schönes Thema für ne Diplomarbeit. ;)
Ailuros
2005-01-05, 06:53:57
Die Rechnung kannst bei adaptivem SSAA nicht machen. Es wird nur das mit mehr Samples berechnet was es auch nötig hat. Wie sie das bei einem Hardwarerasterizer realisieren ist mir eigentlich egal. Dafür haben die Leute in der Entwicklung.
Natuerlich kann ich die Rechnung nicht so machen, aber ich hab es trotzdem schwer zu verdauen dass >16/32x sample stochastisches SSAA weniger in Resourcen kosten wuerde als normales brute-force 2xSSAA.
Ich bezweifle die Nutzbarbkeit von einem stochastischen Algorithmus im Grunde nicht, eher die Nutzbarkeit von Supersampling jeder Art und das ueberhaupt fuer sehr hohe Aufloesungen.
Wenn dann will ich von einer Theorie hoeren wo stochastisches SSAA mit genauso wenig Resourcen auskommt wie stochastisches MSAA.
Um es noch genauer zu machen, nur mal ein einfaches DX7 Spiel:
UT2k4/maximum quality:
Primeval/8bots:
1024*768*32/ 4xAF:
2*1 SSAA = 37.58 fps
2x MSAA = 68.56 fps
Face3/flyby:
1024*768*32/ 4xAF
2*1 SSAA = 135.77 fps
2x MSAA = 154.85 fps
1600*1200*32/ 4xAF
2*1 SSAA = 62.30 fps
2x MSAA = 114.54 fps
Nun gib mir einen guten Grund warum sich dieses Bild theoretisch zwischen stochastischen Multisampling und stochastischem Supersampling aendern sollte.
Aber als Multipass wäre es wohl schon möglich.
Fuer stochastisches SSAA aber dann bitte nur auf einem TBDR. Aber ich stimme hier meinen vorigen Zitaten wohl eher zu. Mit anspruchsvollen Pixel Shadern ist selbst da SSAA unpraktisch und von diesen ist ja erst gar nichts mal zu sehen in den obrigen Tests. Ich denke jetzt mal an Spiele fuer ~2006 mit 50-200 PS Instruktionen, dynamischen Schatten und 64bpp HDR.
Theoretisch reicht ein 256mb framebuffer fuer eine verrueckt hohe Anzahl von SSAA samples fuer solche einen Fall bei einem high end TBDR erstmal bis zu 1024*768 aus; von hoeheren Aufloesungen und/oder Leistung sollte hier aber erstmal nicht die Rede sein.
Naja, wäre da ein aperiodischer Tilingansatz nicht z.B. auch ganz gut geeignet? Man hätte eine überschaubare Anzahl an Tiles (z.B. 8 oder 16) und es gibt ja dann nicht nur eine Möglichkeit, diese Tiles anzuordnen. Das Anordnen selbst würde dann aber sicher die Herausforderung in Hardware darstellen.
Anordnen? Au weia.... Coverage Mask Techniken ermoeglichen uebrigens nach dem vorigen Geblubber/Behauptungen "order independent transparency".
Ailuros
2005-01-05, 07:02:49
coverage mask ist ein Begriff der in Verbindung mit MSAA schon immer benutzt wird. Er gibt lediglich an welcher der einen Pixel zugeordenen Samples von dem gerade berechneten Primitive (Punkt, Linke, Dreieck) auch bedeckt werden. Die Maske wird in der Regel vom Rasterisierer erzeugt und von den ROPs ausgewertet. Sie kann aber auch durchaus in der Pixelpipeline selbst zum Einsatz kommen um zum Beispiel beim Centroid Sampling die richtige Position zu bestimmen.
Im Fall von SA's Aussagen hab ich aber dann eher das Gefuehl dass er sich eher auf "Z3-artige" Implementationen (oder noch etwas erweitert Algorithmen die im Grunde adaptiv sind) bezieht als normales Multisampling.
Mit welcher Methode man jetzt theoretisch Adaptivitaet mit AA erreichen wuerde, ist mir im Grunde egal. Das Endresultat darf keine deutliche Schwaechen im Vergleich zu "brute-force" Methoden zeigen IMHO (Beispiel 16x sample adaptiv vs 8x sparce "brute-force") und es faellt mir immer noch schwer einzusehen dass selbst adaptives SSAA keine Resource-Verschwendung sein koennte.
Exxtreme
2005-01-05, 10:14:40
Ailuros,
ich weiss gar nicht, warum du SSAA als Resourcenverschwendung ansiehst. :| Klar frisst es Füllrate weg ohne Ende. Nur es bietet eine bessere BQ in praktisch allen Fällen als MSAA.
Adaptives AA sollte ja nicht nur erkennen wo nachgeberechnet werden muss. Man führt es rekursiv aus und erhält so an schwierigen Stellen eine bessere Glättung. Wieviel Prozent vom Bild ne höhere Auflösung brauchen, hängt von zuvielen Faktoren ab, als dass man da ne allgemeingültige Aussage machen kann.
Selbst wenn er 20% vom Bild als kritisch erkennt hätte man gegenüber Bruteforce noch ne Einsparung von 80%. Und 20% von einem Bild sind schon verdammt viel...
Wenn man dann noch mit einbezieht, dass von den 20% die meisten Fälle mit 4-fach erledigt wären, bleibt der Teil der 16fach braucht nicht mehr allzu gross.
Demirug
2005-01-05, 13:18:30
Zu dem Thema habe ich noch was von S3 für euch:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6828983&F=0&QPN=US6828983
Ailuros
2005-01-05, 17:41:24
Adaptives AA sollte ja nicht nur erkennen wo nachgeberechnet werden muss. Man führt es rekursiv aus und erhält so an schwierigen Stellen eine bessere Glättung. Wieviel Prozent vom Bild ne höhere Auflösung brauchen, hängt von zuvielen Faktoren ab, als dass man da ne allgemeingültige Aussage machen kann.
Selbst wenn er 20% vom Bild als kritisch erkennt hätte man gegenüber Bruteforce noch ne Einsparung von 80%. Und 20% von einem Bild sind schon verdammt viel...
Wenn man dann noch mit einbezieht, dass von den 20% die meisten Fälle mit 4-fach erledigt wären, bleibt der Teil der 16fach braucht nicht mehr allzu gross.
Schon 2-fach heisst die Haelfte der Fuellrate, was wohl auf keinen Fall bis jetzt der Fall mit Multisampling ist. Stochastisches/adaptives MSAA kann eventuell "Fuellraten-frei" sein, SSAA eben nicht.
Ailuros
2005-01-05, 17:53:01
Ailuros,
ich weiss gar nicht, warum du SSAA als Resourcenverschwendung ansiehst. :| Klar frisst es Füllrate weg ohne Ende. Nur es bietet eine bessere BQ in praktisch allen Fällen als MSAA.
Weil die Faelle wo MSAA nicht effektiv einsetzt zu gering sind. Eine MSAA + AF Kombination (jeglicher Art ob nun brute force oder adaptiv) ist IMO durchaus ausreichend. Ich will hohe Aufloesungen und Antialiasing.
Supersampling bietet uebrigens von alleine im Durchschnitt bis jetzt nicht eine bessere Bildqualitaet als eine MSAA+ (>2x)AF Kombination. SSAA + AF ist dann ein ganz anderes Bier und heisst eben noch mehr Fuellraten-Verschwendung und noch niedrigere Aufloesung.
Im vorigen Beispiel mit nur 2xSSAA muss ich in 1024 steckenbleiben. Dass ich aber im gegebenen Fall mit 2xMSAA/2xAF auf 1600 problemlos komme, bedeutet in Echtzeit nicht nur einen Leistungs- sonder auch einen durchschnittlichen Qualitaets-schub.
Ailuros
2005-01-05, 18:15:12
Zu dem Thema habe ich noch was von S3 für euch:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6828983&F=0&QPN=US6828983
Verdammt interessant :D
Imposant ist dass man auch Z3 unter die Lupe genommen hat. Ist es quasi eine Kombination von Z3 und FAA (sehr relativ gesehen) oder liege ich hier falsch?
Eine 16x sample sparsed edge-AA Realisierung mit S3's ausgezeichnetem AF Algorithmus waere wohl der Hammer fuer die Zukunft...
robbitop
2005-01-05, 21:10:51
Verdammt interessant :D
Imposant ist dass man auch Z3 unter die Lupe genommen hat. Ist es quasi eine Kombination von Z3 und FAA (sehr relativ gesehen) oder liege ich hier falsch?
Eine 16x sample sparsed edge-AA Realisierung mit S3's ausgezeichnetem AF Algorithmus waere wohl der Hammer fuer die Zukunft...
wo ist dort von Z3 die Rede? Oder habe ich soetwas überlesen?
Klingt jedoch verdammt interessant. Wäre schon genial, wenn das bereits im "Destination Films"-Projekt Einzug finden wird.
Demirug
2005-01-05, 21:18:54
Ailuros, soweit ich das sehe ist das Verfahren das S3 da beschreibt verlustfrei. Z3 ist es ja nicht.
Allerdings sind da noch ein paar andere Sachen etwas merkwürdig. So das man das AA als Postprocess durchführen möchte.
EDIT PS: Ich habe ja auch mal ein AA Verfahren entworfen mal schauen ob ich die Sachen noch finde.
Ailuros
2005-01-06, 09:30:57
wo ist dort von Z3 die Rede? Oder habe ich soetwas überlesen?
Klingt jedoch verdammt interessant. Wäre schon genial, wenn das bereits im "Destination Films"-Projekt Einzug finden wird.
Es wird erwaehnt als "Vergleichs-Material":
[0009] A further anti-aliasing method is known as Z<3> , which maintains a sorted list of edge fragments and blends the fragments in the same manner as the A-buffer algorithm. Although the Z<3 > algorithm can detect "Z-edges", it disadvantageously relies on unbounded memory, use of linked lists which require complex logic, and blending of polygon edge fragments to reduce memory usage which degrades the quality of the output image for a complex 3D scene.
[0010] Therefore, there is a need for an improved system and method for efficiently sampling 3D primitives while preventing the aliasing artifacts introduced by the sampling process.
Demi,
Ailuros, soweit ich das sehe ist das Verfahren das S3 da beschreibt verlustfrei. Z3 ist es ja nicht.
Allerdings sind da noch ein paar andere Sachen etwas merkwürdig. So das man das AA als Postprocess durchführen möchte.
Ich sagte ja auch nicht dass es Z3 ist; SA schlug damals ein Verfahren vor, dass die Vorteile von Z3 und FAA kombiniert ohne deren jeweilige Nachteile zu adoptieren.
Matrox's FAA hat ein Problem mit poly intersections dass Z3 nicht hat (und ist auch im Grund edge-AA mit ordered grid Supersampling) und Z3 hat das "Speicher-verwaltungs"-Problem.
You could keep the advantages of FAA without its 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.
BTW, I would definitely keep the spare matrix sampling pattern that Z3 uses as well.
Postprocess? So in etwa stellte ich mir einen moeglichen Algorithmus schon immer vor als SA von coverage mask Techniken blubberte. Es kann sein dass er "coverage mask" als Beschreibung hier etwas merkwuerdig bezeichnet (wenn es tatsaechlich generell auf MSAA bezieht), aber in diesem Sinn kommt mir das Puzzle so langsam schon zusammen:
Coverage mask AA techniques can process samples in a pixel with the same precision as individual point samples if the information is kept around to do so. This includes the correct processing of implicit edges. Z3 does this by using z slopes (hence Z3 - the z, dzdx, and dzdy), although there are other techniques, this is the most effective. FAA did not bother to do this.
When using z slopes with coverage mask AA, the result is actually a form of tile based renderer with pixel sized tiles. The rendering is done in two passes, much like a typical TBR. The first pass renders to "tiles" that are a rectangular collection of higher resolution screen samples. The second pass then renders each tile to the final frame buffer.
The major differences compared to typical TBRs are the format of the data in the tile and the size of the tile. In the case of coverage mask AA, the data is kept in the tile as a set of geometry information (z slopes and a z value), bit masks, and colors. This means that colors are rendered on the first pass which is different than a deferred rendering tiler which keeps the geometry as triangles and unrendered color information. However, both render at a lower resolution than the sample resolution on the first pass and collect up fragments in the "tile" buffer to be rendered on the second pass. On the second pass coverage mask AA, processes each pixel sized "tile" by processing each of the fragments found on the first pass - typically front to back to produce the final color for the pixel.
A typical TBR of course, processes each tile by processing each of the triangles in the tile (not necessarily front to back).
Coverage mask AA derives many of the same benefits as typical TBRs, that is, it substantially reduces external memory bandwidth for a given sample resolution. This is because the processing on the first pass is done at a lower resolution than the sample resolution, and the results are kept in a compressed format for the second pass which processes each tile.
There is one notable difference when it comes to AA though between coverage mask techniques and typical TBRs. Typical TBRs are capable of rendering super-sampled AA at high sample densities (say 16x) while coverage mask techniques must use multi-sampling. This is because TBR's do not render the color on the first pass, but only when the tile is rendered. Since coverage mask AA renders colors on the first pass, it can only afford to render one color per fragment, since rendering a color for each sample would lose most of the benefits.
This may not be much of an advantage in actual practice though, since a TBR would be limited by pixel shader performance, even though it is not restricted by external memory bandwidth. Super-sampling each sample when running a sophisticated pixel shader is simply impractical. The computational resources could be put to much better use and multi-sampled AA is good enough.
Ausser ich hab mich mit dem komplizierten Patent-Zeug tatsaechlich verlesen...
Uebrigens deferred rendering hin und her, wenn ich mir die Qualitaets-Orientierung/Philosophie von S3 und PowerVR etwas generell ueberdenke, sollten die Beiden vielleicht nochmal eine moegliche Zusammenarbeit ueberdenken.
***edit:
http://www.beyond3d.com/forum/viewtopic.php?p=441050#441050
Mal sehen ob es zu einer interessanten Debatte fuehrt ;)
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.