ZFX + Developia

Verfasst: **15.09.2012, 16:49**

Schrompf hat geschrieben:Der Vorschlag klingt gut! Und was tun wir, wenn der Typ gar nichts davon liest, weil er nur hauptberuflich hunderte Foren wie unseres zumüllt, ohne irgendwo mitzulesen?

Bei dem ersten Verstoß eine PM schicken (da geht ja eine Benachrichtigung an die hinterlegte E-Mail-Adresse), bei dem zweiten Verstoß sperren. Auch ich bin es Leid, diese ganzen Threads jedes mal als gelesen zu markieren.

Nachtrag:

CodingCat hat geschrieben:Das ist richtig übel, bis eben dachte ich, auf modernen GPUs wäre Flow Control nur eine Frage des Ausmaskierens einzelner Threads.

Ja, aber warum ist das so übel? Ich meine, im ersten Fall wird die for-Schleife übersprungen, im zweiten Fall wird die for-Schleife nach einer weiteren Abfrage übersprungen; von den Laufzeiten her sollte das doch keinen Unterschied machen. Ich verstehe es nicht.

Verfasst: **15.09.2012, 18:46**

Ich kriege meine Quaternions nicht hin. Egal, was ich mache – immer ist irgendwas negiert.

Wenn ich alle Multiplikationen in der falschen Reihenfolge (also von links nach rechts; ich weiß, dass Quaternion-Multiplikationen verdreht sind) durchführe, funktioniert alles. Obwohl es eindeutig nicht darf.

Verfasst: **15.09.2012, 22:42**

eXile hat geschrieben:Nachtrag:
CodingCat hat geschrieben:Das ist richtig übel, bis eben dachte ich, auf modernen GPUs wäre Flow Control nur eine Frage des Ausmaskierens einzelner Threads.
Ja, aber warum ist das so übel? Ich meine, im ersten Fall wird die for-Schleife übersprungen, im zweiten Fall wird die for-Schleife nach einer weiteren Abfrage übersprungen; von den Laufzeiten her sollte das doch keinen Unterschied machen. Ich verstehe es nicht.

Das ist es ja. Das Einzige, was im Diff der Assemblercodes für die continue-Variante anders ist, ist folgender Zusatz:

Code: Alles auswählen

 if_nz r0.w
   continue

Damit wächst die Ausführungszeit mit zunehmender Anzahl übersprungener Schleifendurchgänge ins Unermessliche. Und ja, in der anderen Variante wird weiter unten in der for-Schleife auch einfach übersprungen. Ich verstehe es selbst nicht.

Verfasst: **18.09.2012, 14:23**

Ich bin in einer Sackgasse. Es macht keinen Unterschied, ob ich meine Strahlbeschreibungen (Orig + Dir, 6 floats!) während der Schnitttests inkohärent indiziere oder perfekt kohärent und kompakt lese (3 uints). Die Dekodierung (Trigonometrie, Wurzeln, Divisonen) kostet mich offenbar gerade die 40 ms, die ich beim Speicherzugriff spare.

Obendrein macht es keinen Unterschied, ob ich das Ergebnis meiner Schnitttests überhaupt verwende (inkohärente Atomic Updates!) oder einfach verwerfe. Bin ich mir dieser Masse von Speicherzugriffen ernsthaft ALU-Limitiert?!

Verfasst: **18.09.2012, 14:37**

Schnell:

Code: Alles auswählen

if (rayCount != 12512)
	return;

if (!hit)
	return;

Langsam:

Code: Alles auswählen

if (!hit)
	return;

if (rayCount != 12512)
	return;

Die rayCount-Bedingung ist nur eine Art, den Shader zu beenden, ohne dass der Compiler alles danach (oder davor) wegoptimieren kann.

~~Sieht mal wieder nach einen massiven Branching-Problem aus.~~ Das ganze liegt in einem Pixel Shader, und hit kann naturgemäß sehr inkohärent sein. :evil:

Verfasst: **18.09.2012, 15:47**

clip spart im angegebenen Testfall beim Branching 15 ms, führt aber zu Treiberreset sobald danach auch nur ein UAV mit Atomics angerührt wird.

Verfasst: **18.09.2012, 16:45**

Ich verbringe ~~80 ms~~ 15 ms damit, für jeden Pixel Shader das passende Dreieck aus dem Speicher zu laden. Verschieben in nointerpolation-Register sprengt aber offenbar ein internes Limit, das die Anzahl der gleichzeitig ausgeführten Pixel Shaders ebenfalls extrem dezimiert.

Verfasst: **18.09.2012, 17:23**

Das Ganze zeigt mal wieder, WIE vorsichtig man beim Durchmessen sein muss. Das, was ich vorhin als Branching-Overhead gemessen hatte, war tatsächlich einfach nur ein Extremfall von Compiler-Optimierung, in dem der Shader-Compiler ganze Zweige in Abhängigkeit ihrer Beziehung untereinander mal weit nach vorne gezogen hat, mal aber auch nicht.

Dennoch, nach meiner ganzen Messerei müsste der Shader nach Adam Ries(e) mindestens die vierfache Zeit dessen in Anspruch nehmen, was ich am Ende tatsächlich an Gesamtlaufzeit erhalte. Ein Paradebeispiel für die außerordentliche Fähigkeit der GPU, Latenzen zu verstecken.

Leider bin ich deshalb jetzt trotz einiger Optimierungen auch noch immer keinen Deut schneller

Verfasst: **18.09.2012, 18:44**

Code: Alles auswählen

float azimuth = compactAzimuth / (float) MaxShortUInt * (2.0f * PI) - PI;

Daraus macht mir fxc Assembler Dump:

Code: Alles auswählen

mad r2.w, r2.w, l(0.000096), l(-3.141593)  // azimuth<0:[-3.14159f,3.14159f]>

Zwei Dezimalen. Ich kann nur hoffen, dass das nur die Assembler-Ausgabe zu Debug-Zwecken betrifft.

Verfasst: **18.09.2012, 19:34**

Ich finde in meinem Release-C++ ständig

mulss xmm#, dword ptr [__real@3F800000]

(lies: Multiplikation mit 1.0f).

Verfasst: **18.09.2012, 20:34**

Krishty hat geschrieben:Ich finde in meinem Release-C++ ständig

mulss xmm#, dword ptr [__real@3F800000]

(lies: Multiplikation mit 1.0f).

Sowas kannst du als Compiler auch nur in der Release-Version generieren. In der Debug Config kannst du dich schließlich nicht drauf verlassen, dass ein guter moderner Coder das für dich rausoptimiert. :D

Verfasst: **18.09.2012, 20:53**

Kann ich eine Quaternion-Rotation invertieren, indem ich w negiere? Ich hatte eine Quelle gefunden, die die Imaginärteile negiert, aber mit w geht es auch und es sind zwei Operationen weniger … scheint zu klappen; ich weiß nur nicht, ob ich auf der sicheren Seite bin …

?

Obligatorisches Gejammer: Mein Handy scheint einen Garbage Collector zu nutzen. Jedes Mal, wenn ich 31 Kurznachrichten gelöscht habe, friert es beim Löschen der 32. für zwei Minuten (!) ein. Scheint O(n²) zu sein, denn 500 SMSen früher waren es etwa acht Minuten.

Verfasst: **18.09.2012, 22:36**

Invertieren: Schau dir nochmal die Achse-Winkel-Darstellung an, und welche Eigenschaften sin/cos bzgl. 0-Punkt-Symmetrie haben...

Verfasst: **18.09.2012, 22:52**

Bei Achse-Winkel ist der Fall eindeutig – man kann entweder die Achse invertieren oder den Winkel. (Beides invertieren bedeutet, die Transformation unverändert zu lassen – das nutzen ja bspw. Crytek, um Quaternions in drei statt vier Zahlen zu speichern.)

Sinus/Kosinus: Ich weiß, dass der Realteil das Kosinus beherbergt und die Imaginärteile das Sinus; und dass (sin, -cos) bzw. (-sin, cos) 90-Grad-Rotationen eines Vektors sind; und dass Quaternions mit Sinus und Kosinus des halbierten Winkels arbeiten. Hier werden Sinus und Kosinus aber nicht vertauscht, sondern nur eins invertiert. Liege ich richtig, dass dadurch die Rotation gespiegelt wird, und das der Invertierung gleichkommt?

Verfasst: **19.09.2012, 00:29**

Bwargh.

D3D11: ERROR: ID3D11DeviceContext::CSSetUnorderedAccessViews: The UnorderedAccessView at slot 2 overlaps with the UnorderedAccessView at slot 3. It is not possible to write to the same Subresources at the same time. [ STATE_SETTING ERROR #2097403: DEVICE_CSSETUNORDEREDACCESSVIEWS_INVALIDVIEW ]

D3D11: ERROR: ID3D11DeviceContext::CopySubresourceRegion: Cannot invoke CopySubresourceRegion when the source and destination Subresource are same Subresource of the same Resource. [ RESOURCE_MANIPULATION ERROR #281: COPYSUBRESOURCEREGION_INVALIDSOURCE ]

D3D11: WARNING: ID3D11DeviceContext::CSSetUnorderedAccessViews: Resource being set to CS UnorderedAccessView slot 1 is still bound on input! [ STATE_SETTING WARNING #2097355: DEVICE_CSSETUNORDEREDACCESSVIEWS_HAZARD ]
D3D11: WARNING: ID3D11DeviceContext::CSSetUnorderedAccessViews: Forcing CS shader resource slot 0 to NULL. [ STATE_SETTING WARNING #2097317: DEVICE_CSSETSHADERRESOURCES_HAZARD ]
The thread 'Win32 Thread' (0x838) has exited with code 0 (0x0).
D3D11: WARNING: ID3D11DeviceContext::CSSetShaderResources: Resource being set to CS shader resource slot 1 is still bound on output! Forcing to NULL. [ STATE_SETTING WARNING #2097317: DEVICE_CSSETSHADERRESOURCES_HAZARD ]

In den Speicherbereichen überlappt sich rein gar nichts. Wie zur Hölle soll man da speichereffizient programmieren, das kostet mich bis zu 24 MiB extra!

Verfasst: **19.09.2012, 07:06**

Darum hat mein Glare ja auch um die 600 MiB VRAM verbraucht. Ein Hoch auf unsere Helden beim Direct3D-Team!

Verfasst: **19.09.2012, 10:02**

VC++ 2012 hat noch nicht mal implizite Move-Konstruktoren. Und wenn Herb Sutter so locker sagt, das Fehlen von make_unique in C++11 sei ein "Oversight" gewesen, frage ich mich manchmal schon, wann C++ eigentlich brauchbar werden soll.

Verfasst: **19.09.2012, 12:41**

NVidia NSight mag ein nettes Tool sein, ist aber immer gerade dann nicht genau genug, wenn ich wirklich mal Details bräuchte. Und noch dazu zeigt es ein paar hundert Geister-DrawCalls an, die ich nie gemacht habe. Und wenn ich die anzeigen lassen will, crasht Visual Studio.

Diese Geister-DrawCalls sind übrigens als Einzige Shader-limitiert... alle anderen DrawCalls ersticken im Input Assembler an Millionen kleinen Voxel-Flocken. Was kann man da noch machen? Das ist evtl. eine Frage für einen eigenen Thread.

Verfasst: **19.09.2012, 13:00**

Ja, NSight hat mir bis jetzt auch genau kein Mal geholfen. Crashes ohne Ende und es zeigt nie das, was man braucht. Zu den Voxelflocken bräuchte man in der Tat mehr Details.

Verfasst: **19.09.2012, 13:22**

Es wird SO Zeit für Unified Addressing; ich muss mit einem riesen Rechenaufwand Morton Codes zusammensetzen und auf der anderen Seite wieder zerlegen, nur um dort eine 3D-Textur addressieren zu können.

Verfasst: **19.09.2012, 13:39**

CodingCat hat geschrieben:Ja, NSight hat mir bis jetzt auch genau kein Mal geholfen. Crashes ohne Ende und es zeigt nie das, was man braucht. Zu den Voxelflocken bräuchte man in der Tat mehr Details.

Mir hat NSight sehr wohl geholfen, vorausgesetzt, man hab mal eben zwei Rechner rumstehen (Direct3D Shader Debugging).

Verfasst: **19.09.2012, 13:46**

Fun Fact: Es funktioniert mit DX11 und mit CUDA, aber nicht für DX11 und CUDA zusammen. Für mich funktioniert es also überhaupt nicht mehr.

Verfasst: **19.09.2012, 14:28**

CodingCat hat geschrieben:Fun Fact: Es funktioniert mit DX11 und mit CUDA, aber nicht für DX11 und CUDA zusammen. Für mich funktioniert es also überhaupt nicht mehr.

:|

Für mich sieht es gerade fast so aus, als ob ich hier einen Direct3D-OpenGL-Interop probieren müsste. Grund: Bindless Textures. Das kann doch nur schief gehen.

Verfasst: **19.09.2012, 14:38**

Vier neue Goodgame Jobs innerhalb von 9 Minuten.

Verfasst: **19.09.2012, 14:56**

Artificial Mind hat geschrieben:Vier neue Goodgame Jobs innerhalb von 9 Minuten.

Fünf sogar. Habe soeben (ohne Rücksprache mit den anderen Mods, Sorry dafür) eine PN verschickt.

PN hat geschrieben:Hallo Goodgame Studios,

bitte fasse alle Mitarbeiter-Gesuche eines Monats in einem einzelnen Beitrag zusammen. Die bisherigen Massen-Postings belästigen die aktiven Nutzer des Forums und sind daher bitte in Zukunft zu unterlassen.

Mit freundlichen Grüßen

Thomas Schulze

Verfasst: **19.09.2012, 15:02**

Danke.

Verfasst: **19.09.2012, 19:24**

Bedenklich: Meine Shaders werden bei Besuch besonders wenig aufwändiger Kamerapositionen nochmal eine ganze Ecke schneller. Sieht etwas danach aus, als würde der Treiber auf die Entdeckung hin, dass es sich um eine Echtzeitanwendung handelt, nochmal eine Optimierungsstufe hochschalten. :o

Verfasst: **19.09.2012, 22:36**

Quaternions: ja - auch wenn das kein Grund zum Jammern ist ;)

Verfasst: **20.09.2012, 15:47**

Irgendein Template führt zu einem fürchterlichen Code Bloat in in einem meiner Sourcefiles, aber ich weiß nicht, welches Template das Problem ist und bei allen, die ich im Verdacht hatte, hat ein Durchzählen der Instantierungen (globale Variable als Counter und im Template eine static dummy Variable, die mit dem return Value einer Funktion initalisiert wird, welche den globalen Counter inkrementiert) nur seh überschauliche Zahlen gegeben, die nicht das Problem sein können.
Templight habe ich auch versucht, drüber laufen zu lassen, der scheint aber mit dem Projekt überhaupt nicht klar zu kommen, findet die Includes nicht, mag manche Syntax nicht, usw., mit den Samples habe ich ihn zum Laufen bekommen, mit meinem Code nicht.

Noch igendwer Ideen, wie ich mit möglichst wenig Aufwand raus finde, welches Template wie oft instantiiert wird?

Verfasst: **20.09.2012, 15:57**

Ein Blick in die Debug Database oder das Map-File? Ist nur geraten, aber ich denke, da könnten alle verwendeten Symbole auftauchen.

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread