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

It's unlikely to diverge from the same general flavor as vulkan. The worst parts of the DXIL to SPIR-V conversion I remember from that chain of blog posts is rebuilding structured control flow and how it interacts with atomics and wave convergence.

That's a problem that goes away irrespective of any DX extensions to SPIR-V for supporting the binding model DX uses.

> It would be great if you could find that Unity/Adobe discussion as I would be interested to read it.

https://github.com/gpuweb/gpuweb/wiki/Minutes-2019-09-24

Corentin: Web Shading Language — A high-level shading language made by Apple for WebGPU.

<room in general grimaces>

[...]

Jesse B (Unity): We care about HLSL

Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.

Jesse B: If we can transcode to HLSL to whatever you need, great. If we can’t, we may not support your platform at all.

Eric B: Would really not like even to write another transcoder. If there’s an existing tool to get to an intermediate representation, that’s good. Would suggest SPIRV is an EXCELLENT existing intermediate representation.

Note the WSL language made by Apple which sparked that discussion is unrelated to the WGSL language they ended up shipping, but the sentiment that the ISV representatives just wanted them to use HLSL or SPIR-V stands.

The choice was between using or adapting SPIR-V, which is what basically everyone doing multi-platform development wanted, or using anything else and pissing everyone off by making them support another shader language. Apple stonewalled using SPIR-V or any other Khronos IP on unspecified legal grounds so they effectively forced the decision to roll a new shader langage, post-hoc rationalizations were given (e.g. human readable formats being more in the spirit of the web despite WebAssembly already existing at that point) but the technical merits were irrelevant when one of the biggest stakeholders was never ever going to accept the alternative for non-technical reasons.

https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.

I don't understand why people say things that are kind of trivial to disprove, but here's the document with the notes where Apple refuses to use SPIR-V.

https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

> MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.

Reading between the lines, it seems like Apple mainly doesn't want to implement SPIR-V because engaging with the "Khronos IP framework" would prevent them from suing other Khronos members over patent disputes.

It's almost as like some Fruit based company is sabotaging the efforts to keep its walled garden.

Safari supports WebGL2 since version 15 - unless you meant something else by macOS lacking support?

(I agree with your general point though.)

> macOS doesn't support WebGL2

WebGL2 is fully supported in Safari since quite a while now. In fact it's using the same rendering backend as Chrome and Firefox (ANGLE), and AFAIK Google and Apple engineers worked together to create (or at least improve?) the ANGLE Metal backend and integrate ANGLE into Safari.

Long term shading languages will be a transition phase, and most GPUs will turn into general purpose compute devices, where we can write code like in the old days of software rendering, except it will be hardware accelerated anyway.

We already see this with rendering engines that are using CUDA instead, or as shown at Vulkanised sessions.

I do agree that to the extent C++ has grown, and the security issues, something else would be preferable, maybe NVidia has some luck with their Slang adoption proposal.

At some point you have to stop working in assembly and graduate to a high-level language and beyond.

Modern GPU stuff is getting too complex to be practical without higher language features.

yes, but you can use the same compiler, unlike with SPIR-V

Oh, I was under the impression that Direct X 12 was built-in for Windows like Metal is on Apple.

D3D is clearly more integrated into the OS than Vulkan is.

Most importantly, Windows includes a software D3D renderer (WARP) so apps can depend on it always being present (even if the performance isn’t spectacular). There are lots of situations where Vulkan isn’t present on Windows, for example a Remote Desktop/terminal server session, or machines with old/low-end video cards. These might not be important for AAA games, but for normal applications they are.

Another example: Windows doesn’t include the Vulkan loader (vulkan-1.dll), apps need to bundle/install that.

The downside is that it ties them incredibly heavily to Microsoft, and makes cross-platform efforts much harder.

I would guess that if DX didn't exist the iteration on VK side would just be faster. Through extensions, like you've mentioned.

In the end it might have even speed up the adoption of such features. Currently if you have a multiplatform engine, even though windows is like 99% of your PC player base it's still sometimes a tough decision to just use a feature that you can't support on all your targets.

LunarG released a native ARM version of the Vulkan SDK shortly after the Snapdragon X machines launched so presumably it works on those.

edit: yup https://vulkan.gpuinfo.org/listreports.php?devicename=Micros...

Vulkan is based on Mantle, which predates the release of DX12 by about 2 years.

DX12 is proprietary. Vulkan is not.

In this case Vulkan is the only option. DX12 is a non starter since it was never intended to be universally available.

DX12 was pushed as NIH, since it was made from Mantle same way as Vulkan was. So to reduce NIH, it only makes sense to unify it all in Vulkan.

They already made the first sensible step with SPIR-V here. The next step makes the same sense.

And stuff can be translated into Vulkan if it can't be rewritten.

I think saying that DX was first so it's Vulkan that was reinventing the wheel is incorrect with historical context.

AMD and DICE developed a prototype API called Mantle. Which is what both DX and Vulkan are based on.

Both Vulkan(glNext back then) and DX12 were announced around the same time. VK came a bit later as standards are usually slower in coming to decisions but it's not like VK was reinventing anything from DX.

I remember we were having a laugh reading early DX12 documentation as it was in parts just copied from Mantle with names unchanged in places!

I don't think that going into implementation details is what I would expect from an interface specification. The interface exists precisely to isolate the API consumer from the implementation details.

And while they're much better than nothing, those documents are certainly not a specification. They're are individual documents each covering a part of the API, with very spotty coverage (mostly focusing on new features) and unclear relationship to one another.

For example, the precise semantics of ResourceBarrier() are nowhere to be found. You can infer something from the extended barrier documentation, something is written in the function MSDN page (with vague references to concepts like "promoting" and "decaying"), something else is written in other random MSDN pages (which you only discover by browsing around, there are no specific links) but at the end of the day you're left to guess the actual assumptions you can make.

*EDIT* I don't mean to say that Vulkan or SPIR-V specification is perfect either. One still has a lot of doubts while reading them. But at least there is an attempt of writing a document that specifies the entire contract that exists between the API implementer and the API consumer. Missing points are in general considered bugs and sometimes fixed.

If you search for 'D3D12' spec what you actually find is D3D12 doesn't have a specification at all. D3D12's "spec" is only specified by a document that states the differences from D3D11. There's no complete holistic document that describes D3D12 entirely in terms of D3D12. You have to cross reference back and forth between the two documents and try and make sense of it.

Many of D3D12's newer features (Enhanced Barriers, which are largely a clone of Vulkan's pipeline barriers) are woefully under specified, with no real description of the precise semantics. Just finding if a function is safe to call in multiple threads simultaneously is quite difficult.