back

by raphlinus·4y ago·view on hn ↗
This doesn't sound right to me. Vulkan 1.2 has support for pointers through an extension[1], and that's getting more widely available (certainly a lot more cards than can run ROCm). There's also support coming down the pike for buffer device address[2], which basically lets you use pointers to refer to resources when submitting work to the GPU instead of having to create bindings.

If an open source project of this scope came to me for advice, I would absolutely 100% recommend they base their stuff on Vulkan. It's getting very good quite quickly; there's basically nothing holding you back any more if you're willing to use the latest extensions. There is a tendency in open source to move more slowly though, and I understand that.

I agree with you that GLSL/HLSL is a bad programming language, but you can still get your work done in it. I'm personally excited about rust-gpu, but that is not ready yet.

[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions...

[2]: https://community.arm.com/arm-community-blogs/b/graphics-gam...

1 comments
You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
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.

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.