Share via

Last Month on DirectX Shader Compiler (2017-08-24)

  • Article

Oh me, oh my, how time flies - a month since the last update! Hopefully I'll get back to weekly updates. The lag isn't because things got quiet - on the contrary!

A ton of SPIR-V activity that had been waiting to get in is now current. Shout out to the Google folks who have done great work here, it's a pleasure to work with them. There's a new Wiki page with a whole bunch of information for those interested.

What's happened that's worth talking about? Lots of things!

  • Improvements in handling denorms. Sometimes you want consistent results one way or another, other times you just want whatever's faster. We got you covered.
  • More support for PIX functionality, including helping to test force early Z.
  • dxexp got more useful even when you're not in developer mode. Includes a JSON-formatted output, useful to get a quick report of adapter basics.
  • Support for true 16-bit float is starting to make its way into all the necessary places.
  • Improvements to the d3dcompiler bridge: implement D3DReadFileToBlob, add support for the built-in file-based include handler.
  • Many, many fixes, including some that affect execution tests that eventually get used to verify conformance.
  • Lots of changes here and there to improve handling of shader libraries. We haven't yet written a great sample of how best to leverage this yet(any takers out there?), but it's looking pretty good. You do have to use it in a sensible way and structure your code accordingly; many builds are structured around "big-bang" single compilation (understandably so), and you'll want to take a look at how to factor code to avoid recompiling code multiple times.

We've also been working on design notes for upcoming work that we'd like to post alongside code commits, to give people following the project an idea of what's coming.

Enjoy!

Comments

  • Anonymous
    September 21, 2017
    The denorm changelist description mentions that "undefined" could become the default option. Perhaps instead it would be better to default to the existing behaviour of DX10/11, where fp32 denorms are flushed to zero and fp16 denorms are preserved:https://msdn.microsoft.com/en-us/library/windows/desktop/cc308050(v=vs.85).aspx