10 ms·
DirectX Adopting SPIR-V as the Interchange Format of the Future
- r1chardnl 2y ago[flagged]
- jsheard 2y agoStep 1: Microsoft has a proprietary alternative to an open standard, people complain. Step 2: Microsoft begins adopting the open standard, people complain.
- majorchord 2y agoI think they're referring to https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
- jsheard 2y agoI know that's what they're referring to. If you're concerned about Microsoft gaining undue influence over Vulkan/SPIR-V then rest assured they already effectively controlled the desktop graphics landscape, however they define DirectX becomes the template for hardware vendors to follow, and Vulkan then has to follow their lead. The pattern is especially obvious with big new features like raytracing, which was added to DirectX first and then some time later added to Vulkan with an API which almost exactly mirrors how DirectX abstracts it. There are even Vulkan extensions which exist specifically to make emulating DirectX semantics easier.
- chucke1992 2y agoThat's understandable. Control over standards has the immense value. Just like look at Nvidia's CUDA.
- pjmlp 2y agoCUDA success has much to thank Intel and AMD for never providing anything with OpenCL that could be a proper alternative in developer experience, graphical debugging, libraries and stable drivers. Even OpenCL 2.x C++ standard was largely ignored or badly supported by their toolchains.
- talldayo 2y agocough cough Remind me who owns the OpenCL trademark, again? Intel and AMD weren't the ones that abandoned it. Speaking in no uncertain terms, there was a sole stakeholder that can be held responsible for letting the project die and preventing the proliferation of Open GPGPU standards. A company that has everything to gain from killing Open standards in the cradle and replacing them with proprietary alternatives. Someone with a well-known grudge against Khronos who's willing to throw an oversized wrench into the plans as long as it hurts their opponents.
- google234123 2y agoWould you be willing to share the deal with Apple/Khronos relations?
- troupo 2y agoApple didn't like OpenGL, rightfully, and came up with their own Metal which they released two years before first version of Vulkan was released. Now people pretend that Apple is bad because it never adopted Vulkan and never implemented the "good modern OpenGL" (which never really existed).
- jsheard 2y agoIt runs deeper than that, during the development of WebGPU it came to light that Apple was vetoing the use of any Khronos IP whatsoever, due to a private legal dispute between them. That led to WebGPU having to re-invent the wheel with a brand new shader language because Apples lawyers wouldn't sign off on using GLSL or SPIR-V under any circumstances. The actual details of the dispute never came out, so we don't know if it has been resolved or not.
- plorkyeran 2y agoYes, obviously. It is an incredibly tiresome comment which is brought up every single time that Microsoft adopts any sort of open standard and it's never done with any particular insight into if this is one of the times that it'll be relevant.
- saurik 2y agoHas it ever not ended up being relevant? Like, I would agree that it is kind of redundant--and thereby maybe doesn't need to be said--but if there are people who actually think "maybe this time will be different", arguably the comment should be pinned to the top of the thread as a reminder?
- pjmlp 2y agoNo surprise here, given the extent HLSL is already the de facto shading language for Vulkan. Khronos already mentioned in a couple of conferences that there will be no further work improving GLSL, and given DirectX weight in the industry, HLSL kind of took over. Additionally for the NVidia fans, it might be that Slang also gets a place in the Vulkan ecosystem, discussions are ongoing, as revealed on SIGGRAPH sessions.
- gigatexal 2y agoWill this help games be more compatible with the proton layer on Linux or is this not related?
- jsheard 2y agoIn theory if DirectX games start passing shaders to the driver in SPIR-V, the same format Vulkan uses, then yes it should make Protons job easier. Translating the current DXIL format to SPIR-V is apparently non-trivial to say the least: https://themaister.net/blog/2021/09/05/my-personal-hell-of-translating-dxil-to-spir-v-part-1/ https://themaister.net/blog/2021/09/05/my-personal-hell-of-t... https://themaister.net/blog/2021/10/03/my-personal-hell-of-translating-dxil-to-spir-v-part-2/ https://themaister.net/blog/2021/10/03/my-personal-hell-of-t... https://themaister.net/blog/2021/11/07/my-personal-hell-of-translating-dxil-to-spir-v-part-3/ https://themaister.net/blog/2021/11/07/my-personal-hell-of-t... https://themaister.net/blog/2022/04/11/my-personal-hell-of-translating-dxil-to-spir-v-part-4/ https://themaister.net/blog/2022/04/11/my-personal-hell-of-t... https://themaister.net/blog/2022/04/24/my-personal-hell-of-translating-dxil-to-spir-v-part-5/ https://themaister.net/blog/2022/04/24/my-personal-hell-of-t...
- trelane 2y agoMaybe. Maybe not; it could well be an incompatible flavour of SPIR-V.
- MindSpunk 2y agoIt'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.
- tester756 2y agoThis is really good news!
- bobajeff 2y agoGood. Now if Windows would adopt Vulkan as the graphics API of the future.
- nicebyte 2y agovulkan is already supported on windows as a first-class citizen by all major IHVs. I am not sure what this "adoption" you speak would entail. If you're talking about replacing d3d12, that actually is a terrible idea.
- jimbob45 2y agoIf you're talking about replacing d3d12, that actually is a terrible idea. Why do you say that?
- nicebyte 2y agoI say this because vulkan is hamstrung by being an "open API" intended to run on a very wide range of devices including mobiles. this has major repercussions, like the awkward descriptor set binding model (whereas d3d12's descriptor heaps are both easier to deal with and map better to the actual hardware that d3d12 is intended to run on, see e.g. https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are-hard/ https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are...). overall d3d has the benefit of a narrower scope. Another problem with being an open API is that (and this is my own speculation) it's easier for IHVs to collaborate with just Microsoft to move faster and hammer out the APIs for upcoming novel features like work graphs for example, vs bringing it into the public working group and "showing their cards" so to speak. This is probably why vk gets all new shiny stuff like rtrt, mesh shaders etc. only after it has been in d3d for a while. One could argue this is all solvable by "just" adding a torrent of extensions to vulkan but it's really not clear to me what that path offers vs d3d.
- trelane 2y agoThe downside is that it ties them incredibly heavily to Microsoft, and makes cross-platform efforts much harder.
- binary132 2y agoHopefully this isn’t actually Third SPIR-V Dialect
- flohofwoe 2y agoI wouldn't expect being able to load a D3D12 SPIRV blob into Vulkan or OpenGL anyway though, just because the 'input semantics' are very different (and I think that's also the main difference between GL and Vulkan SPIRV blobs). But AFAIK SPIRV is extensible for this type of differences without rendering existing SPIRV tools completely useless.
- binary132 2y agoI think you’re kind of missing what I was getting at: today, tools which produce SPIR-V for OpenCL cannot be used to produce SPIR-V for Vulkan shaders, and vice versa. MLIR is a possible way out of the mess, but I am not hopeful that the future looks less messy, at least for some years, and it may not have enough incentive to even be feasible to improve.
- flohofwoe 2y agoAh right, I was thinking of the Vulkan vs GL SPIRV flavours. I don't think it's much of a problem though. I cannot run a WASM blob compiled for the web in a WASI runtime either, or an x86 executable compiled for Windows on Linux. Heck, I can't even run an executable compiled for one Linux distro on another Linux distro if the glibc library versions don't overlap.
- binary132 2y agoyes, but you can use the same compiler, unlike with SPIR-V
- flohofwoe 2y agoI guess the main reason is that entirely different people work on using GPUs for compute tasks versus using GPUs for rendering tasks (unless you're using the 3D API's compute features). E.g. not a technical problem, but organizational.
- omershapira 2y agoCinematic crossovers have gone too far
- riedel 2y agoI'd wish more Microsoft devblog content was like this one.
- flohofwoe 2y agoI could do without the shitty memes images.
- cbarrick 2y agoAside: I find it funny to see memes with attribution. Given the culture around memes, attribution feels somehow weird.