Jammer-Thread

[Krishty]

Wieder ein return zu viel in der Fensterprozedur. Diesmal: Ohne DefWndProc()-Aufruf haben Fenster zwar eine Titelzeile, aber keinen Titel darin.

[CodingCat]

Ich gebe immer an DefWndProc() weiter, es sei denn, ich habe einen guten Grund, es nicht zu tun (Weiterverarbeitung bewusst unterbinden). Wieso sollte ich plötzlich das Standardverhalten ändern, nur weil ich in irgendeiner Form auf eine Nachricht reagiere?

[Krishty]

If an application processes this message […]

und nicht

If an application processes this message and requires any default behaviour being disabled […]

Bedingung erfüllt, also return.

[CodingCat]

Ist doch egal was da steht, wenn es absolut keinen Sinn ergibt. Wenn ich Standardverhalten will, rufe ich Standardverhalten auf, so einfach ist das.

[Krishty]

Visual C++ hat selbst mit Warnlevel 4 nicht gewarnt.

    UnsignedInt4B const roundedUpTo16(
        UnsignedInt4B const value
    ) {
        return (value + 15u) & 0xFFFFFFFF0;
    }

[dot]

In der Tat, es braucht /Wall...

Code: Alles auswählen

#include <cstdint>

std::uint32_t const roundedUpTo16(uint32_t const value)
{
  return (value + 7u) & 0xFFFFFFFF0;
}

int main()
{

}

warning C4365: 'return' : conversion from '__int64' to 'const uint32_t', signed/unsigned mismatch

[Krishty]

Der D3D 11 Input Assembler kann kein sRGB?! War da nicht irgendwas von wegen alles vereinheitlichen; für HDR bereit sein und so?! Überhaupt ist die sRGB-Unterstützung immernoch lächerlich.

[dot]

Wieso sollte der Input Assembler sRGB verstehen!?

[Krishty]

Benutzt denn niemand mehr Vertex-Farben?

[Krishty]

D3D11::StructuredShaderConstantBuffer<VertexShaderTransformation>

Solche Monsterstrings sind die Strafe für meine Liebe zu aussagekräftigen Namen.

[Krishty]

D3D11: INFO: Create Buffer: Name="unnamed", Addr=0x006FCDFC, ExtRef=1, IntRef=0 [ STATE_CREATION INFO #2097228: CREATE_BUFFER ]
D3D11: INFO: Create RenderTargetView: Name="unnamed", Addr=0x00EC691C, ExtRef=1, IntRef=0 [ STATE_CREATION INFO #2097243: CREATE_RENDERTARGETVIEW ]
D3D11: INFO: Destroy RenderTargetView: Name="unnamed", Addr=0x00EC691C [ STATE_CREATION INFO #2097245: DESTROY_RENDERTARGETVIEW ]
D3D11: INFO: Destroy Buffer: Name="unnamed", Addr=0x006FCDFC [ STATE_CREATION INFO #2097230: DESTROY_BUFFER ]

Damit flutet die Direct3D 11 Debug Runtime das Ausgabefenster, sobald ich Antialiasing einschalte. Okay; ich kann die Infos ausschalten – aber trotzdem wüsste ich gern, woher der dringende Bedarf kommt, bei jedem Present() einen Puffer und ein RTV zu erzeugen.

Viel interessanter ist aber, dass sich dabei der Default Rasterizer State ändert! Ohne Antialiasing werden Rückseiten ignoriert; sobald ich Antialiasing einschalte, werden sie mitgezeichnet. Wtf?!

Nachtrag: Ohne Debug Runtime ebenfalls. Toll. Ich habe mich bisher immer auf den Default Rasterizer State verlassen, und bestimmt deshalb dauernd unbeabsichtigt Rückseiten mitgezeichnet.

[CodingCat]

Das klingt in der Tat sehr ungut. In welcher Form schaltest du denn Antialiasing ein? Macht der da am Ende ein Resolve() in einen temporären Puffer?

[Krishty]

In meiner Swap Chain setze ich SampleDesc auf { 8, 0 }. Bei { 4, 0 } und { 2, 0 } ist es dasselbe.

Wenn ich manuell einen Rasterizer State setze, der Rückseiten ignoriert, werden sie auch mit Antialiasing ignoriert. Aber der Default State zeichnet sie mit; es sei denn, ich setze { 1, 0 }.

Das mit Resolve() wäre möglich. Richtig die Hosen voll habe ich aber, wenn der das durch ein Full Screen Rect macht, dabei seinen eigenen Rasterizer State setzt, und nicht den Standard wiederherstellt. Direkt mal testen.

[CodingCat]

Kurios. Allerdings braucht man für Antialiasing ohnehin einen expliziten State um MultisampleEnable zu setzen, oder? Die MSDN sagt in der Tat, dass der Rasterizer ab Feature Level 10.1 immer antialiased rendert, MultisampleEnable wird angeblich ignoriert.

[Krishty]

Ja; ein Full Screen Rect ist es wohl. Fuck.

Irgendwo in Present() wird der Rasterizer State umgestellt; wahrscheinlich zum Auflösen des Antialiasings. Ihn manuell mit RSSetState(nullptr); zurücksetzen stellt das Standardverhalten auch wieder her.

Kurios. Allerdings braucht man für Antialiasing ohnehin einen expliziten State um MultisampleEnable zu setzen, oder?

Nö. Ich hatte ja schon vor drei Jahren beim Entwickeln meiner Sternendemo gemeckert, dass der Rasterizer State darauf keinen Einfluss hat und immer mit Antialiasing gezeichnet wird, falls das Ziel eine Textur ist, die mit Multisampling erzeugt wurde. Danke für den Hinweis; jetzt weiß ich auch, dass es wohldokumentiert ist und kann die States aus meinem Text löschen, die sich nur in diesem Flag unterscheiden. Ich benenne es bei mir direkt in Ignored um.

[CodingCat]

Wenn die da ernsthaft jedes Present() einen Resolve-Puffer erzeugen, würde ich das Resolve ohnehin eher selbst machen.

[Krishty]

Ja. In der Sternendemo hatte ich es sowieso so gemacht; auch, ohne das zu wissen. Jetzt wollte ich einfach mal was auf den Bildschirm kriegen. Aber einfach ist mit D3D nicht.

[CodingCat]

Ich verstehe allerdings nicht, wieso die da ein Rechteck rendern. Sollte das nicht ResolveSubresource() erledigen? Oder ist ResolveSubresource() derart mies implementiert, dass es den Rasterizer State immer verändert?

[Krishty]

Ich vermute, dass sie ein Rechteck rendern. Sagen wir es so: Die gesamte Operation sollte in einem halbwegs vernünftigen Compute Shader komplett ohne Rasterisierung möglich sein. Das einzige, was ich mir an Rasterisierung vorstellen könnte, wäre eben diese miese Implementierung als Full Screen Rect.

[eXile]

Der D3D 11 Input Assembler kann kein sRGB?! War da nicht irgendwas von wegen alles vereinheitlichen; für HDR bereit sein und so?! Überhaupt ist die sRGB-Unterstützung immernoch lächerlich.

Benutzt denn niemand mehr Vertex-Farben?

Entschuldige, dass ich für die Beantwortung deiner Frage wieder einmal etwas ausholen muss.

Wir hatten das Thema ja schon einmal an anderer Stelle angeschnitten, damals aber komplett ohne Texturen mit höherer Farbtiefe, sondern nur 8-Bit-Texturen in einer HDR-Pipeline (und natürlich Anti-Aliasing, was wir hier nicht behandeln).

1. Erst einmal ist klar: Wir wollen auch Farbwerte aus 8-Bit Texturen mit Farbwerten aus 16-Bit-Texturen vermischen. Zumindest bei 8-Bit-Texturen haben wir uns (und auch der Rest der Welt) auf sRGB geeinigt. Wie wir vielleicht noch wissen, besteht die Transformation von sRGB nach CIEXYZ aus einer Matrixmultiplikation (linearer Transformationsanteil) und einer nicht-linearen Transformation:

   Wie macht man die sRGB→CIEXYZ-Transformation? Wikipedia liefert:\($$\operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{CIEXYZ}}\begin{pmatrix}x_1 \\ x_2 \\ x_3\end{pmatrix} = \begin{pmatrix}0.4124&0.3576&0.1805\\0.2126&0.7152&0.0722\\0.0193&0.1192&0.9505\end{pmatrix}\begin{pmatrix}\operatorname{h}(x_1)\\ \operatorname{h}(x_2)\\ \operatorname{h}(x_3)\end{pmatrix}$$\)mit irgendeiner Hilfsfunktion\($$\operatorname{h}(x)=\begin{cases}\frac{x}{12.92}, & x\le0.04045\\\left(\frac{x+0.055}{1.055}\right)^{2.4}, & x>0.04045\end{cases}$$\)

2. Wie ich damals schon erzählt habe: Man kann sich die nichtlineare Transformation auch sparen.

   Aber zu diesen Zeitpunkt höre ich schon das Fluchen: Was soll der Mist, eine Matrixtransformation nur für so einen einzelnen popeligen Farbwert, nö keine Lust dadrauf, zu ineffizient, hau doch ab, etc. pp. Ja richtig, wir überlegen mal gerade: Wir brauchen nur eine Transformation in irgendeinen linearen Farbraum; warum gerade in den CIEXYZ ist vollkommen unklar. Und das stimmt auch: Wir können einfach die Matrix oben weglassen. Warum? Weil die Matrixmultiplikation einfach nur eine lineare Transformation ist; d.h. wenn wir mit \($\operatorname{h}$\) transformiert haben, sind wir bereits in irgendeinem linearen Farbraum (aber noch nicht in dem CIEXYZ-Farbraum).
   
   Also sagen wir einfach: \($$\operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{Linear}}\begin{pmatrix}x_1 \\ x_2 \\ x_3\end{pmatrix} = \begin{pmatrix}\operatorname{h}(x_1)\\ \operatorname{h}(x_2)\\ \operatorname{h}(x_3)\end{pmatrix}$$\) und fertig ist die Laube.

3. Wir spielen jetzt mal durch: Was würde passieren, wenn wir auch unsere 16-Bit-Texturen im sRGB-Farbraum vorhalten?
4. Das würde bedeuten: Wenn wir unsere 16-Bit-Texturen einfach auch im sRGB-Farbraum vorhalten, kriegen wir natürlich korrekte Ergebnisse heraus, selbst wenn wir die lineare Transformation (d.h. die Matrixmultiplikation) nicht durchführen: Wir landen wieder in irgendeinem linearen Farbraum (nicht CIEXYZ), was zum Herumrechnen bereits vollkommen ausreicht; genau wie bei Punkt (2) es schon angesprochen wurde.

Soweit die rein untechnische Sicht. Es funktioniert alles. So schön könnte die Welt sein.

Ich möchte noch einmal betonen, was das uns überhaupt bringt: Man kann damit größere Farbwerte aus dem CIEXYZ-Farbraum darstellen, und auch mit mehr Präzision (kleinere Diskretisierungsschritte). Aber: Wenn man die CIEXYZ-Werte nimmt, und sich mal die Chromatizitätswerte (d.h. x und y) anschaut, erkennt man, dass man immer noch nur die gleiche Farbmenge damit darstellen kann (nur mit mehr Präzision und größeren Y-Werten, d.h. „heller“.). Man kann auch sagen: Die Untermenge der damit darstellbaren Farben (Gamut genannt) ist gleich. Hier sieht man mal den sRGB-Gamut; der wird durch eine höhere Farbtiefe erst einmal nicht verändert.

Daher kann es sinnvoll sein, diese Gelegenheit zu nutzen, und ein paar Bits dafür einzusetzen, die Menge der durch den Farbraum darstellbaren Farben zu vergrößern: Wir wollen einen größeren Gamut.

Um den Gamut zu vergrößern es in der Literatur drei Möglichkeiten; alle haben gemein, dass sie eine andere nichtlineare Transformation \($\operatorname{h}$\) benutzen:

1. Extended range (xr): \($\operatorname{h_1}(x)=(x - 256) / 255$\) (von hier)
2. scRGB:\($\operatorname{h_2}(x)=(x - 4096) / 8192$\)
3. scRGB-nl:\($\operatorname{h_3}(x)=(\operatorname{h}(x) - 1024) / 1280$\)

Dadurch, dass in allen Fällen nur die nichtlineare Transformation geändert wurde, aber nicht die zugehörigen sRGB-Primärfarben (lineare Transformationsmatrix oben), kann man noch immer den gleichen Trick anwenden, nämlich dass man die Transformationsmatrix zum Berechnen einfach weglassen kann. Dies ist ein Vorteil von scRGB im Vergleich zu OpenEXR.

Dadurch, dass man aber die gleichen Primärfarben benutzt, sieht die Gamut, den scRGB hat, sehr ähnlich aus wie der von sRGB: Er ist nämlich einfach nur größer. Genauer: Um den Weißpunkt herum skaliert. Das sieht man auch hier. Das Problem daran ist nun, dass man dadurch ziemlich viele Farben, die man eh nicht sehen kann, verschwendet. Das ist nicht so schön.

Direkt in Direct3D integriert sind:

• DXGI_FORMAT_R8G8B8A8_UNORM_SRGB: 8 Bit Farbtiefe, benutzt \($\operatorname{h}$\).
• Achtung, ich merke gerade dass diese Präsentation wohl nicht ganz die Wahrheit sagt. Die folgenden Punkte können damit wohl sehr wahrscheinlich falsch sein!
• DXGI_FORMAT_R10G10B10A2_UNORM: 10 Bit Farbtiefe, („high precision“), benutzt \($\operatorname{h}$\).
• DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM: 10 Bit Farbtiefe, („extended range“), benutzt \($\operatorname{h_1}$\).
• DXGI_FORMAT_R16G16B16_A16: 16 Bit Farbtiefe, benutzt \($\operatorname{h_2}$\)

Ich vertraue der Präsentation nicht mehr. Kann das mal jemand testen? Einfach aus einer DXGI_FORMAT_R16G16B16_A16-Textur lesen, in der nur die Farbwerte 0.25, 0.5 und 0.75 als halfs drin stehen, mit einem Shader einfach Loaden und rausschreiben. Dann den Farbwert mit Bildschirmdruck und GIMP ermitteln. Warum habe ich nur das Gefühl, dass da 64, 128 und 192 rauskommen werden. :|

Irgendetwas mit \($\operatorname{h_3}(x)$\) gibt es nicht in Direct3D, zumindest so weit ich das sehe.

Nun endlich zu deinen Fragen:

1. Wenn DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM und DXGI_FORMAT_R16G16B16_A16 tatsächlich kein sRGB (mit unterschiedlichen Transformationsfunktionen) benutzen, wäre das ein Armutszeugnis.
2. Der Input-Assembler konvertiert wohl nichts, weil die sRGB-Konvertierung fest in die MMU für die Texturregister gebunden ist, und die werden für den Vertex-Input nicht verwendet. Funktioniert DXGI_FORMAT_R8G8B8A8_UNORM_SRGB tatsächlich nicht? Wenn nicht, dann wäre das nicht nur ein Armutszeugnis, sondern ein ganzer Grabstein.

Bevor ich mir noch einen Wolf weiter abschreibe, erst einmal hier reinstellen, bevor alles was ich gesagt habe gänzlicher Quark ist.

[Krishty]

wat

Also weil ich zu 99 % des Ganzen weniger Bezug erkenne als auf den Matratzen im Obdachlosenheim, antworte ich einfach schnell auf Frage 2 und ducke mich weg:
    D3D11: ERROR: ID3D11Device::CreateInputLayout: Element[1]'s format (R8G8B8A8_UNORM_SRGB) cannot be used with the Input Assembler. [ STATE_CREATION ERROR #153: CREATEINPUTLAYOUT_INCOMPATIBLEFORMAT ]

Und direkt hinterhergeschossen: Ist 32-Bit-Filterung in D3D11 immernoch optional? Meine Ambient Occlusion (DXGI_FORMAT_R32_FLOAT) ist völlig verpixelt …

Und zum Finale noch einmal neben den Strohhalm gesaugt: Ich habe vorhin 4096 KiB über eines meiner Arrays hinausgelesen und nichts Ungewöhnliches ist passiert. Wie tf ist das technisch möglich

[dot]

Und direkt hinterhergeschossen: Ist 32-Bit-Filterung in D3D11 immernoch optional? Meine Ambient Occlusion (DXGI_FORMAT_R32_FLOAT) ist völlig verpixelt …

Laut http://msdn.microsoft.com/en-us/library ... 71325.aspx ist das von D3D11 Hardware gefordert...

[Krishty]

Und direkt hinterhergeschossen: Ist 32-Bit-Filterung in D3D11 immernoch optional? Meine Ambient Occlusion (DXGI_FORMAT_R32_FLOAT) ist völlig verpixelt …

Laut http://msdn.microsoft.com/en-us/library ... 71325.aspx ist das von D3D11 Hardware gefordert...

Danke; ich war immer nur auf dem völlig nutzlosen http://msdn.microsoft.com/en-us/library ... p/ff476342 gelandet. Hm. Dann wird es wohl was anderes sein. Scheißegal; wandert eh in den Vertex Shader.

[eXile]

D3D11: ERROR: ID3D11Device::CreateInputLayout: Element[1]'s format (R8G8B8A8_UNORM_SRGB) cannot be used with the Input Assembler. [ STATE_CREATION ERROR #153: CREATEINPUTLAYOUT_INCOMPATIBLEFORMAT ]

Aww shit.

wat

Der Beitrag war hauptsächlich gemünzt auf

für HDR bereit sein und so?!

und sollte zeigen, dass für HDR-Formate durchaus sRGB und -Derivate (andere Transformationsfunktionen und scRGB) funktionieren. Oder kurz: Wenn wir mehr Farbtiefe haben, können wir Farben nicht nur genauer darstellen, sondern auch ganz andere Farben darstellen (erfordert dann aber 10-Bit-Monitore oder höher).

Selbst wenn du einen neuen 10-Bit-Monitor gekauft hättest, und einen 10-bittingen-Framebuffer hättest, kann es sein, dass du trotzdem keine anderen Farben als vorher bekommst. Du musst erst auf extended range oder scRGB umsatteln; mit sRGB bringt's nichts. Luxusprobleme viel? :)

Wenn diese Sachen in Direct3D implementiert wären. Was ich im Augenblick nicht nachprüfen kann.

[Krishty]

Aaaah okay – also mal wieder das Große Ganze :) Gutgut.

[dot]

Mir ist immer noch nicht klar, wieso der Input Assembler DXGI_FORMAT_R8G8B8A8_UNORM_SRGB akzeptieren sollte. Also ich versteh schon, wofür man es brauchen könnte, aber wie eXile ja auch schon angedeutet hat, steckt die sRGB Konvertierung in ganz anderer Hardware (ist afaik mehr oder weniger fix im im Texture Cache eingebaut) und ist daher für die IA Stage einfach physikalisch nicht verfügbar. Mir ist lieber wenn die Runtime mir einen entsprechenden Fehler liefert, als wenn sie es einfach akzeptieren und den _SRGB Part ignorieren würde. Wenn du es wegen Bandbreite und so unbedingt brauchst, kannst du es ja einfach im VertexShader selbst dekomprimieren...

[eXile]

Mir ist immer noch nicht klar, wieso der Input Assembler DXGI_FORMAT_R8G8B8A8_UNORM_SRGB akzeptieren sollte. Also ich versteh schon, wofür man es brauchen könnte, aber wie eXile ja auch schon angedeutet hat, steckt die sRGB Konvertierung in ganz anderer Hardware (ist afaik mehr oder weniger fix im im Texture Cache eingebaut) und ist daher für die IA Stage einfach physikalisch nicht verfügbar.

Das Hauptproblem ist, dass man im Code nun sowohl sRGB-Farben (für Texturen) als auch CIEXYZ-Farben (für Vertices) verwalten muss. Wenn man die Farbwerte für die Vertices also in einer Textur speichern würde, müsste die Textur CIEXYZ-Farben halten. Das ist alles nicht mehr homogen und bringt die Gefahr von Asset-Verwechslungen (beispielsweise wenn die Vertex-Farben aus einer sRGB-Textur ohne Umwandlungen gelesen werden, ist das Bullenscheiße).

[dot]

Das Hauptproblem ist, dass man im Code nun sowohl sRGB-Farben (für Texturen) als auch CIEXYZ-Farben (für Vertices) verwalten muss.

Wieso, ich kann die sRGB Inputs doch einfach im Shader selbst in einen linearen Farbraum transformieren!?

Wenn man die Farbwerte für die Vertices also in einer Textur speichern würde, müsste die Textur CIEXYZ-Farben halten.

Wieso!? Sobald ich was in einer Textur hab, kann doch einfach ein _SRGB Format verwenden!?

[eXile]

Wieso, ich kann die sRGB Inputs doch einfach im Shader selbst in einen linearen Farbraum transformieren!?

Richtig, aber das ist langsamer. Und du weißt ganz genau, wer die Frage ursprünglich gestellt hat.

Wenn man die Farbwerte für die Vertices also in einer Textur speichern würde, müsste die Textur CIEXYZ-Farben halten.

Wieso!? Sobald ich was in einer Textur hab, kann doch einfach ein _SRGB Format verwenden!?

Sorry, Missverständnis. Ersetze „Textur“ durch „Datei“ im Zitat. Sorry about that.

[dot]

Wieso, ich kann die sRGB Inputs doch einfach im Shader selbst in einen linearen Farbraum transformieren!?

Richtig, aber das ist langsamer. Und du weißt ganz genau, wer die Frage ursprünglich gestellt hat.

Naja, langsamer als was? Es gibt keine Alternative, der Input Assembler kann das halt einfach nicht. Ich seh folgendes Spektrum möglicher Tradeoffs:

1. Unkomprimierte Vertexfarben, braucht mehr Bandbreite, spart Laufzeit;
2. sRGB Vertexfarben im Shader selbst dekomprimieren, spart Bandbreite kostet etwas Laufzeit, wobei das nötige pow() wohl kaum Overhead erzeugen sollte (Latency in der Gegend von 8 Clock Cycles oder sowas); oder
3. Vertexfarben aus einer Textur laden, was in D3D11 über SV_VertexID trivial ist.

Ich würde vermuten, dass Variante 2) meistens am sinnvollsten ist...