Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Jammer-Thread

Beitrag von eXile »

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.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Jammer-Thread

Beitrag von dot »

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...
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Jammer-Thread

Beitrag von eXile »

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.
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Jammer-Thread

Beitrag von eXile »

Hahahahaha!

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

Kein Direct3D 11.1 für Windows 7.

Bild
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Jammer-Thread

Beitrag von kaiserludi »

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.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
Schrompf
Moderator
Beiträge: 4884
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

Die aktuelle MSDN ist so "aufgeräumt", dass jegliche Option, die automatische Übersetzung zu unterlassen, verschwunden ist. Brrrr.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
antisteo
Establishment
Beiträge: 854
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Jammer-Thread

Beitrag von antisteo »

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.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Andre
Establishment
Beiträge: 186
Registriert: 21.12.2011, 20:33

Re: Jammer-Thread

Beitrag von Andre »

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 ;)
Dateianhänge
msdn.PNG
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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:
12-11-13 normals normal.png
und hier ist dasselbe mit Bent Normals:
12-11-13 normals bent.png
WTF. Mache ich was komplett falsch oder ist der Unterschied immer so stark?!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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:
12-11-13 normals bent correctly.png
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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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?
Zuletzt geändert von CodingCat am 13.11.2012, 18:47, insgesamt 1-mal geändert.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Ja; der Noise ist atm extrem billig und sichtbar Quad-Tree-mäßig. Bin noch nicht zu meiner geliebten Fouriertransformation gekommen :(
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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

Bild
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

Woher kommt denn das? Texturen? Geht nicht RWStructuredBuffer?
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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

IE10 auf Windows 8:
iezgh.png
iezgh.png (3.65 KiB) 5169 mal betrachtet
Chrome auf Windows 8:
crzah.png
crzah.png (4.15 KiB) 5169 mal betrachtet
Mancherorts ist es extrem:

IE10 auf Windows 8:
iesgh.png
iesgh.png (3.1 KiB) 5169 mal betrachtet
Chrome auf Windows 8:
crsah.png
crsah.png (1.97 KiB) 5169 mal betrachtet
Fazit: IE10 liefert Windows-8-"Metro"-Matsch, Chrome weiterhin Clear Type.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Ja; ich brauche das leider als Textur.

Und bevor du Chrome lobst, will ich dich erinnern, dass das auch schonmal anders war.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
joggel

Re: Jammer-Thread

Beitrag von joggel »

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
nehmt Das!!
nehmt Das!!
Fuck_FaceBook.jpg (7.8 KiB) 5042 mal betrachtet
Benutzeravatar
Schrompf
Moderator
Beiträge: 4884
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
joggel

Re: Jammer-Thread

Beitrag von joggel »

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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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. :-/
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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:
(kontrastverstärkt)
(kontrastverstärkt)
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 …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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)?
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Jammer-Thread

Beitrag von eXile »

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?
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Antworten