Why HIP and not for example Vulkan?

UPDATE:

Looks like this more about adapting existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose.

It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too.

As described by Brecht Van Lommel (Blender and Cycles developer):

Vulkan has limitations in how you can write kernels, in practice you can’t currently use pointers for example. But also, GPU vendors will recommend certain platforms for writing production renderers, provide support around that, and various renderers will use it. Choosing a different platform means you will hit more bugs and limitations, have slower or no access to certain features, are not likely to see library support like OSL, etc.

Our strategy for Cycles X is to rely on the GPU vendors to support us and provide APIs that meet our requirements. We want to support as many GPUs as possible, but not at any cost.

Why would anyone want pointers on the GPU?

Among other things: C++ on the GPU, with lots of common code between the two worlds.

It’s one of the core reasons why CUDA took off. You could adapt your code instead of a full rewrite, even mixing code within the same file. Types are checked at compile time too.

I'd take Rust over C++ for the GPU.

I don’t see why you’d want that, but if you want to do it you can.

nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.htm...)

I think this is more promising: https://github.com/EmbarkStudios/rust-gpu