Two Weeks of DirectX Shader Compiler (2016-06-20)

  • Article

What's been going on recently? For one thing, lots of paying attention to the DXIL validation version. This is important because it sets the constraints that have been applied to a given compiled shader. Once we release a new dxil.dll version, this becomes less of a concern as we need not maintain compatibility with prior versions in the compiler, but in the meantime we're staying in sync with the latest Windows SDK-provided binaries on the project. This way we make sure we share our development experience with other contributors.

Now that syntax colorization is a thing, we're also making sure we address issues and requests for code editor uses.

Finally, the most interesting thing is probably the inclusion of a linking API. There is more work that needs to happen here, especially around debug information, formalizing some of the link information and augmenting for edit and continue scenarios, but the basic case is in place.

The outline for how to use the linker is as follows:

  • Compile one or more source files into blobs with IDxcCompiler::Compile() using the lib_* target.
  • Create a CLSID_DxcLinker object that implements IDxcLinker.
  • Make your source files known to this linker by calling RegisterLibrary once per blob and naming them.
  • Create a runnable shader by invoking Link on the linker, passing the names of the registered libraries you want involved in the linking process.

If you have code that is common across multiple shaders, you can save the parse, analysis and some amount of optimization time by building a library and then producing each shader through linking. This linking process produces DXIL, so there is no driver involvement; GPU drivers still see a fully compiled shader in the end.

LinkerTest.cpp has some examples of how to put all of this together. I'll be sharing more information on linking in upcoming posts, but if you've got any questions, this blog or twitter are good places to reach me.

Enjoy!