3 ms·

Compiling C++ to the SPIR-V dialect used by Vulkan in a usable form is close to technical impossibility... To the SPIR-V dialect used by OpenCL and oneAPI Leve

by my123 5y ago

Compiling C++ to the SPIR-V dialect used by Vulkan in a usable form is close to technical impossibility... To the SPIR-V dialect used by OpenCL and oneAPI Level Zero is a production-ready exercise heavily used by Intel's oneAPI compute stack. However, note that neither NVIDIA nor AMD support SPIR-V in their OpenCL implementation.

hansihe 5y ago
Isn't the main thing missing pointer support in shaders? As I understand it the VK_KHR_buffer_device_address is mandatory in 1.3 and should fix most of the blockers
- my123 5y ago
  That extension was present in a lot of places before 1.3 in practice. It's nothing new. (and indeed it helps significantly)
baggiponte 5y ago
I’m afraid I’m lost - what’s the relationship between HSLS, CUDA and OpenCL?
- raphlinus 5y ago
  I'll try to answer. CUDA is the Nvidia GPU compute infrastructure and runtime. The native language is a variant of C++, but there are lots of ways to use CUDA from Python (very popular in the machine learning world), Julia, etc. It is an extremely mature and polished way to get access to high performance compute. The biggest downside is that it's Nvidia proprietary. OpenCL is the older non-Nvidia standard infrastructure for GPU compute. It's languishing though. It is traditionally programmed in OpenCL C, but it does support other languages such as SYCL (another C++ dialect, similar in scope to CUDA C++). HLSL is similar in that it's a language for programming GPU code, also derived from C (with some C++ sprinkled in), but it's different than CUDA and OpenCL in that it's primarily for graphics applications rather than general purpose compute. The line blurs a bit with the concept of "compute shader," which can be seen as a cut-down CUDA or OpenCL that runs inside the GPU graphics API. Compute shaders are becoming more powerful in each generation. That said, HLSL is overwhelmingly popular for game development, because the tools are so good. This stuff is confusing. I haven't even touched on the different intermediate representations and the tools for converting between the different languages, of which there is an increasingly dense matrix.
  - iamcreasy 5y ago
    Thank you. Could you please also elaborate on this part. > Additionally DXC can be used to generate SPIR-V which can then be used either with the Vulkan runtime or, through SPIR-V cross, converted to GLSL or Metal Shader Language for use with their respective APIs. Is it like saying HSLS can be converted to GSLS or Metal Shaders by converting it to some intermediate representation first?
    - raphlinus 5y ago
      Exactly that. You compile down to SPIR-V, then use spirv-cross to generate Metal Shading Language or GLSL. It's clunky and there are some rough edges - these conversions aren't 100% lossless - but it does work. If you play a game on a mac, there's a very good chance this is the compilation strategy used.
raphlinus 5y ago
It may be close to a technical impossibility, but the Circle compiler by Sean Baxter is attempting it. That's based on an aggressive "de-pointerization" (see [1] in particular for details). There's also academic work[2] to compile C++ to shaders. I agree that it's an open question how well that will work out. Also as pointed out elsethread, now that buffer device address is starting to land, the friction to compile pointer-intense C++ code should decrease even more. These are exciting times! [1]: https://github.com/seanbaxter/shaders#approaching-circle-shaders-from-c https://github.com/seanbaxter/shaders#approaching-circle-sha... [2]: https://arxiv.org/abs/2109.14682 https://arxiv.org/abs/2109.14682

by my123 5y ago

hansihe 5y ago

Isn't the main thing missing pointer support in shaders? As I understand it the VK_KHR_buffer_device_address is mandatory in 1.3 and should fix most of the blockers

my123 5y ago
That extension was present in a lot of places before 1.3 in practice. It's nothing new. (and indeed it helps significantly)

baggiponte 5y ago

I’m afraid I’m lost - what’s the relationship between HSLS, CUDA and OpenCL?

raphlinus 5y ago
I'll try to answer. CUDA is the Nvidia GPU compute infrastructure and runtime. The native language is a variant of C++, but there are lots of ways to use CUDA from Python (very popular in the machine learning world), Julia, etc. It is an extremely mature and polished way to get access to high performance compute. The biggest downside is that it's Nvidia proprietary. OpenCL is the older non-Nvidia standard infrastructure for GPU compute. It's languishing though. It is traditionally programmed in OpenCL C, but it does support other languages such as SYCL (another C++ dialect, similar in scope to CUDA C++). HLSL is similar in that it's a language for programming GPU code, also derived from C (with some C++ sprinkled in), but it's different than CUDA and OpenCL in that it's primarily for graphics applications rather than general purpose compute. The line blurs a bit with the concept of "compute shader," which can be seen as a cut-down CUDA or OpenCL that runs inside the GPU graphics API. Compute shaders are becoming more powerful in each generation. That said, HLSL is overwhelmingly popular for game development, because the tools are so good. This stuff is confusing. I haven't even touched on the different intermediate representations and the tools for converting between the different languages, of which there is an increasingly dense matrix.
- iamcreasy 5y ago
  Thank you. Could you please also elaborate on this part. > Additionally DXC can be used to generate SPIR-V which can then be used either with the Vulkan runtime or, through SPIR-V cross, converted to GLSL or Metal Shader Language for use with their respective APIs. Is it like saying HSLS can be converted to GSLS or Metal Shaders by converting it to some intermediate representation first?
  - raphlinus 5y ago
    Exactly that. You compile down to SPIR-V, then use spirv-cross to generate Metal Shading Language or GLSL. It's clunky and there are some rough edges - these conversions aren't 100% lossless - but it does work. If you play a game on a mac, there's a very good chance this is the compilation strategy used.

raphlinus 5y ago

It may be close to a technical impossibility, but the Circle compiler by Sean Baxter is attempting it. That's based on an aggressive "de-pointerization" (see [1] in particular for details). There's also academic work[2] to compile C++ to shaders. I agree that it's an open question how well that will work out. Also as pointed out elsethread, now that buffer device address is starting to land, the friction to compile pointer-intense C++ code should decrease even more. These are exciting times! [1]: https://github.com/seanbaxter/shaders#approaching-circle-shaders-from-c https://github.com/seanbaxter/shaders#approaching-circle-sha... [2]: https://arxiv.org/abs/2109.14682 https://arxiv.org/abs/2109.14682