Aktuell bin ich dabei, verschiedene Shader-Effekte wie z. B. Blur, Grayscale, Pixel-Lightning usw. zu entwickeln. Schwierig ist dabei eigentlich immer, Fehler in den Shadern zu finden. Was macht man als Anfänger? Man geht her, programmiert den Shader in Visual Studio, kompiliert diesen und bindet ihn in das Programm ein. Das Ergebnis ist dann meistens erst einmal nicht das, was man erwartet. Und dann? Tja, im Hlsl-Coding nach dem möglichen Fehler suchen, ausbessern, wieder kompilieren und dann wieder schauen. Und so geht das eine ganze Weile weiter.. dabei kann man diesen Ablauf in Visual Studio mittlerweile wesentlich produktiver gestalten.
In Visual Studio 2012 wurde PIX integriert. PIX wurde in der Vergangenheit mit dem DirectX SDK ausgeliefert und dient zur Analyse von Direct3D-Anwendungen. Man kann es sich als Art Profiler vorstellen. Ein gutes Feature ist z. B., alle Direct3D-Aufrufe innerhalb eines Frames aufzulisten, um damit etwa schauen zu können, ob die Engine so arbeitet, wie gedacht oder ob es Optimierungspotenziale gibt.
Innerhalb von Visual Studio kann PIX genau für das verwenden werden. Man kann das eigene Programm laufen lassen und per Knopfdruck einen Frame durch PIX analysieren lassen. Das Gute daran: In Visual Studio werden alle Direct3D-Aufrufe innerhalb dieses Frames, ein Screenshot und sogar alle Draw-Aufrufe, durch die ein beliebiger Pixel erzeugt wurde, aufgelistet. Das richtig geile ist aber – um wieder zum Thema weiter oben zu kommen – man kann damit die Shader debuggen.
Eine coole Sache (links ein Screenshot vom Debugger). Was man aber wissen muss: Das Debugging läuft nicht live auf der Grafikkarte, sondern wird von der Umgebung „simuliert“. Es werden im Prinzip die Parameter hergenommen, welche der Shader innerhalb dieses Frames hatte und damit wird der Shader durch den Debugger neu ausgeführt. Mir persönlich hat dieses Feature bis jetzt sehr geholfen. Vor allem, wenn ich prüfen möchte, ob die Übergabeparameter an den jeweiligen Shader auch passen.
Jetzt komme ich aber zu den Teil, der mir nicht so gut gefallen hat. Nicht zuletzt aufgrund der Tatsache, dass ich meine Programme komplett in C# entwickle, hatte ich zunächst Probleme, dieses Analysewerkzeug zu nutzen.
Ein erstes Problem bezieht sich auf Berechtigungen. Die Analyse eines Frames funktioniert nur, wenn Visual Studio mit Administrator-Berechtigungen läuft. Ob dem so ist oder nicht erfährt man durch den Hinweis „(Administrator)“ in der Titel-Leiste von Visual Studio. Bei mir war das grundsätzlich ein Problem, da ich zu testzwecken so gut wie immer UAC aktiviert habe.
Ein weiteres Problem heißt WPF. Die Analyse von Frames, welche in ein Direct3DImage von WPF gerendert werden, funktioniert grundsätzlich nicht. Zumindest habe ich dieses nicht zum hinbekommen. Ich vermute, dass kommt von der Tatsache, dass man selbst nur in eine Textur rendert, welche dann WPF in den eigenen Render-Prozess mit einbindet.
Weiterhin muss der Shader speziell zum Debuggen entsprechend Debug-Informationen haben. Diese Debug-Informationen können mit dem Compiler-Flag „/Zi“ im Shader-Compiler des Windows 8 SDK dem kompilierten Shader angehängt werden. Näheres dazu auf Msdn.
Ein weiteres Thema für C#-Anwendungen ist, dass in den Projekteinstellungen das Debuggen von nativen Code aktiviert sein muss. Wenn dieses Häkchen nicht aktiv ist, scheint sich PIX nicht an die Anwendung ran hängen zu können und man bekommt die relativ wenig aussagekräftige Fehlermeldung „Unable to start Experiment session“.
Sind die Abhängigkeiten erfüllt, so kann das Debuggen begonnen werden. Allerdings nicht mit dem normalen Debugger, sondern mit dem Grafik-Debugger. Zu finden ist der richtige Button über den Menü-Punkt Debug -> Graphics -> Start Diagnostics. Zu Beginn des Debuggens beschwert sich Visual Studio bei mir immer, dass es Probleme bei den Debug-Symbolen gibt. Auf das Debuggen danach hat das bei mir bis jetzt noch keine Auswirkungen gehabt, man kann den Dialog also bedenkenlos weg klicken.
Im Anschluss sollte man genau das machen können, was ich weiter oben schon geschrieben habe. Für jeden, der Direct3D-Anwendungen entwickelt, auf jeden Fall eine sehr nützliche Erweiterung von Visual Studio.
Hallo
ich bin nach stundenlanger Suche zur Problematik „HLSL Debugging“ auf deine Seite gestoßen und aus den Zwischensätzen lässt sich ja herauslesen das du einen Workaround hast um die Pixel Shader zu debuggen. (Korrigiere mich falls ich falsch liege!) Ich schreibe meine Desktopprogramme mit C# und WPF und habe versucht anhand deines Post vorzugehen. Ich habe das DirectX SDK, das Windows SDK usw. installiert. Ich schaffe es auch aus VS über den FX Compiler aus der .FX Datei eine .PS Datei zu bauen, diese einzubauen und dann auf mein WPF Element anzuwenden. Das Problem ist, dass ich es nicht schaffe den Pixel Shader Effekt zu debuggen. Vielleicht hast du ja eine Idee. Admin wird ausgeführt, das Flag ist gesetzt usw. Nur das Debugging funktioniert nicht. Du hast ja das Problem mit den Frames bei WPF angesprochen, wie lösst du das?
Gruß
Daniel
Hallo Daniel,
bei mir funktioniert das mit WPF leider auch nicht. Habe das Debuggen nur mit Windows.Forms machen können, und selbst dabei sind alle oben beschriebenen Hürden zu nehmen.
Getestet habe ich übrigens auf Windows 8 Pro 64-Bit. Als ich es vor ein paar Tagen nach dem Windows 8.1 Update ausprobieren wollte, ging es auch mit Windows.Forms nicht mehr. Ich vermute, dass ich hierfür noch das falsche Windows SDK habe, habe das Thema dann aber nicht mehr weiter verfolgt.
Gruß
Roland
Danke für die Info, dann wundert es mich nicht mehr wenn es einfach nicht funktionieren will! Ich habe auch so einiges jetzt versucht und es will nicht klappen. Schade eigentlich dass hier von MS nichts vernünftiges entwickelt wurde!
Gruß
Daniel