ZFX + Developia

dot hat geschrieben: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 4-8 Clock Cycles oder sowas); oder
3. Vertexfarben aus einer Textur laden, was in D3D11 über SV_VertexID trivial ist.

Von der Liste geht Nummer 1 in die richtige Richtung. Aber was meinst du mit Kompression? Eine Farbraumtransformation ist keine Kompression!

Du musst anstatt die Vertex-Farben durch \($\operatorname{h}$\) im Shader laufen zu lassen, diese Operation einfach auf die Vertex-Farben vor dem Rendering anwenden. Dann sind die Vertex-Farben im Shader im linearen Farbraum, und die Farben sind mit den anderen, beispielsweise aus sRGB-Texturen gezogenen Farben kompatibel. Einfach die Operation aus dem Shader in die Vorverarbeitung ziehen. Das gibt keinen zusätzlichen Speicheraufwand.

eXile hat geschrieben:Von der Liste geht Nummer 1 in die richtige Richtung.

eXile hat geschrieben:[...] Dann sind die Vertex-Farben im Shader im linearen Farbraum, und die Farben sind mit den anderen, beispielsweise aus sRGB-Texturen gezogenen Farben kompatibel.

Das sollten sie imo eigentlich nach allen drei Methoden sein!?

eXile hat geschrieben:Aber was meinst du mit Kompression? Eine Farbraumtransformation ist keine Kompression!

Mit "dekomprimieren" meinte ich, die Transformation von sRGB nach linear vornehmen. sRGB stellt doch Farben gewissermaßen verlustbehaftet komprimiert dar (mehr Bits in dunklere Bereiche), aber gut, inwiefern man da wirklich von einer "Kompression" im eigentlichen Sinne sprechen kann, hab ich mir jetzt nicht wirklich überlegt...

dot hat geschrieben:Mit "dekomprimieren" meinte ich, die Transformation von sRGB nach linear vornehmen. sRGB stellt doch Farben gewissermaßen verlustbehaftet komprimiert dar (mehr Bits in dunklere Bereiche), aber gut, inwiefern man da wirklich von einer "Kompression" im eigentliche Sinne sprechen kann, hab ich mir jetzt nicht wirklich überlegt...

In der Tat, ich sehe erst jetzt, dass ja schon wieder von 8 Bits gesprochen wird. Sorry! Mein Gehirn war durch den langen Beitrag vorhin noch immer im HDR/16-Bit-Modus! ;)

Bei 8 Bits kriegt man genau das, was du mit Kompression meinst: Quantisierungsartefakte. Man muss in solchen Fällen die Farbwerte nichtlinear quantisieren (eben genau mit \($\operatorname{h}$\)), weil ansonsten die relative Genauigkeit bei dunklen Farbwerten scheiße ist. Jawohl, für 8 Bit Farbtiefe würde ich eine Umwandlung im Vertex-Shader vorschlagen. :)

Also hopp, hopp, schnell mal \($\operatorname{h}$\) in den Vertex-Shader klatschen, Krishty. Code gibt's hier.

Hahahahaha!

Ich hab's gewusst! Ich hab's genau gewusst!

Kein Direct3D 11.1 für Windows 7.

Ich bin mir ja noch immer nicht sicher, ob es D3D 11.1 überhaupt für Windows 8 gibt und unter welchen obskuren Umständen das der Fall ist.

CodingCat hat geschrieben:Ich bin mir ja noch immer nicht sicher, ob es D3D 11.1 überhaupt für Windows 8 gibt und unter welchen obskuren Umständen das der Fall ist.

Na, wenn das nicht der Fall sein sollte, dann gibt's wohl überhaupt kein D3D 11.1, denn DX 11.1 gibt's ja offensichtlich nur für WIndows 8.

Die aktuelle MSDN ist so "aufgeräumt", dass jegliche Option, die automatische Übersetzung zu unterlassen, verschwunden ist. Brrrr.

eXile hat geschrieben:

dot hat geschrieben: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.

Darum geht es garnicht. Zuerst einmal ist es ein Aufwand, den einem die GPU an zig Stellen abnimmt; aber eben nicht an allen. Und dann fällt mir keine Rechtfertigung dafür ein. OH lass uns doch 32768 Byte Gruppenspeicher einführen, der mitsamt Caches für 256 Shader-Einheiten kohärent gehalten werden muss und atomare Operationen erlaubt! Und dutzende Videowiedergabe-Pixelformate schmeißen wir auch noch in die Texture Units! Warte – sRGB im Input Layout? Streich das; die Transistoren kann doch keiner bezahlen!!!!

Ich hasse Selbermachen; ich werde nur durch scheiß APIs immer wieder dazu gezwungen. Und hier sehe ich einfach keinen Grund, warum D3D mir das nicht abnehmen kann. Aber wenn AMD und Nvidia das anders sehen, werden die schon Gründe haben.

Ich habe 30 min den Bug gesucht, warum Dispatch() nix macht. Ganz banal: Kein Compute Shader gebunden. Warum warnt die D3D Debug Runtime da nicht?! Zum Kotzen.

Warum ist die menschliche Konzentration nur so begrenzt? Sobald es später wird, verschwimmt meine Sicht und auch so ist nicht mehr viel mit Coden.

Schrompf hat geschrieben:Die aktuelle MSDN ist so "aufgeräumt", dass jegliche Option, die automatische Übersetzung zu unterlassen, verschwunden ist. Brrrr.

Nein, ist sie nicht. Oben über der Seite ist jetzt so eine blaue Toolbar. Die kann man rechts an der Seite wegschicken ;)

Ewig nichts mit genauer Beleuchtung gemacht, darum komplett verwirrt.

Also; hier ist mein Terrain mit Ambient Occlision und Diffuse Lighting und mit gewöhnlichen Normalen: und hier ist dasselbe mit Bent Normals: WTF. Mache ich was komplett falsch oder ist der Unterschied immer so stark?!

Okay; habe den Fehler: Ich habe die Normalen nicht nach ihrer Wirkung gewichtet, sondern erstmal alle zusammengeschmissen und danach gemeinsam gewichtet. Da kann natürlich nur Schmuh rauskommen. Verbessert sieht es so aus: Ich denke, ich spamme den Thread einfach mal weiterhin zu. So kann ich Dampf ablassen, und falls ihr mal Vergleichsbilder für sowas braucht, wisst ihr, wo ihr sie herkriegt.

Auf einer stückweise einigermaßen ebenen Oberfläche sollten Bent Normals und Normalen übereinstimmen. Hängt aber sehr von der genauen Berechnungsweise und dem Verdeckungsradius ab. Wieso sind die Normalen eigentlich so gemustert? Liegt das am Noise?

Ja; der Noise ist atm extrem billig und sichtbar Quad-Tree-mäßig. Bin noch nicht zu meiner geliebten Fouriertransformation gekommen :(

error X3676: typed UAV loads are only allowed for single-component 32-bit element types

Woher kommt denn das? Texturen? Geht nicht RWStructuredBuffer?

Nun also endlich der Windows 8 IE vs. Chrome Text Rendering Vergleich. Mancherorts ist es nicht ganz so schlimm:

IE10 auf Windows 8: Chrome auf Windows 8: Mancherorts ist es extrem:

IE10 auf Windows 8: Chrome auf Windows 8: Fazit: IE10 liefert Windows-8-"Metro"-Matsch, Chrome weiterhin Clear Type.

Ja; ich brauche das leider als Textur.

Und bevor du Chrome lobst, will ich dich erinnern, dass das auch schonmal anders war.

Krishty hat geschrieben:Und bevor du Chrome lobst, will ich dich erinnern, dass das auch schonmal anders war.

Noch dehnt sich das Universum aber aus.

Ich darf nochmal schnell?

Wer hat sich diesen Dünnschiss von QtQuick3D einfallen lassen??
Was soll denn das bitteschön?
Und wie wird hier OpenGL initialisiert?
Welcher Version wird unterstützt? Etc..?
SINNLOS!!!!

Nicht genug, dass man sich irgendwie mit OGL vertraut machen muss... was ja sowieso schon ein Kapitel für sich ist.
Dann soll man sich noch damit vertraut machen, wie Qt dies handelt... :x

Was ist an der Klasse denn falsch? Sieht für mich nach ner banalen Wrapperklasse für eine CubeMap aus, nur halt im Qt-Stil.

Ja, eben.
Im Endeffekt kapselt sie nur 6 Texturen. Die man in unterschiedlichen Kontexe verwenden kann.
Aber mir fällt kein vernünftiger Grund dafür ein, auser eben sowas:
Oha.. ich verstehe.
Diese Klasse erstellt also eine TextureCube, die ja unter OGL nur EINE ID (Handle) bekommt.
Also direkt für eine OGL-Cube-Map.
Diese kann ich dann zB für EnvironmentMapping benutzen.
Okay, da habe ich etwas den Sinn dieser Klasse verkannt.

Okay – dass ich meinen über-Compute-Shader in kleine Happen aufteilen muss, damit das System nicht wegen Timeout alles abbricht, ist ja noch halbwegs nachvollziehbar.

Aber WarumTF muss ich die Häppchen dann alle mit einem Flush() beenden?! Ist die Runtime etwa zu blöd, das selber zu erkennen? Zumal da ein CopyResource() folgt, das zumindest teilweise sowieso einen Flush bewirkt …

Nachtrag: Selbst, wenn der Treiber nicht abschmiert, zeigt das System über Minuten keine Reaktion. Absolut katastrophal. Ich versuche mal, jedes GPU-Flush() mit einem Prozess-Sleep() zu verstärken.

Du musst Flush() aufrufen, sonst Timeout? Interessant, ich hatte ja das letzte halbe Jahr unzählige Timeouts, aber das habe ich noch nicht gesehen. Vermutlich, weil ich viel Standard-Graphik-Pipeline dazwischen hatte. Die Timeouts lassen sich übrigens konfigurieren: http://msdn.microsoft.com/en-us/windows ... 8.aspx#E3B

Und ja, endlose Wartezeiten bis der Treiber endlich zurückgesetzt wird hatte ich auf dem AMD-System auch zur Genüge. :-/

CodingCat hat geschrieben:Und ja, endlose Wartezeiten bis der Treiber endlich zurückgesetzt wird hatte ich auf dem AMD-System auch zur Genüge. :-/

Nein, das meine ich nicht – während die GPU am Rechnen ist, wird der Bildschirm nicht aktualisiert. Auch nicht nach Flush() u.Ä.. Alles friert ganz einfach ein, bis das nächste Present() kommt. Echt beunruhigend.

Dafür habe ich aber zum ersten Mal eine 8192²-Heightmap (also das durch Direct3D vorgegebene Limit) zu Gesicht bekommen. Eine der dunklen Stellen von den vorherigen Bildern sieht darin (300 Rays Ambient Occlusion) so aus:Das ist ein Detaillierungsgrad, mit dem man durchaus arbeiten kann.

Trotzdem beschleicht mich das Gefühl, dass das auf der CPU viel einfacher zu entwickeln und zu debuggen ist als auf der GPU. Wenn da nur nicht die rohe Kraft wäre …

Krishty hat geschrieben:Nein, das meine ich nicht – während die GPU am Rechnen ist, wird der Bildschirm nicht aktualisiert. Auch nicht nach Flush() u.Ä.. Alles friert ganz einfach ein, bis das nächste Present() kommt. Echt beunruhigend.

Der ganze Bildschirm? Wow, das habe ich bisher auch nicht bemerkt.

Krishty hat geschrieben:Trotzdem beschleicht mich das Gefühl, dass das auf der CPU viel einfacher zu entwickeln und zu debuggen ist als auf der GPU. Wenn da nur nicht die rohe Kraft wäre …

Einfacher ist es auf der CPU definitiv, GPU-Debugging ist eine Qual. Btw. warnt die Runtime auch nicht, wenn du Gruppen- oder Threadzahl-Limits überschreitest, sondern ignoriert das Dispatch() einfach. Oder war es DispatchIndirect()? Egal, du bist gewarnt. ;)

Nutzt du die Bent Normals eigentlich zur Detailreduzierung (Normal-Mipmapping)?

CodingCat hat geschrieben:Der ganze Bildschirm? Wow, das habe ich bisher auch nicht bemerkt.

AMD ftw m[

CodingCat hat geschrieben:Btw. warnt die Runtime auch nicht, wenn du Gruppen- oder Threadzahl-Limits überschreitest, sondern ignoriert das Dispatch() einfach. Oder war es DispatchIndirect()? Egal, du bist gewarnt. ;)

AUA. Danke …

CodingCat hat geschrieben:Nutzt du die Bent Normals eigentlich zur Detailreduzierung (Normal-Mipmapping)?

Nö; könnte ich aber, weil ich alle Terrain-Eigenschaften in Texturen schreibe.

Im Augenblick ist mein Gedankengang: Bei fast allen meiner Shader waren die Interpolatoren der Flaschenhals. Die Interpolatoren der Vertex-Shader sind dafür gemacht, beliebige Dreiecke zu interpolieren. Mein Terrain hat keine beliebigen Dreiecke, sondern nur Quads. Um Quad-Muster zu interpolieren, hat die GPU bereits dedizierte Hardware: Textursampler. Ohne also jemals was gemessen zu haben denke ich jetzt einfach mal, dass Texturen schneller sind als Vertexattribute.

Man bekommt jedoch ein Detailproblem: Man muss unbedingt anisotrop filtern, sonst sind die Details ziemlich schnell weg.

Irgendwie hasse ich das hantieren mit UAVs. Ein aktuelles Beispiel aus der Blogosphäre kann man hier sehen. Und ja, sowohl das if (++lockCount == 2) wie auch for (int i = 0; i < 16; i++) sind Hacks, die nicht existieren sollten. Die while (1)-Schleife führt auch auf meinem System zum Timeout.

Cat, was sagst du als UAV-Magier dazu?

eXile hat geschrieben:Irgendwie hasse ich das hantieren mit UAVs. Ein aktuelles Beispiel aus der Blogosphäre kann man hier sehen. Und ja, sowohl das if (++lockCount == 2) wie auch for (int i = 0; i < 16; i++) sind Hacks, die nicht existieren sollten. Die while (1)-Schleife führt auch auf meinem System zum Timeout.

Cat, was sagst du als UAV-Magier dazu?

Ich kam ohne derlei Hacks aus. Meine Spin Locks waren einfache do ... while-Schleifen, deren Bedingung nach erfolgreicher Aktualisierung (Lock-Akquisition, Update UND Unlock) zu false auswertete. Aber die Shader-Compiler sind bei Branching mit UAVs noch immer extrem unzuverlässig, ich musste teilweise mehrfach eine Art von Verzweigung gegen eine andere eintauschen, um funktionierende Resultate zu erhalten. Aktuell habe ich grausige Race-Condition-Artefakte, bis sich der Treiber endlich entschließt, die Shaders fertig zu optimieren, dann läuft alles wie es soll. Im Fall des Blogposts würde ich mal testen, einfach das !processed in die Schleifenbedingung zu setzen, breaks haben sich im Rahmen meiner Arbeit als eins der am wenigsten zuverlässigen "Features" erwiesen.