ZFX + Developia

Alexander Kornrumpf hat geschrieben:

Krishty hat geschrieben:Natürlich können sie es schnell. Man muss ja sogar streuen, um verschiedene Bänke simultan zu treffen und so.

Das wage ich mal ganz stark zu bezweifeln, erstens weil es in ungefähr jedem Paper was ich bislang gelesen habe anders steht, und zweitens weil das Bankargument wenn ich mich recht erinnere einfach Blödsinn ist. Wenn ich mich jetzt nicht schwer täusche ist das Adressierungsschema im Shared Memory so, dass konsekutive Speicheradressen in verschieden Bänken liegen um genau das Problem zu vermeiden.

Okay – ich teste es, sobald ich den Compiler so weit habe, effiziente Zugriffe einzusetzen.

Alexander Kornrumpf hat geschrieben:Ich verstehe auch nicht was das "der Compiler lässt mich nicht" heißen soll. Jeder Thread soll "sein" Element lesen, verarbeiten und schreiben. Das ist binär. Entweder man macht es "richtig" oder eben nicht.

Es gibt mehrere Arten und Weisen, wie geschrieben werden kann – die sind von der Sichtbarkeit des Zugriffs und von seiner Größe abhängig, und darüber hinaus davon, ob er atomar geschehen soll oder nicht. Ich kann im Shader nur target[xy] = 0.0f; schreiben. Und der Compiler wählt automatisch die langsamstmögliche Methode aus. Mein Fehler scheint es nicht zu sein, sonst hätten mich MS und AMD längst drauf hingewiesen.

Alexander Kornrumpf hat geschrieben:

Dochdoch, die Daten sind toll, das Schreib-Layout ist optimiert. Der Grund ist, dass die Compiler einen Speicherpfad erzwingen, der normalerweise für Daten ungerader Größe vorgesehen ist, die global synchronisiert werden müssen. Aber was der Sinn dahinter ist, darüber schweigen mich alle nur an. Ich sage: menschliches Versagen.

CUDA unterstützt keine globale Synchronisierung. Es geht einfach nicht. Weil es langsam wäre. Wenn ATi/AMD das verbockt haben sollten dann erklär doch nicht deshalb GPGPU für gescheitert.

Entschuldige – ich meinte nicht „global synchronisiert“ sondern „global sichtbar“. Und verbockt hat es nicht nur AMD, sondern auch Microsoft. Und entweder hat Nvidia sein Mitspracherecht bei der DirectX- und OpenCL-Spezifikation dafür missbraucht, es größtmöglich scheitern zu lassen damit Cuda besser dasteht, oder hat auch Mitschuld an der Misere.

Krishty hat geschrieben:[...]

Da muss schon ein großer unterschied zwischen CUDA und deiner Technologie vorliegen. In CUDA ist es einfach so dass nichts lokal (Shared) sichtbar ist, bis __syncthreads aufgerufen wird und global nichts sichtbar ist, bis der Kernel beendet wurde. Daher bin ich immer noch der Meinung dass die Möglichkeiten für den Compiler was zu verbocken halt begrenzt sind. __syncthreads ist abgesehen davon sogar eine Hardware-Operation. Für die gibt es nur eine mögliche Übersetzung.

Ja, in Direct3D gibt es mehrere Feinabstufungen, mit denen man nicht nur die Threads synchronisieren kann, sondern wahlweise auch Zugriffe auf geteilten oder globalen Speicher. Oder nur die Speicherzugriffe ohne die Threads. Und eben auch, dass jede Änderung an globalem Speicher sofort für alle Thread-Gruppen sichtbar wird. Und all so Spirenzchen.

Hat man in Cuda die Möglichkeit, in 2D-Arrays zu schreiben und die als Direct3D-Texturen zu verwenden? Dann würde ich es auch mal ausprobieren. OpenCL fällt raus weil die Direct3D-Interoperabilität erfordert, dass alles über 1D-Puffer abgewickelt wird …

Nachtrag: Wie, Cuda ist immernoch Nvidia-only? Scheiße. Dann hat sich das erledigt. Und wenn die einzige funktionierende GPGPU-Api nur auf der Hälfte der GPUs läuft, dann ist GPGPU gescheitert.

Krishty hat geschrieben:Ja, in Direct3D gibt es mehrere Feinabstufungen, mit denen man nicht nur die Threads synchronisieren kann, sondern wahlweise auch Zugriffe auf geteilten oder globalen Speicher. Oder nur die Speicherzugriffe ohne die Threads. Und eben auch, dass jede Änderung an globalem Speicher sofort für alle Thread-Gruppen sichtbar wird. Und all so Spirenzchen.

Hat man in Cuda die Möglichkeit, in 2D-Arrays zu schreiben und die als Direct3D-Texturen zu verwenden? Dann würde ich es auch mal ausprobieren. OpenCL fällt raus weil die Direct3D-Interoperabilität erfordert, dass alles über 1D-Puffer abgewickelt wird …

Es gibt einige CUDA-D3D-Interop samples und Funktionen ( http://developer.download.nvidia.com/co ... D3D11.html ) sowie verschiedene Texture Funktionen ( http://developer.download.nvidia.com/co ... XTURE.html ). Das ist aber ein Teil von CUDA den ich nicht verwende weil ich nichts rendern will.

Re: Nachtrag. Willst du NVIDIA jetzt vorwerfen dass sie es einigermaßen zum Laufen gebracht haben (zumindest meiner Meinung nach)? Es würde den anderen Herstellern ja freistehen, etwas vergleichbares anzubieten.

Wollen wir die Diskussion in einen anderen Thread verlegen?

Nööö, ich bin so weit fertig.

Krishty hat geschrieben: OpenCL fällt raus weil die Direct3D-Interoperabilität erfordert, dass alles über 1D-Puffer abgewickelt wird …

Sag's wie es ist...D3D11->DGXI->D3D10->OpenCL, und dann hoffen, dass die OpenCL-Runtime einen Image-Support hat. Der vielleicht in Zukunft irgendwann auch mal __read_write qualifiers fuer ein und das gleiche Image zulaesst ;)

Bleibt zu hoffen, dass mit sich vergrösserndem Einsatzbereich von GPGPU auch dessen Kinderkrankheiten geben.

Ich habe wegen dieser Funktion vor Kurzem einen Bug gemeldet – sie wurde falsch geparst, wenn man auf ihr Ergebnis per [] zugegriffen (also [smpl][coord][chnl] geschrieben) hat. Jetzt zeigt sich: sie ist nicht nur falsch dokumentiert und wird falsch geparst, sondern ist schlicht und einfach nicht implementiert: D3D11 Internal Compiler Error: Invalid Bytecode: ld requires resource declared as texture1D/2D/3D/1DArray/2DArray. Opcode #7, operand #3 (counts are 1-based).

…

Achja: Die Connect-Seite für das DirectX-SDK ist nicht öffentlich einsehbar, einige Buttons funktionieren nicht, mit dem Abarbeiten sind sie jetzt schon sechs Monate im Verzug (obwohl die Seite erst vor kaum mehr als sechs Monaten eingerichtet wurde) und fast jede „Lösung“ ist „wir ziehen es für ein späteres Release in Betracht“. Das sagt dann auch alles über die Chance aus, dass das noch irgendwann behoben wird.

Mein Vorschlag: Wende dich mal (indirekt) an einen DirectX MVP. Davon geistern insbesondere im gamedev.net-Forum einige rum (z.B. Jason Z, der auch aktiv dort postet). Wenn du einen hinreichend provokanten, langen und fundierten Thread erzeugst (der auch direkt auf Direct3D verweist), sollte Dir seine Aufmerksamkeit dort gewiss sein ;)

eXile hat geschrieben:Wenn du einen hinreichend provokanten, langen und fundierten Thread erzeugst (der auch direkt auf Direct3D verweist), sollte Dir seine Aufmerksamkeit dort gewiss sein ;)

Ich habe auch schon eine riesige Wurst über die Lage von DirectCompute auf die Türschwelle des DirectX-Forums, wo das Team unterwegs ist, gekackt und angezündet. Die MVP-Antwort war, ich solle in oben genannter Connect-Seite posten. Habe ich getan. Ich stand auch schon in E-Mail-Kontakt wegen dem Versagen des Compilers mit AppVerifier und bin aktuell in der Mailingliste. Das Problem ist nicht, dass sie mich nicht bemerken, sondern, dass sie mich ignorieren.

Ich werde einfach weiterhin wöchentlich bumpen. In einem oder zwei Monaten haben sie vielleicht die Schnauze voll und kümmern sich drum.

Neben die Tüte gejammert: Man sollte nicht mit der D3D-Debug-Runtime benchen, da hat man 15 % weniger Leistung als mit der Release-Runtime. Und auf Nvidia-Karten kacke ich scheinbar noch übler ab als bei AMD.

Ich muss ehrlich sagen, dass ich "Jammer"-Threads nur aus deutschen Foren kenne. :D

The grumpy old programmer room existiert zum Beispiel auf TIGForums... Jammern ist eng mit Programmieren verbunden :D

Ich für meinen Teil bin hier schon vor langer Zeit zum Stänkern übergegangen.

WM_SIZE zu verarbeiten braucht geschlagene fünf Sekunden weil der Treiber so lange braucht um die Texturen zu allokieren. Danach weitere fünf Sekunden bei 1 fps bis alle Caches warm sind. Das sollte ein eindeutiges Zeichen sein, dass ich langsam über den VRAM hinausschieße. Ich könnte den Speicherbedarf theoretisch halbieren, aber hey, Compute Shader sind scheiße und dann läuft alles nur noch bei einem Viertel der Leistung.

Okay: Wenn ihr irgendwelche Puffer vergrößern oder verkleinern wollt, und das nicht in Echtzeit passieren muss – also z.B., wenn sich die Fenstergröße ändert – ruft ID3D11DeviceContext::Flush() auf, nachdem die alten Puffer freigegeben sind und bevor ihr die Neuen erstellt. Diese Synchronisierung spart euch viel Kummer:

Je nachdem, wie hoch der VRAM fragmentiert ist, kann es nämlich sonst Sekunden dauern, bis der Treiber Speicher für die neuen Texturen allokiert hat. Viel schlimmer ist aber, dass die GPU (weil asynchron) noch mit den alten Puffern rendert, während die neuen allokiert werden. Sind die Puffer nicht alle untereinander unabhängig, versucht die GPU parallel die Neuen zu füllen. Je nach VRAM-Auslastung verheddert sich der Treiber dann in Thrashing; die Framerate dümpelt völlig unabhängig der Leistungsansprüche bei <1 fps und das Abarbeiten der alten Puffer dauert noch länger. Manchmal kann sich der Treiber dann garnicht mehr fangen und die Framerate bleibt bei 100 % GPU-Auslastung auf <1 fps bis die Anwendung beendet wird (was dauert, weil auch die Latenz für Benutzereingaben steigt). Im schlimmsten Fall ist das System für eine Minute auf Autopilot unter Volllast bevor die Anwendung endlich geschlossen wird.

AMD-Karten scheinen da etwas anfälliger als Nvidia-Karten zu sein; zumindest sind letztere bei der Speicherallokation etwa 5× so schnell. (Basierend auf einer total repräsentativen Stichprobe von zwei ATI-Karten und einer Nvidia-Karte.)

Krishty was ist los? Ein ganz sachlicher Jammer-Beitrag ganz ohne Schimpfwörter und Gewaltfantasien im Analbereich? Bist du krank, haben dir die Moderatoren auf die Finger geklopft (im Hinblick auf Jugendschutzgesetze im Internet) oder gehen dir die Ideen aus? Aber ich sehe das durchaus als positive Entwicklung ;).

Liegt daran, dass …

• … ich bei Fehlern, die ich wahrscheinlich selber gemacht hätte (oder die ich sogar selber gemacht habe), keinen ungerichteten Hass empfinde
• … dies eines der wenigen Probleme war, die sich tatsächlich lösen ließen statt mich jeden Morgen mit der Klobürste in den Popo wachzuschrubben
• … ich von Tag zu Tag älter, verzweifelter und gefühlsstumpfer werde
• … dont wanna be no bad bad inflewence no moar

Ich hasse Shader Resource Slots

Ich hasse, dass das Setzen einer Shader Resource View scheitert, wenn bereits eine Unordered Access View der Ressource gebunden ist, aber umgekehrt das Setzen einer UAV nicht scheitert, wenn bereits eine SRV derselben Ressource gebunden ist, sondern die SRV dann genullt wird

Und ich hasse, dass die Debug-Runtime dann manchmal garnicht erst warnt

Aber das FX-Framework hasse ich noch mehr

Mir bleibt also nur Qual in meiner selbstauferlegten Askese

Man sollte Resource Views augenblicklich definieren können, wenn man eine Ressource an eine Pipeline-Stufe bindet … das würde zwei Drittel aller DirectX-Objekte sparen … und viel Frust

Wenn ich meine Shader vom GPU Shader Analyzer zu Intermediate Language kompilieren lasse und das Resultat im Stream Kernel Analyzer zu Maschinentext weiterkompiliere brauchen sie 20 % weniger Register und 4 % weniger Befehle als bei direkter Kompilierung

Mein Javascript Preloader für Assets braucht ohne Threads weniger Zeit als mit. :(

Das bezweifle ich – so lange du nicht „ohne zusätzliche Threads“ schreiben wolltest ;)

XFS just ate my kittys!

Auf einer meiner XFS Partitionen läuft ein Compile nicht mehr durch, weil das Filesystem sich weigert ein paar Objectfiles vom GCC ordnungsgemäß zu speichern. Keine sonstigen korrupten Daten oder auch nur eine Debugausgabe, einfach nur leere Objectfiles. So was kann ich ja leiden...

Naja, ich lade sehr viele Dateien und Threads sind 1. langsam zu initialisieren und 2. erzeugen sie einen hohen Speicherverbrauch. Die Aussage bezog sich auf den Betrieb unter Netbooks und anderen leistungsschwacheren Geräten. Das Laden und verarbeiten an sich geht flotter, allerdings habe ich am Anfang einen Delay, weil ich die ganzen Threads erzeugen muss. Wenn ich die Anzahl der Threads reduziere macht der Loader keine Probleme mehr. ;)

Und meine Aussage bezog sich darauf, dass jeder Prozess aus mindestens einem Thread besteht, du also schlecht „ohne“ ausgekommen sein kannst ;)

Bei parallelisiertem Laden von Daten sollte man auch immer bedenken, dass es einen Grund für die Ladedauer gibt: Die Lesegeschwindigkeit / Bandbreite / ... ist nunmal begrenzt, daran ändern auch mehrere Threads nichts. Sofern die Threads nicht auch noch andere Arbeit (Vorverarbeitung) verrichten, lädt damit dann einfach jeder Thread langsamer mehr Daten gleichzeitig. ;-)

Nein, 16-Bit-Präzision ist nicht ausreichend
Und langsamer noch dazu

Ich hab keine Lust an meinem Spiel weiterzumachen, weil ich sowieso wieder auf Probleme stoße, bei denen ich mit meinem eigenen verballerten Hirn nicht weiterkomme, sodass ich wieder hier auf der Seite einen oder einen anderen Thread zu ballern muss, um auf Leute wie Schrompf zu hoffen, die mir in ihrer unendlichen Hilfsbereitschaft die Sachen erklären, die eigentlich ein Vorschuldkind verstehen könnte, wäre es nur etwas eingearbeitet. Und den Master, den ich machen will, kann ich wohl nicht da machen, wo ich will und überhaupt sind meine ganzen Zukunftspläne trostlos und entsprechen nicht dem, was ich will, sodass ich auf die kommende Klausurphase nebst Bachelor-Arbeit-Schreiben sowas von unmotiviert bin, dass ich das bestimmt auch in den Sand setze.

Eisflamme hat geschrieben:Und den Master, den ich machen will, kann ich wohl nicht da machen, wo ich will und überhaupt sind meine ganzen Zukunftspläne trostlos und entsprechen nicht dem, was ich will, sodass ich auf die kommende Klausurphase nebst Bachelor-Arbeit-Schreiben sowas von unmotiviert bin, dass ich das bestimmt auch in den Sand setze.

Ich selber jammere nun rum, warum die Master-Vorlesungen bloß alle so dämlich sind. 90 Prozent des Stoffes wurden bereits zuvor durchgekaut, aber man muss ja alles noch einmal erzählen. Natürlich mit den exakt gleichen Foliensätzen von den gleichen Dozenten -- aber nun auch mit schlechtem Englisch! :?

Also statt interessanten, fortführenden Veranstaltungen einfach die gleiche Kacke wie zuvor iterieren.

Eine Abschlussarbeit in den Sand zu setzen (im Sinne von Durchfallen) ist übrigens sehr unwahrscheinlich ;)

Eisflamme hat geschrieben:Ich hab keine Lust an meinem Spiel weiterzumachen, weil ich sowieso wieder auf Probleme stoße, bei denen ich mit meinem eigenen verballerten Hirn nicht weiterkomme, sodass ich wieder hier auf der Seite einen oder einen anderen Thread zu ballern muss, um auf Leute wie Schrompf zu hoffen, die mir in ihrer unendlichen Hilfsbereitschaft die Sachen erklären, die eigentlich ein Vorschuldkind verstehen könnte, wäre es nur etwas eingearbeitet. Und den Master, den ich machen will, kann ich wohl nicht da machen, wo ich will und überhaupt sind meine ganzen Zukunftspläne trostlos und entsprechen nicht dem, was ich will, sodass ich auf die kommende Klausurphase nebst Bachelor-Arbeit-Schreiben sowas von unmotiviert bin, dass ich das bestimmt auch in den Sand setze.

Zumindest kannst du deine Misere artikulieren. 95 % der Leute, mit denen ich zu tun habe, können mir auf Nachfrage nicht sagen, warum sie sich scheiße fühlen.

Ich finds meist scheisse, weil ich die Gesamtsituation scheisse finde...
...scheisse :ugeek:
[Scheiss-Edit]
Ich finds scheisse, das ich diesen Monat so scheisse viel zu tun habe.
Und ich nicht an der ZFX-Scheisse mit scheiss Unity3D teilnehmen kann.
Mist!!!

Ich fasse den Thread mal netterweise zusammen