Direct3D feature levels discussion

Last edited:
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?
 
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.
 
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.
Click to expand...
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.
Click to expand...

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).
 
Last edited:
pjbliverpool said:
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?
Click to expand...
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 said:
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.
Click to expand...

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.
 
An interesting blog post that pours some cold water on Work Graphs

Recovery

Struggling
www.supergoodcode.com
The principle of charity requires taking serious claims in the best possible light. This should have yielded robust, powerful ExecuteIndirect benchmark usage (and even base compute/mesh shader usage) to provide competitive benchmarks against Work Graph functionality. At the time of writing, those benchmarks have yet to materialize, and the only test cases are closer to strawmen that can be held up for an easy victory.

I’m not saying that Work Graphs are inherently bad.

Yet.

At this point, however, I haven’t seen compelling evidence which validates the hype surrounding the tech. I haven’t seen great benchmarks and demos. Maybe it’s a combination of that and still-improving driver support. Maybe it’s as-yet available functionality awaiting future hardware. In any case, I haven’t seen a strong, fact-based technical argument which proves, beyond a doubt, that this is the future of graphics.

Before anyone else tries to jump on the Work Graph hype train, I think we owe it to ourselves to thoroughly interrogate this new paradigm and make sure it provides the value that everyone expects.
Click to expand...
 
raytracingfan said:
An interesting blog post that pours some cold water on Work Graphs
Click to expand...
That blog post glosses over one of the biggest wins in favour of Work Graphs which was the compute raster sample from AMD. (1.7ms w/ WG vs 2.9ms w/ EI)

Frankly, ExecuteIndirect has no good solutions for these irregular parallel workloads involving hierarchal data structures ...
 
Is this officially out of beta?

I will wait for Epics review of work graphs. I don’t think the above is wrong, but perhaps work graphs not so effective for simple use cases.
 
You must log in or register to reply here.
Back
Top