If games use it, Nvidia will support it properly. While Vulkan hasn't "won" in the game space (and might not ever), SPIR-V actually already has support from Microsoft. The HLSL DXC compiler can natively output SPIR-V: https://github.com/Microsoft/DirectXShaderCompiler/wiki/SPIR...

So it's not implausible that there's a future world here where DX13 or DX14 use SPIR-V instead of DXIL. After all this makes AMD, Intel, and Nvidia's driver teams happier. Game devs also are happier as then they can ship a single precompiled shader on all platforms - PC & consoles. Microsoft's strong position with DirectX doesn't come from DXIL, but instead from making game developers happy, so SPIR-V's future could easily be very bright.

And then if games are using SPIR-V for compute (and they already use GPU compute for various things), then Nvidia is absolutely going to optimize the ever leaving snot out of it. Likely even more than they do for CUDA, as gaming is by far Nvidia's largest source of revenue: https://s22.q4cdn.com/364334381/files/doc_financials/quarter...

The work to make DXC generate SPIR-V was actually done by Google and Samsung, given the adoption resistance of game developers to downgrade their HLSL experience into GLSL.

Microsoft only open sourced the DXC compiler and approved their changes.

To see how much NVidia cares for SPIR-V, check the amount of Vulkan/OpenGL talks at GTC 2020 versus CUDA and related tooling.

Apparently OctaneRender decided to move away from their Vulkan prototype and just adopt Optix 7 instead.

No, precisely because I see the emerging alternatives as being based on Vulkan and SPIR-V, which I believe have momentum far greater than OpenCL. The only question is whether a compute platform based on these standards and open source tools could be anywhere nearly as good as CUDA. I believe we're far from that today, but it is possible and there's a lot of good work in that direction.

I'd really like to see the ecosystem move to Vulkan and SPIR-V as well. It's great to see that I'm not the only one! I think Vulkan has a lot of great moment behind it, especially since you can see some game shops porting fairly old games to it right now. Ubisoft's Rainbow 6 Siege is one example.

Kind of bums me out Apple decided to double down on Metal and not just go with Vulkan directly, but MoltenVK is probably fine to deal with that. I would have really like to see all other platforms effectively unite behind a DirectX alternative finally.

Regarding other platforms, Sony is still on LibGNM (and LibGNMX) and most Switch titles actually make use of NVN or middleware engines.

Note that openCL can compile to SPIR-V, so as long as Vulkan is used as the low level cross platform API we don't lose it

What about the work using SPIR—V as an intermediate representation for OpenCL? If anything, it seems like we’re moving towards a common foundation for GPU compute, with an expanding and diversifying array of higher level tooling.

What do you think of optimizers such as XLA, TVM or Glow that try to smooth out underlying hardware differences?

I don't follow this space closely (I believe XLA is related to MLIR, which I did mention), but strongly suspect that trying to run machine learning workloads portably is going to be one of the major drivers for building out tools and infrastructure for GPU compute.

Doesn't that exclude Apple?

That's a complex question, again the long answer is no. Both MoltenVK and the gfx-hal portability work (from Mozilla) allow you to run Vulkan workloads on Metal, thanks in large part to spirv-cross. I also see ~WebGL~ WebGPU on the horizon, and Apple is a very active participant in that process. Code written today to run on Vulkan, using any language that compiles to SPIR-V, will be pretty easy to adapt to the WebGPU future.

I think you meant to say "WebGPU" instead of "WebGL" here :)

Duh. Haven't had my coffee yet. Thanks.

Yes, though the MoltenVK project provides a Vulkan->Metal translation layer.

Well, what are the chances that less vendor lock in is in nVidia's interest?

Is it vendor lock-in if the clients want to be there? It's more like you can be in the club with the good music and hip people, or the club with the average unknown DJ and an empty dance floor.

That makes sense for GPU-compute-in-the-cloud applications where you can pick the hardware and don't care if other hardware doesn't work, but some people want to write programs that use GPGPU that can run on anyone's machine.