spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hm das ist sehr komisch. Stimmen deine Texturkoordinaten sicher? Wie füllst du die Textur jetzt?

Dein RowPitch ist 0, was du siehst ist also vollkommen korrekt

Zitat

// hier weiß ich noch nicht wie ich ermitteln kann, wie viel Bytes ich für einen individuellen Shader brauche

D3D11_SHADER_BUFFER_DESC :ize via ID3D11ShaderReflectionConstantBuffer::GetDesc



Packing Rules for Constant Variables


So sollte das funktionieren:

Hoffentlich ist das jetzt nicht zu großer Mist:
Durch die SIMD-Architektur (add , mad , dp4 , usw.) werden Instruktionen immer auf 4 Fließkommazahlen gleichzeitig angewendet. D.h. es sollten diese auch immer auf einmal aus dem Speicher geholt werden. Daraus ergibt sich die Ausrichtung des Speichers an Vielfachen der Größe eines aus 4 Fielßkommazahlen bestehenden Registers. Pro Takt kann im Idealfall (warmer Cache) eines ausgelesen werden. Würden Daten (z.B. ein Vektor) jetzt über mehrere Register verteilt, wären mehrere Take zum Auslesen und Zusammensetzen über die Registergrenze hinweg nötig. Da das wiederum in einer auf unbedingte Leistung ausgelegten Architektur eher suboptimal wäre, wird versucht das zu vermeiden.
C++ Compiler (und vermutlich auch die aller anderen Sprachen) machen das auch, da die x86-Architektur auf 4 Bytes ausgerichtet ist. Allerdings transparent und per Option ausschaltbar (z.B. #pragma pack(1) struct { char a; int b; } wird zu "abbbb" (pro Buchstabe ein Byte des entsprechenden Feldes), mit pack(4) zu "a...bbbb"). Solange man alles einheitlich kompiliert stellt das kein Problem dar, aber hinsichtlich der Performance (aber auf Kosten des Speichers) ist es wie schon gesagt weniger optimal. Beim schreiben von Strukturen im Binärformat in Dateien ist es hingegen eine ziemlich gemeine Stolperfalle, wenn z.B. der eine die gesamte Struktur auf 4 Bytes ausgerichtet auf einmal schreibt (fwrite(handle, sizeof(MyStruct, 1), src), der andere anschließend jedes Feld einzeln per fread(handle, sizeof(myField), 1, dst) ausliest oder mit einer anderen Ausrichtung die gesamte Struktur ausliest, usw.
Das gleiche Problem besteht genauso beim Übergang zwischen C++ und der Grafikarchitektur. Der C++-Compiler kennt die Ausrichtung der Zielarchitektur nicht, weshalb das von Hand zu machen ("pad[3]") oder auf Hilfsmittel wie D3DReflect zurückzugreifen ist, um mehr über die Struktur des Buffers zu erfahren (der Quelltext des Effects11-Frameworks liegt dem SDK bei, um einmal genau zu sehen, wie man das optimal löst). Das ist Mist, aber notwendig.
Ob und wie man genau diese Ausrichtung dem C++-Compiler irgendwie beibringen könnte, weiß ich nicht.

Ist dieses pad[3] wirklich notwendig, ich bezweifle das nämlich? Ein int hat 4 Byte, der struct wäre also auch ohne manuelles padding auf 4 Byte gepackt. Desweiteren sind moderne GPUs schon lange keine float4 SIMD Architekturen mehr (GeForce 7 war da z.B. die letzte bei NVIDIA, ATI hat das noch etwas länger betrieben afaik).

EDIT: Ok, es scheint wohl tatsächlich notwendig zu sein: http://msdn.microsoft.com/en-us/library/bb509632.aspx

Mit den tatsächlichen Architekturen selbst, könnte ich inzwischen falsch liegen. Das nVidia seit der 8000er-Serie eine Skalararchitektur verwendet, weiß ich. Bei ATI/AMD habe ich noch irgendetwas mit 5D-Registern im Kopf, weshalb die auf 160*5=800, 320*5=1600, usw. Streamprocessoren kommen. Das scheint bei denen heute noch so zu sein. (Gibt auch des öfteren Streit in Foren unter Fanboys, ob nVidia jetzt mit 240 Streamprozessoren (GTX280) an die 800 (4870er) von AMD rankommt.)

Zitat

HLSL packing rules are similar to performing a #pragma pack 4 with Visual Studio, which packs data into 4-byte boundaries. Additionally, HLSL packs data so that it does not cross a 16-byte boundary. Variables are packed into a given four-component vector until the variable will straddle a 4-vector boundary; the next variables will be bounced to the next four-component vector.

Ich verstehe das so, dass zumindest die Spezifikation von HLSL noch immer einen SIMD-Ansatz verfolgt. Variablen innerhalb eines Registers können einfach per Squizzle-Operator in die richtige Ordnung gebracht werden, registerübergreifend jedoch nicht.
Außerdem kommt es hier eigentlich nicht darauf an, wie die Architektur aufgebaut ist, sondern was spezifiziert ist, oder? Der Grafik-Treiber kann mit dem HLSL-Bytecode damit anstellen, was er will, solange dabei das erwartete Ergebnis rauskommt. Direct3D11 unterstützt noch Direct3D9-Level Hardware, was Kompatibilität von HLSL zu SIMD-Hardware wie GeForce7 und abwärts erfordert (als compile-target z.B.: ps_4_0_level_9_3).

[EDIT] Habe nach dem Essen das edit noch nicht gesehen.