Potentially support KernelAbstractions and GPUArrays

[VarLad]

Hey!
Is there a possibility that Vulkan.jl + SPIRV.jl can support GPUArrays and KernelAbstractions?
Even better if we can do that without using PhysicalBufferAddress :)

[serenity4]

I'm pretty sure this is possible (don't know about not using PhysicalBufferAddress though), even if there might be more limitations than compute kernels as to what operations are allowed (e.g., the OpenCL SPIR-V subset has fewer restrictions than the Vulkan subset).

I haven't tried it myself because I use Vulkan for graphics only, but if anyone wants to use it more as a cross-platform compute solution, I'd be happy to provide guidance on how to proceed. That'd however require extensive knowledge of Vulkan to implement, as one would have to build a whole compute renderer with proper abstractions.

Vulkan.jl + SPIRV.jl should just work (besides bugs that I'd be glad to fix) as the foundation to implement this renderer.

[VarLad]

Thanks! I'll try finding a way to do it without PhysicalBufferAddress. This is because a subset of Vulkan SPIRV can be compiled to multiple other shader languages as well, which is my target.

As for with PhysicalBufferAddesss, we already have a Vulkan backend over in OpenCL.jl using LLVM for OpenCL and then Zink driver to translate it to Vulkan API + SPIRV.
It can be run using, using OpenCL, Rusticl_jll. Only runs on Linux for now, we're figuring out the Windows and potentially MacOS jll binaries in the meanwhile :)

[serenity4]

As for with PhysicalBufferAddesss, we already have a Vulkan backend over in OpenCL.jl using LLVM for OpenCL and then Zink driver to translate it to Vulkan API + SPIRV.

I am not very familiar with the Mesa toolchain, but IIUC this is essentially a way to use OpenCL on top of a Gallium driver which internally uses Vulkan as an implementation detail, is that correct? So, in the end, you really just do OpenCL at the application level, and it just happens to use Vulkan underneath as part of the OpenCL "driver".