spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja, OpenGL Buffer Textures sind wohl das Äquivalent zum Direct3D tbuffer. Der Unterschied zwischen einem cbuffer und einem tbuffer liegt nicht einfach nur in der maximalen Größe, sondern vor allem darin, dass beide für verschiedene Zugriffsmuster ausgelegt sind. In den Prozessoren einer GPU laufen Gruppen von 32 (NVIDIA) bzw. 64 (ATI) Threads entsprechend dem SIMD Prinzip im Lockstep; d.h. alle 32 bzw. 64 Threads führen in jedem Takt die selbe Instruktion aus. (Ok, im Falle von ATI ist bzw. war es auch in jüngerer Vergangenheit nicht unbedingt immer ganz so einfach, aber gut genug für unsere Zwecke hier ) Aktuelle GPUs haben mittlerweile 1000+ Cores, auf einer solchen GPU werden also im Idealfall zu jedem Zeitpunkt über 1000 Threads parallel ausgeführt. Die Versorgung dieser 1000+ Cores mit Daten wird sehr schnell zum limitierenden Faktor. Daher verfügt eine solche GPU über verschiedenste Mechanismen, um gewisse Arten von Speicherzugriffen möglichst effizient zu gestalten. Am einen Ende des Spektrums haben wir da z.B. deinen StructuredBuffer, im Prinzip einfach nur ein herkömmliches Array auf das jeder Thread jederzeit an jeder beliebigen Stelle zugreifen kann (im Falle eines RWStructuredBuffer auch schreibend). Da muss dann tatsächlich jeder Zugriff aus jedem Thread zum Speicher gehen. Im Falle einer klassischen Shaderkonstante, wie z.B. einer WorldViewProjection Matrix, ist es nun aber so, dass alle Threads einer SIMD Einheit zu jedem Zeitpunkt immer nur auf die selbe Speicherstelle und immer nur lesend zugreifen werden. Daher verfügen GPUs über eine eigene Cache-Hierarchie, durch die solche parallele, lesende Zugriffe auf die selbe Speicherstelle effizienter bedient werden können. Ein anderes Beispiel sind Texturen: Auch dort wird immer nur gelesen und wenn auch nicht alle Threads immer auf exakt die selbe Speicherstelle zugreifen, so ist es in der Regel so, dass benachbarte Threads auch benachbarte Speicherstellen lesen und daher gibt es auch für Texturen eine eigene Cache-Hierarchie. Man muss natürlich erwähnen, dass öffentlich zugängliche Dokumentation zu diesen Dingen in der Regel sehr vage ist, sodass man ab einem gewissen Punkt natürlich nur noch im Nebel stochern und bestenfalls informierte Vermutungen anstellen kann. Aber die D3D Doku sagt uns, dass cbuffer für "constant-variable usage" gedacht sind, während tbuffer für "arbitrarily indexed data" schneller sein können. Die 64KB sind sicherlich kein Zufall, denn die entsprechen genau der Größe des Constant Memory auf den ersten Direct3D 10 Karten. Und die Bezeichnung "Texture Buffer" im Gegensatz zu "Constant Buffer" lässt vermuten, dass solche Buffer einfach statt durch den Constant Cache durch den Texture Cache der Hardware laufen, was auch konsistent mit den beschriebenen Unterschieden im Verhalten wäre.

Zusammenfassend kann man also wohl sagen: Nimm cbuffer für typische Shaderkonstanten, wo sämtliche Vertices/Pixel/etc. die selben Elemente verwenden, nimm tbuffer für Daten, wo verschiedene Vertices/Pixel/etc. auf verschiedene Elemente zugreifen, den Zugriffen aber immer noch eine gewisse Lokalität innewohnt, wie z.B. die Tabelle der Matrizen der Joints eines animierten Modells. StructuredBuffer sind erst mit D3D11 dazugekommen und decken den allgemeinen Fall von völlig wahlfreiem Zugriff ab.

Und während all diese Dinge auf den ersten D3D10 Karten von potentiell fundamentaler Bedeutung waren (konnte sich um Größenordnungen handeln), verfügen moderne GPUs mittlerweile aber sowieso auch über allgemeine Caches und etwaige Geschwindigkeitsunterschiede können heutzutage je nach Anwendung auch nur mehr klein bis kaum messbar ausfallen...

Hervorragende Erklärung, die dot da geschrieben hat! Kann ich jedem nur empfehlen, der irgendwas mit Shadern machen will.

Auch sehr informativ und interessant, danke dot

tbuffer sind vermutlich wohl eher einfache Buffer, die als normale Shader Ressource gesetzt werden.