Endianness und Layout von GPU-Daten
Verfasst: 10.07.2015, 20:21
Moinzeit!
Ich scheitere mal wieder an der Verfütterung der richtigen Stichwörter an Google, deswegen habe ich jetzt die Hoffnung, dass jemand von Euch mir das sagen kann.
Wie genau interpretiert die GPU die Daten, die ich ihm hochladen? Also in welcher Endianess und in welcher Komponenten-Reihenfolge erwartet die GPU die Daten im Speicher?
Mein akutes Problem: ich habe Millionen von Daten in zwei Texturen zu je 4x uint16_t verpackt. uint16_t, weil ich noch auf DX9 bin, wo es ja per Design keine Integer-Operationen gibt und ein uint32_t demzufolge im Shader an Bits einbüßen würde. Im Shader entpacke ich die Daten wieder und zerlege sie nach Bedarf in 8- und 16Bit-Komponenten. Nur muss ich dazu halt genau wissen, in welche Bytes ich welche Bits verpacken muss, damit ich sie im Shader aus .xyzw rausziehen und zurecht-frac()-en kann.
Hat jemand eine Idee oder einen Link parat? Danke.
[edit]Integer-Texturen dürften als unsigned interpretiert und auf 0...1 normiert werden, wenn ich aus ihnen sample. Hab daher die Datentypen auf uint16_t korrigiert.
Ich scheitere mal wieder an der Verfütterung der richtigen Stichwörter an Google, deswegen habe ich jetzt die Hoffnung, dass jemand von Euch mir das sagen kann.
Wie genau interpretiert die GPU die Daten, die ich ihm hochladen? Also in welcher Endianess und in welcher Komponenten-Reihenfolge erwartet die GPU die Daten im Speicher?
Mein akutes Problem: ich habe Millionen von Daten in zwei Texturen zu je 4x uint16_t verpackt. uint16_t, weil ich noch auf DX9 bin, wo es ja per Design keine Integer-Operationen gibt und ein uint32_t demzufolge im Shader an Bits einbüßen würde. Im Shader entpacke ich die Daten wieder und zerlege sie nach Bedarf in 8- und 16Bit-Komponenten. Nur muss ich dazu halt genau wissen, in welche Bytes ich welche Bits verpacken muss, damit ich sie im Shader aus .xyzw rausziehen und zurecht-frac()-en kann.
Hat jemand eine Idee oder einen Link parat? Danke.
[edit]Integer-Texturen dürften als unsigned interpretiert und auf 0...1 normiert werden, wenn ich aus ihnen sample. Hab daher die Datentypen auf uint16_t korrigiert.