(gelöst) Glare-Algorithmus

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Glare-Algorithmus

Beitrag von 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).
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben:Wenn das Problem darin bestehen sollte das Zeilen schneller als Spalten gelesen/geschrieben werden (horizontal/vertikal)
Tut es nicht. Ist alles gleich langsam.
Alexander Kornrumpf hat geschrieben: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).
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Glare-Algorithmus

Beitrag von 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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: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.
Alexander Kornrumpf hat geschrieben:und die Textur-Repräsentation einfach nur ein alternativer Weg ist auf diesen RAM zuzugreifen
Ja
Alexander Kornrumpf hat geschrieben: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.
Zuletzt geändert von Krishty am 23.02.2011, 17:10, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Glare-Algorithmus

Beitrag von Alexander Kornrumpf »

OK, dann verstehe ich das Problem.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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. -.-
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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
bench.png
Funktionalität gleich meiner Sternendemo:
Krishty hat geschrieben: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) 574-mal heruntergeladen
Zuletzt geändert von Krishty am 25.02.2011, 18:52, insgesamt 2-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Glare-Algorithmus

Beitrag von Chromanoid »

dx11 -.-
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Glare-Algorithmus

Beitrag von 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...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Nein, dann „Sorry!“ von mir dafür.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

Täuscht es, oder hat der Glare in halber Größe keine bilineare Filterung?
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

eXile hat geschrieben: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!
Schrompf hat geschrieben: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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Glare-Algorithmus

Beitrag von 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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Despotist hat geschrieben:Wenn man maximal reinzoomt und die Kamera schnell bewegt ziehen die Sterne Streifen.
Das ist eine Bilderbuchbeschreibung von Motion Blur – entschuldige, dass es für Splines über zehn Kontrollpunkte nicht gereicht hat ;)
Despotist hat geschrieben:Was bedeutet slower? Dann flackern die Sterne nur kurz auf.
Halt faster fünf Sekunden gedrückt und du weißt, wozu es gut ist. Wenn die Sterne durch slower zu flackern beginnen, hast du eine unregelmäßige Framerate (Aero, Flash, sonstwas).
Despotist hat geschrieben:Wenn ich extrem weit rauszoome kommt es zu einem Lightspeed effekt. Dann kann ich aber einen Stern sehen (Sonne?) ohne Überblendung.
Sonne und Mond werden anders gerendert als die Sterne; sie sind bei starker Verzerrung leider (und trotz allem Antialiasing) verpixelt und stechen heraus – da kann ich nichts machen. Die Weitwinkelansicht ist aber eh nur zum Spaß da; zocken kann man mit solchen Öffnungswinkeln eh nichts.
Despotist hat geschrieben:Im Standardmodus (512²) fängt nach etwa einer Sekunde nachdem ich die Kamera zuletzt bewegt habe ein Flackern an als ob schwarze Streifen durchlaufen.
Kommt, weil VSync aus ist; jetzt gerade unschön, aber im finalen Produkt unerheblich.
Despotist hat geschrieben:Zu FPS kann ich nichts sagen. Wenn du solche Infos willst musst du sie schon einbauen ;).
Ich bin schockiert, wie viele Entwickler ihre FPS-Counter selber bauen statt einfach Fraps zu nehmen … im nächsten Release ist aber dann einer drin, euch zuliebe …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Glare-Algorithmus

Beitrag von Despotist »

Krishty hat geschrieben: Ich bin schockiert, wie viele Entwickler ihre FPS-Counter selber bauen statt einfach Fraps zu nehmen
Du nennst Installation und Verwendung einer proprietären 3d Party Software einfach? Deine Programme und Demos machen nicht den Eindruck als wären ein paar Zeilen Code zum selberzählen schwierig für dich ;).
Außerdem ist es nicht möglich oder gar wahrscheinlich dass Fraps das Ergebnis beeinflusst?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Despotist hat geschrieben:Du nennst Installation und Verwendung einer proprietären 3d Party Software einfach?
Gefällt mir ja auch nicht, dass es proprietär ist – aber ein kostenloses, seit fast einem Jahrzehnt für genau diesen Zweck optimiertes Tool zu installieren sollte über den Daumen gepeilt 1000× einfacher als sich DirectWrite-Anbindung, Screenshot-Funktion und sogar Online-Videoaufnahme selber zu schreiben – in allen Anwendungen; nicht nur in meinen eigenen, sondern auch, wenn mir mal jemand was zum testen rüberschickt. Ist ja auch nichts, was der Endbenutzer unbedingt haben muss – ich wollte nur mal kurzes Feedback über die Framerate; das hier ist ein Forum voller Grafikprogrammierer und da hätte ich das (oder ein vergleichbares Tool) so selbstverständlich erwartet wie die aktuelle DirectX-Laufzeitbibliothek. Habe mich geirrt und wenn du es nicht drauf hast, musst du es auch nicht extra für mich installieren. Wollte halt nur einen Überblick, was welche Hardware leistet.
Despotist hat geschrieben:Außerdem ist es nicht möglich oder gar wahrscheinlich dass Fraps das Ergebnis beeinflusst?
Als ich das letzte Mal D3DX für Font-Rendering benutzt habe, verursachte deren Kram tausend Mal mehr Unkosten – und wenn das Anzeigen von drei Zahlen in der Bildschirmecke merkliche Auswirkung auf die Leistung von zwölf 2D-Fourier-Transformationen auf 4096² Punkten hätte, wäre das schon sehr seltsam :) Das Ding braucht ja nicht umsonst Admin-Rechte; das ballert direkt in die Puffer von Windows’ Desktopkomposition. Wenn ich exakte Werte haben wollte, würde ich eh selber in kontrollierter Umgebung messen. (Nicht, dass ich euch das nicht zutrauen würde, aber ich kann unmöglich erwarten, dass jemand Aero und seinen Browser abschaltet, nur, damit ich 1 % exaktere Ergebnisse kriege.)

Ab nächstem Mal schreibt ein Druck auf die Print-Taste die Framerate ins Log. Obwohl das auch wieder scheiße ist weil die Hälfte hier keine Zeilenumbrüche ohne Carriage-Return anzeigen kann … :roll:

————

Übrigens habe ich auch mal mit der Pufferlösung experimentiert. Also, statt Texturen. Weil das ja durch den Treiber optimiert wird. Und habe gleich den Bock verloren.

Die lineare Speicherauslegung ist kacke. Ganz einfach, weil sie viel zu architekturspezifisch ist. Klar: es ist großartig, dass man seine Daten jetzt endlich wie auf der CPU verarbeiten kann. Ein Array, super. Gibt auch viele eindimensionale Anwendungsfälle, wo sowas von Vorteil ist. Aber dafür kann man jetzt mit all dem Scheiß anfangen wie: Belegung der Speicherbänke, Breite der Speicherkanäle, Burst-Writes – und alles entsprechend der Wavefront-Größe. (Für Leute, die noch nie mit GPGPU gearbeitet haben: Wenn eurer Bild 1026 Pixel breit ist statt 1024, dann habt ihr 250 fps statt 6. Ich habe dort keine Null vergessen; es geht hier tatsächlich um Leistungsunterschiede von 50:1 wegen einzelner Pixel.) Und dieser ganze räudige Müll ist dann auf anderer Hardware – egal, ob nächsthöhere Klasse, Konkurrenzprodukt oder in ferner Zukunft befindlicher Prototyp – unbrauchbar und alles ist dort noch langsamer als vorher. Totaler Bullshit. Über Jahrzehnte haben GPUs (zum Glück!) ein abstraktes Speichermodell entwickelt, das man zwar mal besser, mal schlechter ausreizen konnte, auf dessen grobe Eigenschaften man sich aber Hersteller- und Modellunabhängig verlassen konnte. Das ist jetzt weg. Die ganzen GPGPU-APIs geben volle Kontrolle, damit man in Präsentationsfolien 5 % mehr Leistung zeigen kann und es dafür auf 99 % der Hardware langsamer ist als je zuvor.

Unter Optimierung verstehe ich nicht, dass der Compiler keine Schreiboperationen anpackt weil ich die ja absichtlich so angeordnet haben könnte damit die Hardware vier Schreibzugriffe zweier Threads zu einem bündelt – unter Optimierung verstehe ich z.B., mitteilen zu können, dass in einem Datenfeld alles nur ein Mal gelesen und dann überschrieben wird und die Hardware deshalb auf alle Synchronisationsmechanismen inklusive Cache-Kohärenz verzichten kann. Aber nein, Optimierung muss ja immer gleichbedeutend mit Low-Level sein. Da kriege ich das Kotzen.

Aber endlich Speicher zu sparen war geil. Wer einen Blick in die Log-Datei riskiert hat, hat gesehen, dass allein der Glare 295 MiB VRAM verbraucht – trotz Downsampling auf halbe Seitenlänge. Das ist exklusiv der Tatsache geschuldet, dass die wenigen RW-Datenstrukturen so hoffnungslos schlecht implementiert sind (jetzt nicht theoretisch, sondern konkret im Treiber) und ich deshalb auf nur-schreiben und nur-lesen ausweichen musste, inklusive Unkosten zum Vorhalten der Zwischenergebnisse. Zu sehen, dass man auch mit der Hälfte auskommt, war schön.

Ich verzichte aber dankend. Ich pumpe da jetzt nicht noch mehr Lebenszeit rein, damit die Leistungscharakteristik von „generell mittelschlecht“ zu „hochperformant auf Radeon HD 5000-Architektur; speicherlimitiert auf Radeon ab HD 6000; auf GeForce GT 450-470 ausgeglichen falls kleiner Input und Branch-lastig bei großem Input; auf GeForce GT >600 unbrauchbar“ wechselt. Wer das will, kann mich mal.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Ein Kommentar zur Durchführung der FFT: Ich benutze den Stockham-Autosort-Algorithmus anstelle von Cooley-Tukey; der ist um ein Vielfaches schneller. Dann werden z.B. für 2048 Samples FFTs mit Radix 4, 4, 4, 4, 2 und 4 durchgeführt. Allerdings schreibt er out-of-place – er liest die Samples von anderen Positionen als er schreibt. Parallelisiert man das Ganze, hat man eine Wettlaufsituation weil der Input eines FFT-Threads von einem anderen Thread, dessen FFT bereits fertig ist, überschrieben werden könnte. Nun hat man zwei Möglichkeiten:

a) Man lässt alle Threads „ihren“ Input in Register laden, synchronisiert sie, lässt sie ihre FFT durchführen und synchronisiert nach dem Schreiben der Ergebnisse erneut (damit bei Beginn der nächsten FFT keiner mehr den Input anderer Threads überschreibt)

b) Man legt in einem Ping-Pong-Muster zwei Arrays mit Samples an. Aus dem einen wird gelesen und (nachdem die FFT durchgeführt wurde) ins andere geschrieben. Dann werden die Threads synchronisiert und die Arrays getauscht (Output wird zu Input und umgekehrt)

a) hat doppelt so viele Synchronisierungpunkte, dafür verbraucht b) doppelt so viel gruppenlokalen Speicher (und braucht deshalb auch mehr als doppelt so lang zum Kompilieren). Was die pure Anzahl Anweisungen angeht, unterscheiden sie sich um nicht einmal ein Prozent. Die Leistungsunterschiede sind aber horrend:

Auf AMD-Hardware ist b) 5 % schneller. Die Ursache kenne ich nicht; ich tippe darauf, dass der Compiler große Probleme hat, Berechnungen über Synchronisationspunkte hinauszutragen.
Auf Nvidia-Hardware ist a) 14 % schneller. Das liegt wahrscheinlich daran, dass Nvidia-Karten weniger gruppenlokalen Speicher haben und der Scheduler es bei halbem Verbrauch schafft, die Wavefronts in der Recheneinheit zu verdoppeln.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: (gelöst) Glare-Algorithmus

Beitrag von Krishty »

Ich wurde eben nach meinem Kernel gefragt.

ich wollte den Kernel ursprünglich prozedural erzeugen, aus einer Innenaugensimulation:


Das brachte leider zwei Probleme mit sich:

1. Ich habe die Fokussierung nicht richtig hinbekommen und das führte zu sehr starkem Ringing. AFAIK ging es um einen „Fresnel-Term” im Paper, der sich mir nicht erschlossen hat.

Bild

2. Das Filtern der Texturen und das Antialiasing erzeugen ein implizites Rastermuster in den Daten (vor allem Treppen an der eigentlich runden Kontur der Iris!). Sobald man die FFT davon nimmt, schaukelt sich das zu deutlichen Mustern auf.

Bild

Hier ist der Quelltext von irgendeiner Version der Demo. (Habe keine Zeit, ihn zu portieren, darum roher 2011er Stand.)

2011-03-20_Bieder.7z

Ihr findet meinen Kernel unter resources\Bieder\tonemapping\glare\6\glare.png. Der sieht vergrieselt aus, aber das hat einen Grund: Chromatic Abberation ist irre wichtig! Er ist auch verschwommen, aber der Grund ist – wie oben genannt – das Unterdrücken aller Treppchen (Nyquist-Shannon), die sich sonst als Streifen äußern würden.

Ihr müsst den Kernel unbedingt für RGB getrennt und unterschiedlich vergrößert berechnen. Dann ergeben alle dunklen Flecken jeweils kleine Regenbögen. Glaubt mir: ohne lohnt sich das alles gar nicht.

Bild

Außerdem wichtig: Ich habe dem Kernel noch irgendeine Funktion mitgegeben, damit er in der Mitte heller ist als außen. 1/n-Kurve oder so. Ich fürchte, um das herauszufinden, müsst ihr den Quelltext durchsuchen. Sorry.

(Shader liegen unter \products\Bieder\Direct3D 11\)

Ihr werdet dann in einer Zwickmühle stecken: Der Glare ist hübsch, aber sehr weich. Möchtet ihr ihn schärfen, übertretet ihr Nyquist-Shannon und es werden sich Streifenmuster bilden. Ich empfehle eine Deckelung bei einem Radius von 2 oder 3 Pixeln in Kombination mit klassischem Gauss. Bin aber nie dazu gekommen, das zu realisieren.

Entschuldigt, falls was falsch ist. Es ist lange her. Ich würd’s gern wieder aufnehmen, aber es mangelt einfach an Zeit.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Antworten