[HN Gopher] DirectX Adopting SPIR-V as the Interchange Format of...
       ___________________________________________________________________
        
       DirectX Adopting SPIR-V as the Interchange Format of the Future
        
       Author : AshleysBrain
       Score  : 100 points
       Date   : 2024-09-19 19:32 UTC (3 hours ago)
        
 (HTM) web link (devblogs.microsoft.com)
 (TXT) w3m dump (devblogs.microsoft.com)
        
       | pjmlp wrote:
       | No 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 wrote:
         | Will this help games be more compatible with the proton layer
         | on Linux or is this not related?
        
           | jsheard wrote:
           | In 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-t...
           | 
           | https://themaister.net/blog/2021/10/03/my-personal-hell-
           | of-t...
           | 
           | https://themaister.net/blog/2021/11/07/my-personal-hell-
           | of-t...
           | 
           | https://themaister.net/blog/2022/04/11/my-personal-hell-
           | of-t...
           | 
           | https://themaister.net/blog/2022/04/24/my-personal-hell-
           | of-t...
        
         | TillE wrote:
         | My understanding was that dxc lacked support for compiling
         | various HLSL features to SPIR-V (hence SM7 now), so there are
         | still a bunch of Vulkan-focused projects like Godot which only
         | support GLSL.
         | 
         | But yes, the games industry has been almost entirely HLSL since
         | forever, and this is going to help remove the final obstacles.
        
         | Simran-B wrote:
         | What about WGSL though, the shader language of WebGPU? WebGPU
         | is kind of Vulkan lite, but unlike with Vulkan, Apple is on
         | board and actually the reason why WGSL exists as yet another
         | shading language.
        
           | jsheard wrote:
           | What about it? Nobody wanted WGSL, it's just an artifact of
           | having to appease Apple during WebGPUs development as you
           | say. I don't see why it would be adopted for anything else.
           | 
           | The old WebGPU meeting notes have some choice quotes from
           | (IIRC) Unity and Adobe engineers literally begging the
           | committee not to invent a new shader language.
        
           | pjmlp wrote:
           | WebGPU, like WebGL, is a decade behind the native APIs it is
           | based on.
           | 
           | No one asked for a new Rust like shading language that they
           | have to rewrite their shaders on.
           | 
           | Also contrary to FOSS circles, most studios don't really care
           | about Web 3D, hence why streaming is such a thing for them.
           | 
           | There have been HLSL to SPIR-V compilers for several years
           | now, this is Microsoft own official compiler getting SPIR-V
           | backend as well.
        
         | camel-cdr wrote:
         | I haven't used either in a while, what is missing from GLSL?
        
           | pjmlp wrote:
           | C based, no support for modular programming, everything needs
           | to be a giant include, no one is adding features to it as
           | Khronos isn't assigned any budget to it.
           | 
           | HLSL has evolved to be C++ like, including lightweight
           | templates, mesh shaders and work graphs, has module support
           | via libraries, is continuously being improved on each DirectX
           | release.
        
       | tester756 wrote:
       | This is really good news!
        
       | bobajeff wrote:
       | Good. Now if Windows would adopt Vulkan as the graphics API of
       | the future.
        
         | nicebyte wrote:
         | vulkan 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.
        
           | bobajeff wrote:
           | That's not really the same as being supported by Windows. I
           | think that's 3rd party support and not built into the OS.
        
             | nicebyte wrote:
             | what do you mean when you say "built into the os"? d3d12 is
             | just an api. the d3d runtime is user-space, both the UMD
             | that wraps it and the KMD are supplied by the hardware
             | vendor. In the end, both a d3d app and a vulkan app end up
             | talking to the very same KMD. See here for reference:
             | 
             | https://learn.microsoft.com/en-us/windows-
             | hardware/drivers/d...
        
               | bobajeff wrote:
               | Oh, I was under the impression that Direct X 12 was
               | built-in for Windows like Metal is on Apple.
        
           | jimbob45 wrote:
           | _If you 're talking about replacing d3d12, that actually is a
           | terrible idea._
           | 
           | Why do you say that?
        
             | nicebyte wrote:
             | I 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...). 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.
        
           | jcotton42 wrote:
           | Does that support extend to ARM? Not sure if it's still the
           | case, but I recall that early Windows on ARM devices didn't
           | have native Vulkan (and I believe OpenGL was translated to
           | DirectX via ANGLE).
        
             | nicebyte wrote:
             | I haven't laid my hands on any ARM windows devices so I
             | wouldn't be able to tell you. I'd be somewhat surprised if
             | the newer snapdragon stuff doesn't have vulkan support
             | because qcom supports vulkan first-class on its gpus. in
             | fact, on newer android devices OpenGL support might already
             | be implemented on top of vulkan, but don't quote me on
             | that.
        
               | jsheard wrote:
               | 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?devi
               | cename=Micros...
        
         | mardifoufs wrote:
         | What's wrong with d3d12? It works perfectly fine for what it
         | does. In my experience it causes a lot less issues than Vulkan.
         | And it's not really due to windows not supporting Vulkan
         | correctly, since my experience with Vulkan has mostly been on
         | Linux.
         | 
         | I don't dislike Vulkan either, it's just that I don't see the
         | point of replacing something that works pretty well.
        
           | bobajeff wrote:
           | Adopting Vulkan doesn't mean removing Direct X 12. Just like
           | adopting spirv doesn't mean removing hlsl. No one said
           | anything about getting rid of anything.
        
             | Narishma wrote:
             | SPIR-V is not an alternative to HLSL. It's an intermediary
             | format that you compile HLSL (or GLSL) to.
        
           | shmerl wrote:
           | Reinvention of the wheel and tax on supporting "yet another
           | thing" for developers who need to deal with it.
           | 
           | Same reason standards have some value.
        
             | izacus wrote:
             | It's Vulkan that was reinventing the DX12 wheel wasn't it
             | though?
        
               | HideousKojima wrote:
               | Vulkan is based on Mantle, which predates the release of
               | DX12 by about 2 years.
        
         | shmerl wrote:
         | It should.
        
       | binary132 wrote:
       | Hopefully this isn't actually Third SPIR-V Dialect
        
       | omershapira wrote:
       | Cinematic crossovers have gone too far
        
       ___________________________________________________________________
       (page generated 2024-09-19 23:00 UTC)