Marcelo's WebLog

PIX and playback adapter selection

Marcelo Lopez Ruiz - MSFT — Mon, 07 Jan 2019 23:00:12 GMT

This is probably my favorite feature of the release, announced here: a drop down to select which GPU to playback on. So you can go with WARP, and more importantly, if you have something like a Surface Book with multiple GPUs for example, you can target the one you specifically want. Enjoy!

PIX support for raytracing shader tables

Marcelo Lopez Ruiz - MSFT — Mon, 30 Jul 2018 19:51:54 GMT

Damyan discusses the new PIX functionality over at PIX 1807.19 – Shader Table Viewer. Managing the various shaders requires care, and it's great to have the tool. The other very useful thing to look at is the acceleration structures, but those were already supported. Enjoy!

Interactive Editor for the DirectX Shader Compiler

Marcelo Lopez Ruiz - MSFT — Mon, 09 Apr 2018 15:00:26 GMT

If you've been following along, welcome back! Otherwise, I recommend catching up on Viewing Optimization Passes in the DirectX Shader Compiler Editor. In addition to tweaking the pipeline configuration, there is also an Interactive Editor button you can click that will do bring up the window like the following. On the left-hand side you have all the passes that were run, with a 'start' pass marking the initial state fed to the optimizer. On the right-hand side you have a disassembly of the selected pass. If the pass is marked with an asterisk on the left, you know there's a change present, and the right-hand view will show a diff of the before/after for that pass. This is a very convenient view to have if you're trying to figure out how the compiler ended up with the code you generated. You can also do one very cool thing, which is to make an edit to the assembly at any point in the optimization process, and the continue compilation from that point on. This allows you to try out changes at a higher level than final IR, and so you get the benefits of legalization, constant propagation, DCE, etc., if you make the change prior to that stage - or perhaps you want to intentionally bypass these and so make them later. Let's try something then. If you've followed along with the Ctr+N default, you can make a change in the last 'dce' pass (right before 'hlsl-dxilfinalize'). First, right-click on the 'Right' radio button. This is necessary for continuation (you can't assemble a diff, which is the default selection). Next, change this line:

  %mul = fmul fast float %9, 0x3FF99999A0000000

To this:

  %mul = fmul fast float %9, 1.0

And then click the Apply Changes button. This will bring up a new window like the following one. You can see that your change has been preserved all the way to the final DXIL emitted. If you want to try this out, click on the 'Copy Container' button, close the interactive editor windows, and then paste inside the XML Shader element, and add a 'Compiled="true"' attribute to the element itself. This causes the execution engine to base64-unencode a container instead of compiling from sources, and if you click View | Render you will see that the aspect ratio is now changed. Note: if you paste on a regular text editor, you'll see that you get the text form of the disassembly - there are some clipboard format shenanigans at play to get to the base64-encoded container. Enjoy!

Viewing Optimization Passes in the DirectX Shader Compiler Editor

Marcelo Lopez Ruiz - MSFT — Fri, 06 Apr 2018 15:00:39 GMT

A few days ago I showed how we can compile and disassemble a shader using the DirectX Shader Compiler Editor, then how to run that shader. Today I'm going to look at the optimizer instead. We're starting again from the stock program available via Ctrl+N, and then when we click on the Optimizer tab, this is what we get. On the left, we have a list of all the available passes in dxcompiler.dll. We get this via the IDxcOptimizer interface. On the right, we have a specific set of passes forming a pipeline of optimizations. We get these via the IDxcCompiler interface using the /Odump argument, which produces a list of the optimization configuration used. This also takes into account other arguments such as /Od or /O1. You can play with the passes by moving them up or down in the pipeline, adding new ones or removing existing ones, or even changing properties by right-clicking on them and selecting Properties. This is only enabled for very few passes at the moment, but we'll add more as we need them. Another handy thing to do is to right-click on the pipeline and select Copy All. This copies to the clipboard the pipeline configuration in the same format you would use with the IDxcOptimizer interface. When you click Run Passes, the output of the optimizer run is displayed. This may include the disassembly if you have any print-module passes. If you used the view-cfg pass to dump a GraphViz-formatted , note that you can right-click on the graph keyword in the output and select 'Show Graph'. This will bring up a new window with an SVG render of that graph if dot.exe can be found. You'll get a list of probed locations if that's not the case. The graph would be more interesting if I had some control flow of course. You can zoom in and out using the slider at the top. Next time we'll explore the Interactive Editor button on the Optimizer tab. Enjoy!

Rendering in the DirectX Shader Compiler Editor

Marcelo Lopez Ruiz - MSFT — Thu, 05 Apr 2018 15:00:14 GMT

Last time we looked at how to disassemble a shader in the DirectX Shader Compiler Editor. If you looked carefully at the code inserted when you use Ctrl+N to include a new document, you'll see that there's an #ifdef'd section near the bottom. This #ifdef'ed section contains a bit of XML written in the same format used for execution tests in the compiler. You can place the cursor on an XML element name and press F1 to get a quick reference. The idea behind this is that it describes a single Dispatch or Draw call with very fine-grained control, for example to check whether heaps laid out in specific ways are behaving properly. Note that the implemented area is extremely basic and there are many features of D3D12 that aren't supported; however, you may find this useful for prototyping. To run the operation, you can select the View | Render option. It's an excellent good idea to turn on the Output window to see the debug spew generated. The render runs with the validation layers enabled, so you will often find useful information there. Finally, you have the option of using shader model 5.0 and 5.1 as well, both for disassembly and for rendering. To change the shader model used for disassembly, update the hlsl-target value specified in the first line of the file. To change the shader model used for rendering, update the Target attribute on the Shader elements in the XML section. There is very little specific to the compiler here, other than the fact that it's very easy to try things out and so we use it when we want to look at a tiny bit of behavior in isolate - and so can you, including for cases when you're putting together a quick repro. Enjoy!

Intro to the DirectX Shader Compiler Editor

Marcelo Lopez Ruiz - MSFT — Wed, 04 Apr 2018 17:00:39 GMT

One of the goodies that you get when you build the GitHub DirectX Shader Compiler yourself is the DirectX Shader Compiler Editor, casually referred to by its executable name 'dndxc'. https://blogs.msdn.microsoft.com/marcelolr/2017/02/01/building-the-directx-compiler-sources/ In case you're wondering, that's "dot net dxc" - it started off as a way to show how to call into the compiler from a C# project. There is very little work going on besides user interface management - pretty much every interesting thing that happens is delegated to the dxcompiler.dll component. The basic UI is as follows: there's a code editor on the left-hand side, and options to operate on that code in the menu, and additional tools on the right-hand side. Probably the most basic thing to do is to compile a shader and look at its disassembly. To do this quickly, press Ctrl+N to start with a new shader template, and then Ctrl+F7 to compile it. You'll see the Disassembly tab come to the foreground with color-coded disassembly. If something goes wrong, you'll get error messages in the output instead. This is simply exercising the IDxcCompiler APIs to compile and disassembly a blob. Next time, we'll look around some more. Enjoy!

Using the GitHub dxcompiler.dll

Marcelo Lopez Ruiz - MSFT — Tue, 06 Mar 2018 18:30:30 GMT

The simplest way for shader authors to build their shaders is to install the Windows SDK. Along with all the other files that support Windows applications and games, you'll get a command-line tool to build shaders (dxc.exe) as well as the the .dlls that support the actual functionality. If you have Visual Studio installed, you can search your Start menu for something along the lines of 'Developer Command Prompt for VS 2017' and bring up a console program. Note that the name will vary a bit depending on what version of Visual Studio you may have installed. In any case, if you type where dxc on the command prompt, you'll get the path to dxc.exe as installed on your computer. For example, I have one such copy at C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86\dxc.exe. There is also a dxcompiler.dll next to that binary which provides most of the actual compiler functionality. You will also find another copy of dxcompiler in a directory such as C:\Program Files (x86)\Windows Kits\10\Redist\D3D\x86\dxcompiler.dll, next to a few other files. Importantly, you'll also see dxil.dll there - more on that in a bit. The DirectX Shader Compiler project over at https://github.com/Microsoft/DirectXShaderCompiler provides you the ability to build your own dxcompiler.dll compiler library. This allows you to build additional features, tooling, or fix issues that you care about or would like to see work differently. If there is a feature or a fix that we're building that interests you and you don't want to wait for a new Windows SDK to be released, you can grab binaries from GitHub or build them yourself. It is important to note that the GitHub project will build dxcompiler.dll but not dxil.dll. By default, the binaries built from GitHub are set up such that they will perform validation of generated shaders, but they won't sign them. Unsigned shaders are fine to use in experimental mode, but will fail on an end user's computer with a message such as the following (in this case, for a compute shader).

D3D12 ERROR: ID3D12Device::CreateComputeShader: Compute Shader is corrupt or in an unrecognized format. [ STATE_CREATION ERROR #322: CREATECOMPUTESHADER_INVALIDSHADERBYTECODE]

If you look at the warning when an unsigned shader is compiler, you'll see the following message.

warning: DXIL.dll not found.  Resulting DXIL will not be signed for use in release environments.

To fix this, simply make dxil.dll available during compilation. The compiler will defer validation to this component, which is essentially the same validation code as that available on GitHub, but publicly and properly versioned so hardware drivers have a well-known and deterministic set of verified invariants to rely on (and possibly a reference for historical issues). And that's why there's both a dxcompiler.dll and dxil.dll available for redistribution - you can substitute your own dxcompiler.dll if you want to make changes to the language or compilation process, but dxil.dll will make sure that the instructions are sound for the hardware driver. Of course, for features that are in development, you may compile a shader for which there is no matching dxil.dll that will accept it - and that's the point of experimental modes to begin with; it's at a subject-to-change point in time. Enjoy!

Last Month on DirectX Shader Compiler (2018-02-13)

Marcelo Lopez Ruiz - MSFT — Tue, 13 Feb 2018 18:25:32 GMT

In addition to the usual work on SPIR-V and conformance, here are a couple of good/interesting fixes:

Lei Zhang provided a flag for pre-expanding macros when token-pasting. This flag modifies the preprocessor behavior to match fxc's behavior and favors compatibility; the current default matches C++ behavior and favors header reuse across languages.
Jeff Noyle fixed the /Zss switch used to use a bytecode-and-binary based hash for symbols. The problem actually affected the /Zsb switch; /Zss was picked up as the default anyway.

More notably for those who want to keep abreast of the latest changes, you'll notice that Young has bumped the shader model version to 6.3, meaning we're largely done with 6.2 at this point and have begun to work on the feature set for 6.3. We have some ideas of our own, but if you have suggestions for what you'd like to see on the capability or language side of things, leave a comment here or file an issue on GitHub - we're listening. In the meantime, happy shading!

Last Week on DirectX Shader Compiler (2018-01-16)

Marcelo Lopez Ruiz - MSFT — Tue, 16 Jan 2018 18:56:31 GMT

A few things to note from last week.

The hardware support section was updated with Intel driver version numbers and links.
Ben has submitted a pull request for secure HLSL. This is mostly scaffolding for adding content to specify a suite to verify conformance at the language level, and aiming for a secure variant of the language. Very exciting to see this!
Bug fixes, SPIR-V work, improved tests and validation.

Enjoy!

Last Month on DirectX Shader Compiler (2018-01-09)

Marcelo Lopez Ruiz - MSFT — Tue, 09 Jan 2018 19:33:49 GMT

Well, not quite a month, but close enough. Happy New Year! The holiday season was mostly about fixing issues with the compiler, translations, and performance of generated code. Also, in case you missed it, we did the first release of binaries via GitHub with the v1.2.0-alpha release. This doesn't (yet) include SPIR-V support, but we're hoping to include that in a future release. Enjoy!