Archiv verlassen und diese Seite im Standarddesign anzeigen : FSAA mit dynamischen Filtern
Ailuros
2007-06-05, 06:16:18
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=WO2007049049&F=0
Kann mir jemand mal genau erklaeren ueber was es in dem Patent genau geht?
Handelt es sich um eine Art adaptives AA + adaptive Filter oder geht es am Ende ausschliesslich nur um die Filter hier?
Gibt es hier irgendeine Parallele zu AMD's edge detection CFAA oder bin ich hier auf dem falschen Pfad?
Wie dem auch sei: IMHO koennten kluge Algorithmen die alternative Filter nur auf Polygonkanten anwenden, sehr interessant sein und ja das gilt ebenso fuer AMD's edge detection Dingsbums (das ich bis jetzt leider nicht in Echtzeit sehen konnte). Mein groesster persoenlicher Einspruch gegen wide/narrow tent CFAA (und auch Quincunx der Vergangenheit) ist das "oversampling" das auf Texturen u.a. vorkommt, wobei ein solcher Filter nicht angewendet werden sollte.
Rein aus technologischen Interesse: mir ist natuerlich klar dass bei jeglicher Art von "edge detection" oder der Methode die hier im Patent beschrieben wird, ein TBDR einen klaren Vorteil hat. Die bloede Frage die hier folgt, ist ob man das Zeug nicht mit einer Art "dual pass" Mechanismus nicht auch auf einem IMR anwenden koennte ohne dass es zu viel Leistung kostet.
Noch bloedere Frage: coverage sampling mit custom filter aber das letzte nur da wo es Sinn macht moeglich?
san.salvador
2007-06-05, 06:18:50
Wie dem auch sei: IMHO koennten kluge Algorithmen die alternative Filter nur auf Polygonkanten anwenden
Trifft das nicht schon auf MSAA zu? :|
Spasstiger
2007-06-05, 06:28:58
Trifft das nicht schon auf MSAA zu? :|
Ja, der edge-detection-Filter vom CFAA macht sich deshalb auch direkt die MSAA-Eigenheiten zu Nutze.
Ailuros
2007-06-06, 05:57:11
Ja, der edge-detection-Filter vom CFAA macht sich deshalb auch direkt die MSAA-Eigenheiten zu Nutze.
Kostet aber dann wohl einiges an Leistung.
Wieviel Leistung im Vergleich zu den beiden Campermodi? Die müssen immerhin das ganze Bild bearbeiten, während die edge-detection und der Boxfilter nur an Rändern und Schnittkanten überhaupt irgendwas machen.
Kostet aber dann wohl einiges an Leistung.
Wenn man das in die Scanout-Logik integrieren würde nicht. Aber bei R600... :D
Ailuros
2007-06-06, 22:56:42
Wieviel Leistung im Vergleich zu den beiden Campermodi? Die müssen immerhin das ganze Bild bearbeiten, während die edge-detection und der Boxfilter nur an Rändern und Schnittkanten überhaupt irgendwas machen.
Afaik liegt die Leistung um einiges niedriger als bei den narrow-/tent Filter Dingdas.
Deiner Logik kann ich leider auch nicht folgen; ganz idiotisch vereinfacht:
Angenommen ich gebe zwei Kerlen Pinsel und Farbe; der eine muss eine grosse Wand einfach nur streichen und der zweite auf einer gleichgrossen Wand nur sehr bestimmte Flecken mit Eingeschaft X aussuchen, markieren und dann diese nur anstreichen. Warum passt es mir nicht in den Schaedel dass der zweite Herr nicht die blasseste Chance hat frueher fertig zu werden?
Afaik liegt die Leistung um einiges niedriger als bei den narrow-/tent Filter Dingdas.
Aber nur weil's im Shader gemacht wird. Das wäre wenn es als Logik implementiert wäre überhaupt kein Problem.
Ich halte von dem ganzen CFAA-Zeug aber sowieso nichts, auch nicht mit Edge-Detection. Aber jedem das seine.
Edit: CSAA->CFAA.
Um die "idiotische Vereinfachung" wegzulassen läufts doch auf folgendes raus:
Entweder
1. Die ROP schreit "Der Pixel ist nicht maximal komprimiert. Shader mach hinne!"
Dann sollte die edge-detection (meistens, nutzt ja mehr Samples) schneller sein.
Oder
2. Auch für edge-detection müssen die Shader den ganzen Framebuffer durchackern.
1. würde für eine so angelegte Architektur sprechen, 2. für die Umschiffung verkäferter ROPs.
@Coda
Von CSAA halte ich auch nicht sonderlich viel. Aber eigentlich gehts hier doch um CFAA, was ich gar nicht mal so doof finde...
san.salvador
2007-06-07, 00:06:02
@Coda
Von CSAA halte ich auch nicht sonderlich viel. Aber eigentlich gehts hier doch um CFAA, was ich gar nicht mal so doof finde...
Auf diese Verwechslung wollte ich auch hinweisen, aber:
Ich halte mich eigentlich für einen Grafikfetischisten und empfinde CSAA als Bereicherung.
Für den Preis von MSAA 4x bekomme ich auch schon CSAA 16x. Natürlich ist das mit MSAA 16x nicht zu vergleichen, aber es bietet dennoch einen sehr günstigen Mehrwert.
Von CFAA halte ich jedoch - abgesehen von CFAA+Edge Detection! (was kostet das eigentlich an Performance?) - nicht das geringste. Blur soll schnell wieder sterben, bitte.
was kostet das eigentlich an Performance?
Verdammt viel. Und auch das halte ich für keine gute Idee. Wenn viel Geometrie an einer Stelle ist matscht es wieder.
san.salvador
2007-06-07, 01:06:41
Naja, es matscht immerhin nur die Kanten, und das ist ja auch irgendwie der Zweck.
Mich würde interessieren, wo Edge-Detection-CFAA im Vergleich zu CSAA liegt - optisch, aber auch vor allem bei der Performance. CSAA ist ja beinahe for free und sieht immer mindestens genau so gut aus wie MSAA.
Naja, es matscht immerhin nur die Kanten, und das ist ja auch irgendwie der Zweck.
Eben nicht. Wenn viele Kanten in einem Bildabschnitt ist matscht wieder alles. Naja ist aber nicht soo schlimm.
CSAA ist ja beinahe for free und sieht immer mindestens genau so gut aus wie MSAA.
CSAA ist übrigens bei weitem nicht "for free". Wundert mich eigentlich selber. Ich denke dass sich das in zukünftigen Generationen noch gibt.
san.salvador
2007-06-07, 02:08:42
>>Hier<< (http://www.beyond3d.com/content/reviews/3/3) gibts mal einige Vergleichsshots zu CSAA.
Wie man bei den Oblivionshots (runterscrollen) sehen, leistet CSAA schon verdammt gute Arbeit.
Zur Performance hab ich noch nichts gefunden, vielleicht wirds ja noch.
Ich halte mich eigentlich für einen Grafikfetischisten und empfinde CSAA als Bereicherung.
Für den Preis von MSAA 4x bekomme ich auch schon CSAA 16x. Natürlich ist das mit MSAA 16x nicht zu vergleichen, aber es bietet dennoch einen sehr günstigen Mehrwert.Es sorgt aber für Inhomogenität im Bild, da es zwar an den meisten Stellen besser aussieht, an manchen aber eben nicht. Und die Stellen stechen mir immer schlimmer ins Auge als wenn das gesamte Bild homogen etwas schlechter aussehen würde. Daher halte ich auch von edge-detection nicht sonderlich viel.
Von CFAA halte ich jedoch - abgesehen von CFAA+Edge Detection! (was kostet das eigentlich an Performance?) - nicht das geringste. Blur soll schnell wieder sterben, bitte.Um Gottes Willen, bloß nicht! Zusätzliche Optionen sind NIE schlecht. Wer sie nicht mag soll halt andere nutzen.
Was das Patent vom PowerVR-b3d-Simon angeht:
Wenn der Endnutzer auch eine gewisse Kontrolle über das Filterverhalten bekommt wäre ich absolut begeistert. Nur das HUD ohne AA, dafür alles andere mit nem 4x4 Filter... Schmackhaft!
Andere wären sicher begeisterter von einer Funktionsweise ähnlich der tatsächlichen edge-detection-CFAA-Funktionsweise oder deren offizieller Erklärung.
Wenn doch nur endlich wieder PowerVR-HW für den PC verfügbar würde :usad:
Um Gottes Willen, bloß nicht! Zusätzliche Optionen sind NIE schlecht. Wer sie nicht mag soll halt andere nutzen.
Ich hab leider das Gefühl, dass man da manche zu ihrem Glück zwingen muss.
Ich hab leider das Gefühl, dass man da manche zu ihrem Glück zwingen muss.Den Satz verstehe ich nicht wirklich.
Meinst du Zwangs"optimierungen" beim Texturfilter? Zwang ist immer doof, aber wenn man die Wahl hat "Optimierungen" zu nutzen oder sie komplett abzuschalten sind selbst die eine Bereicherung der Möglichkeiten. Soll doch jeder für seine Wahrnehmung den passenden Kompromiss aus Leistungsbedarf und Bildqualität finden. Nur weil ich etwas nicht nutze habe ich doch keinen Verlust dadurch, dass andere es nutzen können.[/Antwort auf den zitierten Beitrag]
Mal eine Frage an alle, welche die eine oder andere Option am liebsten verschwinden sehen würden:
WARUM ZUM GEIER? Was habt ihr davon, wenn anderen geschadet wird?
Ailuros
2007-06-07, 06:28:02
Auf diese Verwechslung wollte ich auch hinweisen, aber:
Ich halte mich eigentlich für einen Grafikfetischisten und empfinde CSAA als Bereicherung.
Für den Preis von MSAA 4x bekomme ich auch schon CSAA 16x. Natürlich ist das mit MSAA 16x nicht zu vergleichen, aber es bietet dennoch einen sehr günstigen Mehrwert.
Von CFAA halte ich jedoch - abgesehen von CFAA+Edge Detection! (was kostet das eigentlich an Performance?) - nicht das geringste. Blur soll schnell wieder sterben, bitte.
Wie waere es aber wenn Du als User noch zusaetzlich die Wahl haben koenntest CSAA mit "edge detection custom filter-wasauchimmer" zu kombinieren?
NV sagte zwar oeffentlich dass das Publikum nichts von Quincunx gehalten hat und dass sie solche Konzepte deswegen aufgegeben haben, aber falls fortschrittlichere Methoden in der Zukunft Erfolg sehen sollten, werden sie ihre PR-Meinung wohl auch wieder schnell aendern.
Ailuros
2007-06-07, 06:34:28
Um die "idiotische Vereinfachung" wegzulassen läufts doch auf folgendes raus:
Entweder
1. Die ROP schreit "Der Pixel ist nicht maximal komprimiert. Shader mach hinne!"
Dann sollte die edge-detection (meistens, nutzt ja mehr Samples) schneller sein.
Oder
2. Auch für edge-detection müssen die Shader den ganzen Framebuffer durchackern.
1. würde für eine so angelegte Architektur sprechen, 2. für die Umschiffung verkäferter ROPs.
Dass mit den ROPs ist mir leider schon seit einiger Zeit bewusst. Von dem abgesehen habe ich es momentan schwer zu verstehen wieso edge detection im Vergleich zu narrow/tent CFAA gleich schnell (oder sogar schneller?) sein sollte, wenn eine GPU extra Zeit und Resourcen aufwenden muss um die "Kanten" erstmal zu markieren.
Ich verpasse hier als Laie irgendwo etwas in meiner vereinfachten Logik und ja es handelt sich um eine ehrliche Frage.
Ailuros
2007-06-07, 06:38:33
Was das Patent vom PowerVR-b3d-Simon angeht:
Wenn der Endnutzer auch eine gewisse Kontrolle über das Filterverhalten bekommt wäre ich absolut begeistert. Nur das HUD ohne AA, dafür alles andere mit nem 4x4 Filter... Schmackhaft!
Andere wären sicher begeisterter von einer Funktionsweise ähnlich der tatsächlichen edge-detection-CFAA-Funktionsweise oder deren offizieller Erklärung.
Wenn doch nur endlich wieder PowerVR-HW für den PC verfügbar würde :usad:
Zum letzten Satz: selbst wenn wird es wohl noch etwas dauern und selbst dann wohl nichts was sich ausserhalb dem low-cost Bereich bewegen wird. Kommt ganz drauf was Intel mit dem Zeug langfristig genau vorhat.
Von dem abgesehen, spricht das Patent auch gleichzeitig von adaptivem AA (sprich so und so viel AA samples je nach Bedarf) oder lese ich hier wieder das Ganze falsch? Und nein ich meine jetzt nicht die dynamischen Filter Dingsbumse.
Dass mit den ROPs ist mir leider schon seit einiger Zeit bewusst. Von dem abgesehen habe ich es momentan schwer zu verstehen wieso edge detection im Vergleich zu narrow/tent CFAA gleich schnell (oder sogar schneller?) sein sollte, wenn eine GPU extra Zeit und Resourcen aufwenden muss um die "Kanten" erstmal zu markieren.
Ich verpasse hier als Laie irgendwo etwas in meiner vereinfachten Logik und ja es handelt sich um eine ehrliche Frage.Von Laie zu Laie:
Die Frage ist nicht die, was die GPU tun muss, sondern ob sie HW für einen Teil der Aufgabe hat oder alles in SW machen muss. Könnten die ROPs/RBEs wenigstens anzeigen, welche Pixel maximal komprimiert sind (wie der Antialiasingflagbuffer aus dem Patent, aber aus Performance- statt Qualitätsgründen), bräuchten die Shader dort gar nichts zu machen und es müsste dort nur irgendein Sample beim Scanout ausgelesen werden, ganz ohne Downfilter. Arbeit für die Shader gäbe es nur an Kantenpixeln, und damit meist insgesamt wesentlich weniger Arbeit als bei den Campermodi, die sich stets ums ganze Bild kümmern müssen. Natürlich waren die Probleme mit den ROPs/RBEs schon vorher ein offenes Geheimnis, aber hier hat man einen Ansatzpunkt, den PR-Bullshit als eben solchen zu entlarven:
Wäre R600 für diese Art AA konstruiert, wäre er mit edge-detection-CFAA schneller als mit den Campermodi, sofern diese langsamer als mit Boxfilter sind (sprich für den komplexeren Filterkernel keine HW vorhanden ist). Vielleicht auch nur ein patentrechtliches Problem, sprich die HW kanns, AMD/ATI will aber nix an Simons Brötchengeber blechen.
Ob auch adaptive Samplemengen in dem Patent gemeint sind? Keine Ahnung, würde ich spontan eher verneinen. Die PDFs wollten aber auch irgendwie nicht richtig, habs daher über den Googlehupf hierher (http://209.85.129.104/search?q=cache:r71g-opOgywJ:www.freepatentsonline.com/20070097140.html+bartlett+filter+antialiasing&hl=de&ct=clnk&cd=2&gl=de), also nicht ganz komplett. Frag ihn doch einfach.
Klar gäbs von Intel mit IP von draußen kein Highend. Aber auch ein IGP wäre doch schon was feines z.B. für UPPCs (oder wie die Knirpse noch heißen), würde bei deren bescheidener Auflösung doch einiges an Power pro Pixel anfallen.
Naja, es matscht immerhin nur die Kanten, und das ist ja auch irgendwie der Zweck.
stell dir einen gut ausmodellierten ball vor. bei dem werden nicht nur die ränder vermatscht, wie es eigentlich sein sollte, sondern auch die balltextur die sich über mehrer polygone streckt.
das ganze würde dann wahrscheinlich sogar ziemlich kontraproduktiv wirken, da polygonkanten innerhalb des balles durch unschärfe quasi "markiert" werden und damit sogar mehr ins auge stechen.
Es sorgt aber für Inhomogenität im Bild, da es zwar an den meisten Stellen besser aussieht, an manchen aber eben nicht. Und die Stellen stechen mir immer schlimmer ins Auge als wenn das gesamte Bild homogen etwas schlechter aussehen würde.
jein, in realen spielen gibt es nur sehr selten situationen in denen CSAA nicht vollständig funktioniert und selbst hier kommt immer noch gutes 4xMSAA zum einsatz so dass die inhomogenität eigentlich kaum auffällt.
Ailuros
2007-06-09, 06:24:43
Von Laie zu Laie:
Die Frage ist nicht die, was die GPU tun muss, sondern ob sie HW für einen Teil der Aufgabe hat oder alles in SW machen muss. Könnten die ROPs/RBEs wenigstens anzeigen, welche Pixel maximal komprimiert sind (wie der Antialiasingflagbuffer aus dem Patent, aber aus Performance- statt Qualitätsgründen), bräuchten die Shader dort gar nichts zu machen und es müsste dort nur irgendein Sample beim Scanout ausgelesen werden, ganz ohne Downfilter. Arbeit für die Shader gäbe es nur an Kantenpixeln, und damit meist insgesamt wesentlich weniger Arbeit als bei den Campermodi, die sich stets ums ganze Bild kümmern müssen. Natürlich waren die Probleme mit den ROPs/RBEs schon vorher ein offenes Geheimnis, aber hier hat man einen Ansatzpunkt, den PR-Bullshit als eben solchen zu entlarven:
Wäre R600 für diese Art AA konstruiert, wäre er mit edge-detection-CFAA schneller als mit den Campermodi, sofern diese langsamer als mit Boxfilter sind (sprich für den komplexeren Filterkernel keine HW vorhanden ist). Vielleicht auch nur ein patentrechtliches Problem, sprich die HW kanns, AMD/ATI will aber nix an Simons Brötchengeber blechen.
Danke erstmal fuer die gute Erklaerung. R600= HW Bug jetzt mal verdammt vereinfacht.
Ob auch adaptive Samplemengen in dem Patent gemeint sind? Keine Ahnung, würde ich spontan eher verneinen. Die PDFs wollten aber auch irgendwie nicht richtig, habs daher über den Googlehupf hierher (http://209.85.129.104/search?q=cache:r71g-opOgywJ:www.freepatentsonline.com/20070097140.html+bartlett+filter+antialiasing&hl=de&ct=clnk&cd=2&gl=de), also nicht ganz komplett. Frag ihn doch einfach.
Es handelt sich nur um dynamische Filter (kommt von jemand der das Zeug besser entziffern konnte als ich). Simon ist momentan nicht erreichbar (ich glaube er ist im Urlaub).
Klar gäbs von Intel mit IP von draußen kein Highend. Aber auch ein IGP wäre doch schon was feines z.B. für UPPCs (oder wie die Knirpse noch heißen), würde bei deren bescheidener Auflösung doch einiges an Power pro Pixel anfallen.
Ultra Mobile PCs (so kann man sich dann auch leichter an das UMPC acronym erinnern) ;)
Serie5 soll verdammt skalierbar sein, aber ich verdaechtige dann schon mit mehrfachen cores. Fuer mehr als eine mainstream GPU wuerde ich am Ende nicht erwarten im besten Fall, aber es kommt wohl auch darauf an was Intel mit dem Zeug genau anstellen wird und ob Larabee eine Eigen-Entwicklung ist oder nicht.
Es kann aber auch durchaus sein dass Intel intern eine eigenes GPGPU Dingsbums entwickelt und parallel dann noch etwas mit IMG IP zusammenschustert.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.