Direct3D feature levels discussion

[MfA]

Why on earth would they decide that? uhhh

Would be hilarious if it's because of ARM.

 

[DmitryKo]

Microsoft released the first public build of the Dilithium semester in the Canary channel, but there is still no SDK/WDK and no plans to release it "for the time being" - so it seems APIs / headers for new features like shader model 6_9 with Mesh Shader Nodes (Work Graphs tier 1_1) won't stabilize until start of 2025, and will probably slip even further to Spring or even Summer (if Dilithium ever moves into the release branch)...

 

[DegustatoR]

DirectX Adopting SPIR-V as the Interchange Format of the Future - DirectX Developer Blog

Today the Direct3D and HLSL teams are excited to share some insight into the next big step for GPU programmability. Once Shader Model 7 is released, DirectX 12 will accept shaders compiled to SPIR-V™. The HLSL team is committed to open development processes and collaborating with The Khronos®...

devblogs.microsoft.com

 

[Remij]

^Big news that one!

 

[arandomguy]

With how that's phrased are they also saying that Shader Model 7 will be released under Direct X 12?

 

[pjbliverpool]

So does this mean that moving forwards we can expect PC's to be a little more console like in terms of the APIs ability to access lower level or unique features of a particular GPU's architecture?

 

[MfA]

Depends if they allow drivers to expose extensions, that would be pretty adventurous for Microsoft.

It's a shame workgraph enqueing isn't a pure shader operation, then they could just leave that to SPIR-V too.

 

[DmitryKo]

Interesting. Their previous roadmap was to refactor the open-source DirectX Compiler as a HLSL frontend and DXIL backend in the main branch of Clang/LLVM, instead of making yet another proprietary fork.

Though SPIR-V backend has been available for a while, the language of the announcement blog post suggests SPIR-V for DirectX 12 would replace DXIL bytecode with the release of shader model 7.0:

The Road to Replacing DXIL​

As we look to the future, maintaining a proprietary IR format (even one based on an open-source project) is counter to our commitments to open technologies, so Shader Model 7.0 will adopt SPIR-V as its interchange format. Over the next few years, we will be working to define a SPIR-V environment for Direct3D, and a set of SPIR-V extensions to support all of Direct3D’s current and future shader programming features through SPIR-V.

Appendix: A Brief History of GPU Interchange Formats

LLVM’s bitcode format had some significant drawbacks. Notably it is not version stable. New versions of LLVM support a lossy upgrading of older LLVM IR modules, but new LLVM cannot write IR modules that can be read by older versions of LLVM. Additionally, LLVM bitcode is a bit-packed file format which has two big drawbacks (1) it compresses poorly, and (2) it is hard to read or write from tools that aren’t LLVM.

To solve these problems The Khronos Group developed SPIR-V as a successor to SPIR. SPIR-V is ideologically aligned with LLVM’s IR, but it supports a stable and simple binary serialization. This makes SPIR-V easy to read and write by simpler tools than LLVM IR.

It looks like formally specifying DXIL as a proprietary fork of LLVM 3.7 bitcode proved impractical - so the open-source DXIL backend will only be maintained for backward compatibility with shader model 6.0-6.9, much like DXBC bytecode which was limited to shader model 5.1.

This may also explain why Wave MMA has been removed from DXIL bytecode. Though new DXIL frontend will still support shader model 6.8 and Work Graphs, shader model 6.9 will probably focus on minor updates like C++ language features in HLSL 202x/202y, and the development of major new features like Wave MMA and Graphics nodes will shift to shader model 7.0 and SPIR-V bytecode.

This transition to SPIR-V will surely take several years - or even more - to finalize. Microsoft hasn't even specified shader model 6.9 yet - which was supposed to be developed during the Dilithium semester (25H1), but the latter didn't achieve much and has already been replaced by Selenium (25H2).

 

[MfA]

I do truly wonder how many engineers they had to throw at ARM and how that is related.

 

[Andrew Lauritzen]

So does this mean that moving forwards we can expect PC's to be a little more console like in terms of the APIs ability to access lower level or unique features of a particular GPU's architecture?

Doesn't really affect any of that kind of thing. In the long run it mainly makes it easier to write portable GPU code across platforms and use a shared set of tools so there are ideally fewer platform-specific surprises on that front. Right now there's a lot of nonsense making sure shaders end up compiling well (or at all) for various platforms and dodging various toolchain bugs without messing up another toolchain.

It's great news for folks in the industry, and also for stuff like Linux gaming as when this happens (years from now it sounds like) more of the toolchain can be similar. It also further opens to the door for stuff like Windows Subsystem for Linux functionality, which I imagine is a part of their considerations too.

 

[raytracingfan]

With how that's phrased are they also saying that Shader Model 7 will be released under Direct X 12?

That aspect is definitely interesting. If a change this big doesn't make Microsoft declare DirectX 13, then there might never be a DirectX 13.

 

[trinibwoy]

That aspect is definitely interesting. If a change this big doesn't make Microsoft declare DirectX 13, then there might never be a DirectX 13.

It’s a big change but completely meaningless to end users. It’s not something Microsoft could market as the next big thing. Work graphs would be a good inflection point for the next DirectX but the industry is still slowly digesting mesh shaders and raytracing.