Item — HN Reader

So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town.

I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possible to develop good tools that run on top of it. That's happening to a large extent in the machine learning space with IREE, much less so here though.

I should also say, I'm not disagreeing with the strategy Blender has chosen, specifically getting vendors to support tuned ports to their hardware. I'm just saying that these specific criticisms of Vulkan (like lacking pointers) aren't really valid.

1 comments

If I have learned anything from Khronos APIs is that if Internet was a Khronos standard instead of IETF, we would only have IP as standard, while everyone else had to come up with TCP, UDP, HTTP,... as extensions.

Language support and tooling are never better than the alternatives.

Blender decided to support just the platforms which have a C++ target device language.

This encompasses CUDA, Metal[1] (one of the reasons why it’s much more usable than Vulkan), ROCm HIP, and oneAPI[2].

[1] Metal’s Shading Language is C++14 with a handful of limitations, the biggest one is no lambdas

[2] Vulkan uses a restricted SPIR-V dialect without pointers notably. OpenCL and oneAPI use a separate one which _does_ support them. However, AMD[3] and NVIDIA do not implement SPIR-V in their OpenCL drivers.

[3] it’s a trainwreck, they supported the original SPIR but then https://community.amd.com/t5/opencl/spir-support-in-new-driv... happened. It never came back since then.

Migrating back down to GLSL/HLSL from that makes absolutely no sense. The options above, using C++ as a device language, allow much more code sharing with a CPU backend.

Portability is also a good story, the adaptation is mostly in the glue layer, if your GPU vendor is _not_ AMD and has a proper software stack.

Indeed, and a reason why Khronos only adopted SPIR-V and is now slowly embracing C++.

They took a hard beating from proprietary APIs that have long moved away from "C is the best" approach, and now they are playing catch-up with the rest of the world cozy in their mature C++ tooling for the GPGPU.

Note that Microsoft had C++ AMP on that front, https://docs.microsoft.com/en-us/cpp/parallel/amp/cpp-amp-ov.... That worked on DirectX devices as a whole.

However, MS failed to capitalise on it and bailed out (too early). Has been limping along dead since years, finally acknowledged as deprecated in VS2022.

I think that they rather decided to capitalize in HLSL, DirectX Compute, and mesh shaders instead, given the lack of love for C++AMP at ISO.