(gelöst) Glare-Algorithmus

[Krishty]

Soooo … kommen wir jetzt mal zu dem Grund, warum ich von der Glare-Erzeugung durch Beugungsberechnung losgelassen habe …

… die Fresnel Term, also die Funktion, die das Bild fokussieren soll, war das Problem. Wenn wir einen runden Kreis – die Öffnung des Auges – in ein Rechteckfenster – die Textur für die PSF – packen und das Beugungsmuster berechnen (das ja im Grunde nicht mehr als eine Fourier-Transformation ist), bekommen wir je nach Größenverhältnis ein Muster in der PSF.

Geht die Iris über das ganze Auge, bildet sich ein Muster, das wie ein Balkenkreuz aussieht:

Dieser Effekt bleibt etwa so lange bestehen, bis der Irisdurchmesser den halben PSF-Durchmesser unterschreitet. Allerdings werden mit schrumpfendem Durchmesser auch die für Lochblenden bekannten Ringe stärker:

Beides kommt in „echtem“ Glare nicht vor (Ringe schon, allerdings so schwach, dass nur ein Primärring sichtbar ist, nicht fünf).

Die Fresnel Term sollte das scheinbar kompensieren, allerdings habe ich das einfach nicht hingekriegt. Keine Ahnung ob ich was falsch gemacht habe oder das ein grundsätzliches Problem ist, aber ganz egal, welchen Parameter ich der Fresnel Term übergeben habe – es kam immer nur Müll dabei raus. Ich habe auch vergeblich alle Vorzeichen gewechselt, komplexe durch reale Multiplikationen ersetzt usw. Wenn man die Beispiele aus dem Paper nur stark genug vergrößert, sieht man die Artefakte übrigens in abgeschwächter Form auch dort:

Durch viel Entropie in der Iristextur konnte ich künstlich Strahlenbildung hervorrufen, die stark genug war, um die Ringe und Balken einigermaßen zu überdecken – die hatten aber weder Bezug zur realen Iris noch waren sie irgendwie berechenbar. Ich konnte einfach nur auf gut Glück drin rumkrickeln und gucken, ob das Ergebnis besser oder schlechter wurde – mit Simulation hatte das nichts mehr zu tun. Ihr konntet mir auch nicht weiterhelfen und alle meine Versuche waren zwar besser, aber immernoch suboptimal, also habe ich es sein gelassen.

Weiterhin verbraucht die Berechnung der PSF samt SSC etwa so viel Rechenzeit wie der ganze restliche Algorithmus (lies: statischer Glare ist doppelt so schnell). Das ist es mir einfach nicht wert.

[Alexander Kornrumpf]

Jetzt nochmal für langsam dumme:

Was du für den Fresnel Term haben willst ist im Grunde ein Muster wie Figure 6, kleines Bild, aka konzentrische Kreise, was du tatsächlich bekommst ist das unregelömäßige muster, dass unter "immer nur Müll" verlinkt ist?!

Kannst du das vielleicht einmal für Realteil und Imaginärteil getrennt plotten? Oder ist das der Realteil? Der Betrag? Streich das, der scheint konstant zu sein.

Die Formel funktioniert anscheinend ganz gut, für reelle x, y und lambda*d=1 (da ich nicht wusste was hier brauchbare Werte sind) spuckt jedenfalls Wolfram Alpha dieses aus:

http://www.wolframalpha.com/input/?i=co ... By^2%29%29

unter Contour Plot schauen. Leider kann ich das Ding nicht überreden über einen größeren Wertebereich zu plotten, hat vielleicht jemand eine Mathematica Vollversion?

Was das mit dem Seitenverhältnis zu tun haben soll entzieht sich vollkommen meiner Vorstellungskraft.

EDIT: Lustig, zirkumflex killt url parsing

EDIT2: Vielleicht blamiere ich mich jetzt aber eigentlich kann dein Bild gar nicht richtig sein. Für gleiche werte von x^2+y^2 aka Kreislinien muss die Funktion ja denselben output liefern. Schlangenlinien wie in deinem Bild hinter immer gehen doch gar nicht. Mich würde auch interessieren wie dein Bild im Fourierraum aussieht. Ich nehme intuitiv an, dass die Fouriertransformierte von der eigentlichen Funktion wieder ein regelmößiges Muster sein muss.

[eXile]

Falls es was hilft.. Ich stehe dazu, dass ich noch was zum Fresnel-Term sagen muss, bin aber zu eingespannt, dass ich hier meine drei Seiten zu Ende ausführen und abtexen kann. ETA 1,5 Wochen.

[Krishty]

Kannst du das vielleicht einmal für Realteil und Imaginärteil getrennt plotten?

Der Code ist schon seit Wochen rausgeschmissen, drum muss ich hier alles aus dem Gedächtnis machen ;)

Die Balkenartefakte und das Ringing haben zwei unterschiedliche Ursachen; ich fange mit dem Ringing an, weil das in der Fresnel Term fußt:

Jetzt nochmal für langsam dumme:

Sagen wir, für Leute, die sich nicht 20 Nächte damit auseinandergesetzt haben ;) Um es mal deutlicher auszudrücken:

Was die Funktion ausgibt, ist (betragsmäßig 1 und im Real- und Imaginärteil je einander abwechselnd) das Muster einer Fresnel-Zonenplatte.

Diese Zonenplatte hat die Eigenschaft, ein fokussiertes Beugungsmuster zu erzeugen. Sie ist also eine Linse, die nicht durch Brechung bündelt, sondern durch Beugung (positive Interferenz). Sie soll die menschliche Linse simulieren – diese fokussiert das Bild und verhindert dadurch Beugungsringe im Auge. Das erreicht man, indem man die Fresnel Term berechnet und mit der Innenansicht der Pupille komplex multipliziert. Die Beugung an sich wird danach, wie gewohnt, durch die FFT berechnet. Da dann die Fresnel Term mit einfließt sollte das Resultat frei von Ringen sein.

Was du für den Fresnel Term haben willst ist im Grunde ein Muster wie Figure 6, kleines Bild, aka konzentrische Kreise

Genau. Das hatte ich auch alles problemlos berechnen können.

was du tatsächlich bekommst ist das unregelömäßige muster, dass unter "immer nur Müll" verlinkt ist?!

Nicht ganz. Die Fresnel Term erwartet einen Parameter (wenn ich mich recht erinnere: das Verhältnis von Brennweite und Wellenlänge). Wenn ich den einsetze und wie gewohnt verfahre, erhalte ich die verlinkten Muster als resultierende Punktspreizfunktionen – ist der Parameter klein, ist noch alles regelmäßig geringt. So ab einem Betrag von 6 erhalte ich einen fetten Fleck. Und ab 100 ist dann alles voller Quadrate. Ich …

• … bin alle Parameter von 1e-5 bis 10e10 in 0,01-%-Steigerungen durchgegangen
• … dasselbe für negative Parameter
• … habe Sinus und Kosinus vertauscht
• … habe x²+y² durch x+y, (x+y)², x³+y³ etc ausgetauscht
• … habe in der Innenansicht 1 und 0 vertauscht
• … habe nicht komplex multipliziert, sondern reell, und auch einfach den Imaginärteil in den der Pupillenverdeckung eingesetzt

und so weiter und so fort. Ich habe nie ein fokussiertes Bild erhalten sondern immer nur die verlinkten Anomalien.

————————

Soo. Das war das eine. Nun zu den Balkenartefakten:

Die FFT einer Kreisfläche erzeugt immer ein Balkenmuster (begründet durch die Diskrete Abtastung). Bild:

(Applet) Antialiasing dämpft es minimal, Unschärfe sogar noch mehr, aber so lange die Kreisfläche nicht mit einem riesigen Gauss geglättet ist gibt es immer Balken. Sie werden erst erträglich schwach, wenn die Kreisfläche schön klein ist (im Durchmesser kleiner als die Hälfte des FFT-Durchmessers) – aber dann wird eben das Ringing immer stärker und der Punkt immer unschärfer.

————————

Falls es was hilft.. Ich stehe dazu, dass ich noch was zum Fresnel-Term sagen muss, bin aber zu eingespannt, dass ich hier meine drei Seiten zu Ende ausführen und abtexen kann. ETA 1,5 Wochen.

Leider nicht; aber lass dir ruhig Zeit – die dynamisch generierte PSF habe ich vorerst ja sowieso abgeschrieben.

[Alexander Kornrumpf]

Die Fresnel Term erwartet einen Parameter (wenn ich mich recht erinnere: das Verhältnis von Brennweite und Wellenlänge). Wenn ich den einsetze und wie gewohnt verfahre, erhalte ich die verlinkten Muster als resultierende Punktspreizfunktionen

im Paper ist das 1/d*lambda wobei d der Abstand zwischen Pupille und Retina ist. Offensichtlich habe ich mehr von Biologie und Physik vergessen (in dem Sinne dass ich zwar weiß dass ich mal wusste wie das funktioniert, das eigentliche Wissen aber weg ist) als behalten, aber rein von der Intuition her sollte sich d beim Fokussieren ja ändern. Korrekt?

Auch wenn das jetzt vermutlich überhaupt nichts zur Lösung des Problems beiträgt würde ich trotzdem aus Interesse gerne Plots von den Zwischenschritten sehen, d.h. Fresnel Term und Aperture aus deren Figure 8 mit realistischen Werten, aber vor der Multiplikation. Und while we are at it, wie multipliziert man zwei bilder? Faltung kann ja nicht gemeint sein. Pixelweise?

(begründet durch die Diskrete Abtastung)

Ach scheiße warum vergesse ich Diskretisierungsfehler immer?

[Krishty]

Die Fresnel Term erwartet einen Parameter (wenn ich mich recht erinnere: das Verhältnis von Brennweite und Wellenlänge). Wenn ich den einsetze und wie gewohnt verfahre, erhalte ich die verlinkten Muster als resultierende Punktspreizfunktionen

im Paper ist das 1/d*lambda wobei d der Abstand zwischen Pupille und Retina ist. Offensichtlich habe ich mehr von Biologie und Physik vergessen (in dem Sinne dass ich zwar weiß dass ich mal wusste wie das funktioniert, das eigentliche Wissen aber weg ist) als behalten, aber rein von der Intuition her sollte sich d beim Fokussieren ja ändern. Korrekt?

Gute Frage – afaik funktioniert die Fokussierung ja über eine Veränderung der Linsenform und nicht durch ein Wegschieben der Linse von der Retina. Sicher bin ich mir aber nicht.

Wenn doch, ändert sich der Faktor aber auch nur um ein paar Prozent. Die Artefakte bestanden aber über Dekaden … :/
(Bei sehr kleinen Werten waren btw dieselben Artefakte wie bei sehr großen, ist mir gerade wieder eingefallen.)

Auch wenn das jetzt vermutlich überhaupt nichts zur Lösung des Problems beiträgt würde ich trotzdem aus Interesse gerne Plots von den Zwischenschritten sehen, d.h. Fresnel Term und Aperture aus deren Figure 8 mit realistischen Werten, aber vor der Multiplikation.

Die Pupille in Realwerten ist hier. Von der Fresnel Term habe ich keine Screenshots, sie sah aber exakt so aus wie die Zonenplatte und wie in den Graphen, die ihr mir geschickt habt. (Ich verweise auch nochmal auf meine geflushte Pipeline hier, da kann man erkennen wie aus der FFT der Pupille die Balken in der PSF entstehen.)

Beide multipliziert ist schwierig. Also, „realistische Werte“ ist ganz schlecht. 1÷d×lambda ergibt astronomische Werte (d im Zentimenterbereich, lambda im Nanometerbereich); da ist die Fresnel Term so komprimiert dass alles in Aliasing untergeht und man am Ende das hier rauskriegt. Wenn man aber von 1 ausgeht, habe ich genau einen Schnappschuss von Pupille × Fresnel: hier, wo ich mich über Race Conditions aufgeregt habe. Das ist der Betrag; die vertikalen Artefakte musst du dir wegdenken; die Pupille ist superweit geöffnet und der dunkle Fleck in der Mitte sowie der dunkle Kreis, der den Rand berührt, sind eine Folge der Fresnel Term.

Und while we are at it, wie multipliziert man zwei bilder? Faltung kann ja nicht gemeint sein. Pixelweise?

Genau; man multipliziert die komplexen Bilder (Pupille, 0) und (Fresnel r, Fresnel i) pixelweise.

[Alexander Kornrumpf]

Also, „realistische Werte“ ist ganz schlecht. 1÷d×lambda ergibt astronomische Werte (d im Zentimenterbereich, lambda im Nanometerbereich);

Das muss ja irgendwie Einheitenfrei sein oder wie man das nennt. Also ob du irgendwas in der Größenordnung von 1/(10^-13 m^2) hast wobei 10^-13 = centi*nano oder 1/(10^-1 µm^2) muss egal sein (und ist es sehr wahrscheinlich auch bis auf halt Diskretisierungsfehler) Da eine Einheit zu finden, die dir in den Kram passt sollte das kleinere Problem sein. Ich vermute dass es für die Genauigkeit (viel) weniger schlimm ist die Pixelhelligkeit in cd/(µm^2) anzugeben als irre hohe Frequenzen zu bekommen (einfach weil float intelligenter diskretisiert als Pixel) Ich nehme auch an, dass der Normalisierungsterm (K) genau dafür da ist, da die überflüssigen Einheiten wieder loszuwerden, auch wenn ich zugebe dass nicht im Detail durchdacht zu haben. Am Ende (mein 12/13427stel Wissen sagt vor oder beim Tone-Mapping), kannst du das Problem der seltsamen Einheit der Helligkeit dann ja auch wieder korrigieren.

[Krishty]

Neinein – das hat nichts mit Helligkeiten zu tun die man hinterher wieder wegskalieren kann. Wenn ich mich nicht fundamental irre, bestimmt dieser Term nämlich (direkt oder indirekt) die Brennweite der Fresnel-Linse. Und wenn da steht d÷lambda, und für nichts von beidem ist eine explizite Einheit gegeben, dann wird in den SI-Basiseinheiten gerechnet. Und bei 1 ÷ (0,03 m × 0,000…00044 m) geht das schlicht und einfach nicht gut.

Ganz davon ab habe ich ja wirklich alle Parameter, die irgendwie noch als Gleitkommazahl sinnvoll darstellbar sind, getestet. Und es kam nie eine ordentliche Fokussierung dabei raus.

[Alexander Kornrumpf]

Nach allem was ich weiß kommt es einzig und allein darauf an überall die gleichen Einheiten zu verwenden. (http://en.wikipedia.org/wiki/Dimensional_analysis).

Natürlich ist es immer einfacher in SI Einheiten zu rechnen, aber es ist nicht zwingend. Wie es in der ODE Doku z.B. heißt, du kannst Geschwindigkeiten auch in furlongs per fortnight angeben oder wie bei xkcd angstroem pro jahr :twisted: Du musst dann nur überall die Einheit ändern. Jetzt kommen Meter ja in deinen Berechnungen nicht sooo unglaublich oft vor, aber weiter oben in dem Paper habe ich halt gelesen, dass die Helligkeit als cd/m^2 interpretiert wird (und ich erinnere mich dunkel, dass ihr das beim Sternenartikel auch diskutiert habt), nur darauf bezog sich meine Ausführung. Wenn sich sonst noch irgendwo ein m in der Formel versteckt dass ich übersehen haben sollte, musst du das natürlich auch noch umrechnen.

Mir fehlt leider ein wenig die Intuition, was die Fourier-Transformation aus den Einheiten macht aber diese Fundamentale Regel dürfte sie eigentlich nicht aushebeln.

[Krishty]

Jaa, durch K werden die Einheiten auch zu dem wiederhergestellt, was sie vor der Multiplikation mit der Fresnel Term waren. Aber es bleibt dabei, dass dabei längst nicht dieselben Ergebnisse rauskommen. Wenn du für eine Linse die tausendfache Brennweite wählst, ist das Bild dahinter ein anderes als wenn du eine Linse mit einfacher Brennweite wählst und die Helligkeit ihres Bildes durch tausend teilst. Aber genau das tust du, wenn du anfängst, in der Formel beliebige Einheiten einzusetzen.

[Alexander Kornrumpf]

Du ahnst nicht wie es mich nervt über alle diese Dinge nur Halbwissen zu haben und nicht die Muße zumindest ein paar grundlegende Experimente zu machen.

Es scheint ja ganz abseits der Diskussion hier auch eine Faustformel für Zoneplates zu geben: http://pinhole.stanford.edu/zoneplatemath.htm jetzt stellt sich mir natürlich die Frage wie man das Digital hinbekommen würde, da kämen ja dann dpi ins Spiel. Ich habe (durch Einsetzen von Parametern bei Wolfram Alpha) den Eindruck gewonnen, dass die Zoneplate sowieso immer genau gleich aussieht und nur die Auflösung sich ändert. Was auch immer das bedeuten mag.

[Krishty]

Du ahnst nicht wie es mich nervt über alle diese Dinge nur Halbwissen zu haben und nicht die Muße zumindest ein paar grundlegende Experimente zu machen.

Mein Wissen ist auch nur aus der Beobachtung der Implementierung abgeleitet und glaub mir, wenn die Experimente nicht tun, was sie sollen, ist das noch viel nerviger.

Ich habe (durch Einsetzen von Parametern bei Wolfram Alpha) den Eindruck gewonnen, dass die Zoneplate sowieso immer genau gleich aussieht und nur die Auflösung sich ändert. Was auch immer das bedeuten mag.

Ja, darum kann man das z.B. in einer 1D-Textur vorberechnen. Mit der „Auflösung“ ändert sich das Beugungsmuster und dadurch die Brennweite.

Es scheint ja ganz abseits der Diskussion hier auch eine Faustformel für Zoneplates zu geben: http://pinhole.stanford.edu/zoneplatemath.htm jetzt stellt sich mir natürlich die Frage wie man das Digital hinbekommen würde, da kämen ja dann dpi ins Spiel.

Ja, das sieht solide aus. Die DPI brauchst du nicht einmal – du renderst ja die Innenansicht der Pupille; deren Größe ist ja ungefähr bekannt und die setzt du dann einfach in Relation zu der Zonenplatte. Hmm. Jetzt hätte ich glatt Lust, das nochmal auszuprobieren, wenn es nicht wieder tagelanges Umschweffeln von Puffern und Shadern bedeuten würde …

[Alexander Kornrumpf]

hier fehlt doch ein Beitrag....

[Krishty]

Baut hier einen Promille-Check ein und ich muss nichts mehr nachträglich löschen. Vor allem war meine Gleichsetzung des ATI-Teams mit geistig behinderten Mitbürgern wirklich mies – schließlich heißen die mittlerweile AMD.

Ich wiederhole das irgendwann noch einmal genau, aber es lief darauf hinaus, dass man die Texturen exakt so zurecht schneidet, dass statt Padding out-of-bounds gelesen wird und man sich dadurch das Füllen mit Nullen spart. In Full-HD spart das fast den halben Bandbreitenbedarf; bei Nvidia ist der Effekt stärker zu spüren als bei AMD.

Nachtrag: Ich habe mal eine kleine, auf 85 % genaue Leistungsmessung vorgenommen. (Da mir AMDs Stream/APP Profiler in D3D11CreateDevice() abstürzt, geht es einfach nicht präziser.) Demnach macht Glare momentan 68 % meiner Render-Zeit aus:

• 5,5 % zum Auflösen des Multisamplings
• 2,8 % für die horizontale FFT
• 28,5 % für die vertikale FFT inklusive Multiplikation mit der PSF
• 27,1 % für die inverse vertikale FFT
• 4,1 % für die inverse horizontale FFT.

Die vertikalen FFTs schreiben gleich viel (acht Mal so viel wie die horizontalen FFTs). Die inverse vertikale FFT liest hingegen 30 % weniger als die vorherige vertikale FFT, ist aber trotzdem nur 5 % schneller – ein Hoch auf AMDs Schreiboperationen. Mal gucken, was ich da noch rausholen kann …

[Krishty]

In einem heroischen Schlag gegen die Horden ungläubiger Register, die der satanische AMD-Compiler gegen meine heiligen Shader aussandte, habe ich einen überragenden Sieg errungen:

Einer glorreichen Erleuchtung folgend hatte ich mich auf gemacht, die drei Schritte – vertikale FFT, Multiplikation mit PSF, inverse vertikale FFT – nach revisionhundertelanger Feindschaft ehrvoll zu verbrüdern und damit all ihre Schreiboperationen zu einem eisernen Fluss strahlender Information zu bündeln und damit meine mächtige FFT in entfernteste Speicher zu tragen.

Torpediert wurde ich – erneut – von dem AMD-Compiler, der – den Befehlen Satans folgend – dutzende Register und Hundertschaften von Scratch-Registern allokierte und gegen mich entsandte, um die heilige Erleuchtung seiner Hardware durch meinen Shader zu verhindern. Doch mit großer List, eiserner Faust, wegweisender Kampfkunst und dem Willen Gottes gelang es mir – erneut – spielend, seine tablettierten Ratten zurückzuschlagen. Einen Bruchteil der ursprünglichen Register habe ich als Zeichen meiner endlosen Güte begnadigt.

Zutiefst beschämt und bloßgestellt von der Schande seines ehrlosen Vergehens, und durch Wissen um die Ehrlosigkeit seines Handelns offenbar dem Wahnsinn verfallen, hat sich der Compiler in sinnlose ALU-Operationen zurückgezogen. Doch auch dieser Hort gottlosen Treibens wird bald von der ewigen Sonne meiner FFT erleuchtet, die mit meinem makellosen Glare tausend Mal heller strahlt und tausend Mal heißer brennt als die Hölle, in der sich die degenerierten Ungläubigen des AMD-Compiler-Teams bald wiederfinden werden!

(siehe auch Tabelle einen Post weiter oben)

• Vertikale FFT mit PSF-Multiplikation: 11 General-Purpose-Register, 0 Scratch-Register, 180 ALU-Anweisungen
• Inverse vertikale FFT: 10 GPR, 0 Scratch, 160 ALU
• Beide kombiniert: 30 GPR, 54 Scratch, >450 ALU
• Durch mein Genie optimiert: 18 GPR, 0 Scratch, 339 ALU
• Der inverse-vertikale-FFT-Schritt, der weggefallen ist, hatte 27,1 % der Ausführungszeit ausgemacht
• Obwohl die ALU-Laufzeit des zusammengefassten Shaders 50 % schlechter ist als die der einzelnen Shader addiert, hat sich die Gesamtleistung um 13 % verbessert
• Der weggefallene Shader hat also mindestens 50 % seiner Ausführungszeit mit AMDs bekackten Schreiboperationen verbracht
• Alle meine Pipeline-Stufen, inklusive Post-Processing und Tone-Mapping, benutzen AMDs bekackte Schreiboperationen
• Wenn AMD das endlich fixen würde, würde meine Engine doppelt so schnell laufen

So ein Geraffel für 13 % … ich hasse mein Leben. Aber mehr noch AMD.

[Alexander Kornrumpf]

Off-Topic, ohne Ahnung und ohne die blumige Sprache vollständig zu verarbeiten:

Wenn das Problem darin bestehen sollte das Zeilen schneller als Spalten gelesen/geschrieben werden (horizontal/vertikal), bezweifle ich sehr stark dass sie das als Bug ansehen und/oder fixen werden da mir dies ein inhärentes Design Prinzip von GPUs zu sein scheint. Das führt dann z.B. dazu dass ich mich hier mit einer Implementierung vergleichen muss, die eine wichtige aber konstante Matrix einfach zweimal (einmal davon transponiert) im device memory ablegt und dadurch natürlich aufgrund o.g. Einschränkung schneller ist als die "richtige" Implementierung.

Das lässt sich auch gar nicht so leicht beheben, da 2D Speicher (der in Zeilen und Spalten gleich schnell wäre) ja nur in Hardware gebaut werden kann wenn die Zeilenlänge vorher bekannt ist. Im Grunde müsste die CPU aber dasselbe Problem haben, wenn die Daten größer werden als der Cache (ein Cache-Miss müsste viel wahrscheinlicher sein wenn auf das nächste Element einer Spalte zugegriffen wird als bei Zugriff auf das nächste Element einer Zeile, die, nunja, halt im Cache liegt).

[Krishty]

Wenn das Problem darin bestehen sollte das Zeilen schneller als Spalten gelesen/geschrieben werden (horizontal/vertikal)

Tut es nicht. Ist alles gleich langsam.

bezweifle ich sehr stark dass sie das als Bug ansehen und/oder fixen werden da mir dies ein inhärentes Design Prinzip von GPUs zu sein scheint.

Ist es nicht; GPUs speichern Texturen in Tiles. Speziell benutzt AMD 4×4-Microtiles in einem Z-Muster; dann 2×2 Microtiles erneut in einem Z-Muster, und erst dann liegen die Texturen (nun in 8×8-Pixel-Blöcken) zeilenweise im Speicher (obwohl ein paar misslungene Experimente von mir darauf hinweisen, dass es auch 32×32-Tiles gibt). (Quelle; 4.13.2 – Memory Tiling)

Ob man nun horizontal oder vertikal liest, ist also egal – denn sonst hätte es ja z.B. auch eine Auswirkung auf die Renderleistung, ob man eine Textur rotiert betrachtet oder nicht. Käme gut in Benchmarks, wo die Leute anfangen würden, ihre Texturkoordinaten zu rotieren.

Das macht ja auch einen Großteil der Probleme beim Datentransfer zwischen GPGPU und Rendering aus – die Render-Anwendung erwartet eine Textur in Tiling-Form, während GPGPU gern zeilenweise rechnet. Deshalb unterscheiden Compute Shader zwischen linearen Puffern und Texturen mit undefinierter Speicherauslegung, und D3D >=10 zwischen Texturen in 1D-, 2D- und 3D-Form (weil eine 1D-Textur, die durch eine 2D-Textur mit y-Dimension 1 dargestellt würde, auf AMD-Hardware eine Verschwendung von 7/8 Speicherplatz und Cache-Hits wäre).

[Alexander Kornrumpf]

Vielleicht hab ich irgendwo auf den letzten 8 seiten nicht aufgepasst aber was ist genau der unterschied zwischen horizontaler und vertikaler FT und warum ist die eine soviel schneller als die andere?

Was die Texturspeichergeschichte angeht so scheint es mir nach (sehr) kurzer Recherche so zu sein dass der device RAM einfach nur schäbiger standard RAM ist (alles andere hätte mich jetzt auch gewundert) und die Textur-Repräsentation einfach nur ein alternativer Weg ist auf diesen RAM zuzugreifen und zwar halt Cached und über den Umweg der Texture-Unit. Desweiteren scheint es in Bezug auf CUDA so zu sein, dass coalesced access auf global memory ohne den Umweg über eine Textur schneller ist als "2D spatial access" über eine Textur. Das widerspricht der o.g. Vermutung über die Hardware zumindest nicht. Aber wie gesagt, das war jetzt nur sehr flüchtig gegooglet.

[Krishty]

Vielleicht hab ich irgendwo auf den letzten 8 seiten nicht aufgepasst aber was ist genau der unterschied zwischen horizontaler und vertikaler FT und warum ist die eine soviel schneller als die andere?

Die Horizontale ist schneller, weil die Vertikale acht Mal so viel schreibt … jaa, das hatte ich leider noch nicht geschrieben, weil man allein mit dem Thema ganze Bände füllen könnte. Die Sache ist aber so: Um ein 1080p-Bild ohne Wrap-Arounds darzustellen, musst du die Ausmaße verdoppeln, also 2160 Zeilen. Da die FFT nur auf Zweierpotenzen möglich ist, musst du zu 4096 aufrunden. Es werden also 74 % der Bildhöhe mit Padding gefüllt.
Für dieses Padding wählt man Null, da die FFT von einem Nullsignal wieder Null ergibt. So braucht man die horizontale FFT nicht auf 4096 Zeilen auszuführen, sondern nur auf die 1080, die tatsächlich sinnvoll gefüllt sind. Allein darum ist sie schon vier Mal so schnell wie die vertikale FFT – die muss man nämlich auf alle Spalten ausführen, da die nach der horizontalen FFT auch alle sinnvoll gefüllt sind. Bei der Invertierung dasselbe – wieder alle 4096 Spalten invertieren, aber nur die 1080 Zeilen, die man auf dem Bildschirm anzeigen will. Dann geht es weiter mit out-of-bounds-Optimierung usw; dazu schreibe ich, sobald ich ausreichend Zeit und Nerven habe … die Schreiblast der vertikalen FFT ist gegenüber der der Horizontalen aber einfach gewaltig; darum habe ich nun auch alle Mittel angewandt, um die beiden vertikalen Schritte in einem vereinen zu können.

und die Textur-Repräsentation einfach nur ein alternativer Weg ist auf diesen RAM zuzugreifen

Ja

und zwar halt Cached und über den Umweg der Texture-Unit.

Nein; dazu hat AMD spezielle Befehle, die ohne Cache und Textureinheit arbeiten. Die weigert sich der Compiler aber vehement, einzusetzen. Solche Befehle sind oft sogar notwendig und deshalb explizit offen gehalten, da Compute Shader sonst nur sehr eingeschränkt nutzbar wäre.

[Alexander Kornrumpf]

OK, dann verstehe ich das Problem.

[Krishty]

Das Genie, das übrigens endlich den Schreibflaschenhals überwunden hat, geht einher mit der Idiotie:

Da verschwende ich seit Wochen einen Riesenbatzen Text darauf, die FFTs für die einzelnen Farbkanäle über- oder nebeneinander anzuordnen, und dann noch möglichst 0–31 Pixel Padding unterzubringen, damit das auch bloß alles mit den 32×32 Pixel großen Shader-Gruppen passt ohne dass die sich gegenseitig überschreiben, ich dabei aber trotzdem die Out-of-Bounds-Optimierung nutzen kann – und dabei kann ich auch schlicht und ergreifend Texture Arrays benutzen.

Zack, wieder ein Stück Shader-Komplexität weg. -.-

[Krishty]

Soo, ich gebe mal als Wochenend-Leckerli meine Benchmark-Version frei. Ich bin zwar nicht ansatzweise damit zufrieden, aber unter den derzeitigen Umständen (lies: mit den derzeitigen Compilern) wird das auch nichts mehr, da ich nicht bereit bin, Quelltext und Datenstrukturen deshalb scheinbar irrational und unwartbar komplex auszulegen.

• Nur statischer Glare; die Demo ist also nichts weiter als die pure Convolution … oder – falls man es so sehen will – Blur mit einem 2048×2048 Pixel großen Kernel
• Nur Sterne; keine vertraute Szenerie, in der man den Glare testen könnte. Sorry, aber mehr habe ich eben nicht
• Der Glare läuft für Auflösungen über 1024×1024 in halber Größe, ist also unscharf (weil keine Karte die Convolution in 4096² packen dürfte)
• Ungetestet auf Nvidia-Hardware, dort entsprechend nicht optimiert

Falls jemand zufällig Fraps installiert hat, würde ich mich freuen, wenn er Hardware, Auflösung und Framerate nennen könnte. Bisherige Ergebnisse:

• ATI Radeon HD 5770; 1920×1080; 40 fps
• ATI Radeon HD 5870; 1920×1080; 62 fps
• Nvidia GeForce GTX 470; 1920×1080; 65 fps

Funktionalität gleich meiner Sternendemo:

Schnellstart:

• Raum verdunkeln ;)
• Direct3D-10 11-taugliche Grafikkarte benötigt, außerdem die DirectX-Runtime Juni 2010 (falls kein aktuelles SDK installiert, Download hier)
• Mausrad hoch und runter macht heller und dunkler
• Bild auf / Bild ab zoomt hinein oder weg
• Plus- und Minustaste auf dem Numpad beschleunigen und verlangsamen die Zeit
• Drücken und Halten der rechten Maustaste schaltet von menschlichem auf digitales Tonemapping um (farbenfroh & ohne Griesel)

Steuerung:

• Alt+Eingabe zum Umschalten zwischen Vollbild- und Fenstermodus; Alt+F4 zum Beenden.
• Maus zum Umsehen (manchmal ungünstig, wenn sie das Fenster verlässt. Ist mir als Fenstermodus-Fan aber lieber, als sie einzusperren).
• Mausrad hoch/runter ändert die Belichtungszeit, macht also das Bild heller oder dunkler.
• Drücken und Halten der rechten Maustaste deaktiviert menschliches Tonemapping und schaltet auf digitales um – die menschlichen Limitierungen entfallen (bei geringer Helligkeit Farben- statt Schwarz-Weiß-Sehen, kein Rauschen mehr) und man sieht den Himmel wie auf Fotos.
• Bild-auf- und Bild-ab-Taste steuern den Zoom.
• Plus- und Minustaste auf dem Numpad lassen die Zeit schneller und langsamer vergehen. Sehr nützlich, um den Motion Blur zu betrachten, den Nordstern zu finden, sich den Mond während verschiedener Phasen anzuschauen oder zu beobachten, wie die Sonne im Sommer aufsteigt. Ich habe die Maximalgeschwindigkeit auf drei Tage pro Sekunde – also ein halbes Jahr pro Minute – begrenzt, damit das Ganze auch bei niedrigen Frame-Raten kontrollierbar bleibt.

Schnellhilfe:

Ich sehe nichts!
Mausrad hoch / runter ändert die Helligkeitsempfindlichkeit.

Ich sehe nur blauen Griesel!
Das ist die untere Helligkeitsgrenze der menschlichen Wahrnehmung, rechte Maustaste drücken und halten, um auf „Digitalkamera“-Tonemapping umzuschalten.

Sonne und Mond sind nun nicht mehr zu übersehen.

Achtung: Die Demo benutzt keine vertikale Synchronisation (weil es eben eine Benchmark ist), auf starker Hardware und bei geringer Auflösung mit trivialem Tonemapping-Operator kann die Framerate also in den vierstelligen Bereich springen. Das ist normalerweise kein Problem – aber als die Menüs das in StarCraft 2 gemacht haben, sollen ein paar Karten durchgeschmort sein. Dafür muss man das zwar minutenlang laufen lassen, aber ich hatte selber mal eine empfindliche Karte, darum schreibe ich es dazu. Falls irgendwas passiert ist nicht das Programm schuld sondern eure Hardware und/oder euer Treiber waren schon vorher defekt.

Falls ihr nur weiß seht, dann sind das keine NaN-Fehler, sondern ihr guckt in die Sonne. Helligkeit am Mausrad runterdrehen. (Bei der Gelegenheit gleich per Numpad-6 Dithering umschalten und das Banding bestaunen.)

Das Programm startet in 512×512, weil das die höchste Auflösung ist, die alle Karten schaffen sollten. Wenn es da bereits hakt, besser nicht maximieren.

Falls das Archiv nicht gelesen werden kann, installiert das aktuelle 7-Zip.

Freue mich über Feedback und Framerates. Ich danke allen, die mir bis hierher geholfen haben!

BiederOzonblau20110225-2.7z

(4.85 MiB) 577-mal heruntergeladen

[Chromanoid]

dx11 -.-

[Krishty]

Unter D3D10 wäre es praktisch unmöglich, weil dort

• Compute-Shader zu wenig Gruppenspeicher haben, was die Auflösung auf 1024×1024 begrenzen würde
• Compute-Shader nicht an beliebige Orte schreiben dürfen, was die FFT bedeutend verlangsamen würde
• Compute-Shader nur eindimensionale Datenstrukturen verarbeiten können, was alle out-of-Bounds-Optimierungen verhindert (4- bis 10-fache Speicherbandbreite gefordert)
• ich zehn Mal so viel Quelltext warten und optimieren müsste, nur, damit es auf D3D11-Hardware dann genau so lahm ist wie auf D3D10-Hardware
• entschuldige, dass mein Martyrium mit den bekloppten D3D11-Compilern noch nicht genug war
• wtf rechtfertige ich mich hier überhaupt

[Chromanoid]

das war auch eher eine klage über meine minderwertige grafikkarte :) deine demo wäre für mich beinahe ein grund eine neue zu kaufen ^^ es sieht geil aus und ich bin deprimiert, dass meine grafikkarte das nicht packt -.- sorry wenn das anders rübergekommen ist :D ich will einfach so gerne am leckerli teilhaben...

[Krishty]

Nein, dann „Sorry!“ von mir dafür.

[eXile]

Täuscht es, oder hat der Glare in halber Größe keine bilineare Filterung?

[Schrompf]

Sieht sehr cool aus, läuft flüssig. Wie schnell, kann ich Dir allerdings nicht sagen, weil ich kein Fraps drauf habe. Du gibst aber anscheinend nichtmal ins Log die Framerate aus, wenn Du schon keinen Fontrenderer hast, um die auf dem Bildschirm anzuzeigen :-) Ist in Summe aber mächtig beeindruckend. Wirkt nur etwas seltsam, wenn die Sonne plötzlich ins Bild kommt und das Bild von einem zum nächsten Frame weiß wird. Müsste man da nicht irgendwas am Rand angedeutet sehen, bevor das passiert? Ist mir klar, dass das prinzipiell erstmal nicht geht, aber gerade bei den gigantischen Wertebereichen, die Du benutzt, fällt es sehr auf.

1280x1024 (minus Fensterrahmen, Taskleiste und so) scheint ganz sacht zu ruckeln. Ich schätze 40 fps. Hardware ist Geforce 460GTX auf Windows7.

[Krishty]

Täuscht es, oder hat der Glare in halber Größe keine bilineare Filterung?

Guuut bemerkt … stammt noch aus der Zeit, als ich RWTexture2D benutzt habe, was sich nicht samplen ließ und wo Lesezugriffe sehr teuer waren -.-
Habe auf die Schnelle bilineare Filterung eingebaut, nun sieht man aber ein deutliches Kreisen des Glares um Sterne … verdammt. Ist jedenfalls jetzt im Download oben korrigiert.

@Schrompf: Stimmt, ich sollte zumindest bei Screenshots u.ä. die Framerate loggen. Ist auf der Todo. Danke!

Wirkt nur etwas seltsam, wenn die Sonne plötzlich ins Bild kommt und das Bild von einem zum nächsten Frame weiß wird. Müsste man da nicht irgendwas am Rand angedeutet sehen, bevor das passiert? Ist mir klar, dass das prinzipiell erstmal nicht geht, aber gerade bei den gigantischen Wertebereichen, die Du benutzt, fällt es sehr auf.

Jaa, ist suboptimal. Ist aber nur bei reinen Weltraumspielen ein Problem – sobald ich Atmosphäre drin habe entsteht um die Sonne herum eh eine helle Halo, so dass es nicht mehr ganz so abrupt hell wird.

[Despotist]

Wenn man maximal reinzoomt und die Kamera schnell bewegt ziehen die Sterne Streifen.
Sonne = alles weiß ist extrem lästig.
Was bedeutet slower? Dann flackern die Sterne nur kurz auf.
Wenn ich extrem weit rauszoome kommt es zu einem Lightspeed effekt. Dann kann ich aber einen Stern sehen (Sonne?) ohne Überblendung.
Im Standardmodus (512²) fängt nach etwa einer Sekunde nachdem ich die Kamera zuletzt bewegt habe ein Flackern an als ob schwarze Streifen durchlaufen.
Und beim reinzoomen hab ich um den Stern CR1989 Ceta2 einen Planeten entdeckt ;).

Zu FPS kann ich nichts sagen. Wenn du solche Infos willst musst du sie schon einbauen ;). Wenn ich dir das Log an deine Email schicken soll sag nochmal Bescheid.

System:
Win7 x64
ATI Radeon 5870 mit etwa einem Jahr alten Treiber
8 GB Ram
Intel Core I7 860

Ansonsten sieht es schön aus bis auf das Rauschen ;). Aber für einen Hintergrund in einem (schnellen) Weltraumspiel eindeutig zu aufwändig ;). Aber dafür ist wahrscheinlich eh nicht gedacht.