5 ms·

Adding HLSL and DirectX Support to Clang and LLVM

124 points by cglong 5y ago

my123 5y ago
> But in general, SPIR-V, as a standard, has two quite different “profiles” to accommodate the needs of graphics like Vulkan and compute like OpenCL. These two “profiles” correspond to the capabilities in the Shader and Kernel tree respectively. They have quite different approaches towards memory models, runtime shader/kernel ABI etc. For the Shader side, it’s using logical addressing mode where we have abstract pointers (no physical size, cannot store into memory by default, etc.) and generally rely on indices to access nested structures. There are quite a lot of requirements on how resources are represented (e.g., using structs with special decorations) and how they match across shader stages (vertex/geometry/fragment/etc.). For the Kernel side, it’s using physical addressing mode, where it’s more akin to LLVM’s approach towards pointers and you can do all sorts of casting. Resources and interfaces are also simpler, without the need to match multiple shader stages and interact with fixed-function stages. So to me, among the two, the Kernel side is more of a fit to go through LLVM flow. Letting the Shader side go through LLVM you might need to fight hard with LLVM transformations assuming more of the Kernel mentality, e.g., recovering structured control flow, handling convergence, threading decorations needed through various layers, etc. Some of the issues have been discussed for a long time in the community and I’m not sure we have a good answer towards them even today. Note that part of the thread specifically deals with the issues of SPIR-V being split into two different profiles (Shader for graphics and Kernel for compute APIs). The Shader dialect, which is used for OpenGL 4.6 and Vulkan, is not exactly especially practical for general GPGPU use. It's the Achilles' heel of Vulkan compute and significantly affects this effort too.
- skywal_l 5y ago
  I am a complete noob regarding these subjects so pardon my ignorance but does it mean they intent to compile C++ to SPIR-V (or something that's GPUs can understand)? Does it mean short circuiting CUDA?
  - 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.
- diamondlovesyou 5y ago
  With the Physical Address Buffer extension, many of the pain points in this area aren't impossible anymore, even if Vulkan SPIR-V overall is still painfull vs CUDA/HIP/ROCM.
mhh__ 5y ago
Would love to see a GCC backend for these types of things although can't help but think the way GCC works wrt to cross compiling will always hold it back.
- pjmlp 5y ago
  What holds GCC back is that many companies using LLVM for these efforts never contribute to upstream, thanks license. They would never used GCC regardless of how GIMPLE and backend infrastructure might be.
  - mhh__ 5y ago
    If we assume the first paragraph is true then only the second dominates the ability of the GCC developers to work on this kind of thing. LLVM allows you to build one compiler with N backends, whereas GCC basically doesn't. This is very annoying if you want to compile a mixture of code to (say) native object code and shaders.
    - pjmlp 5y ago
      That wasn't an issue before LLVM came to be. The first is definitely an issue, how many Nintendo or Sony contributions have landed on upstream? Or the interesting detail that while standard LLVM bitcode isn't stable, the one used by watchOS is. Finally the increasing pain that despite the amount of LLVM users topping Linux kernel like usage, clang is now lagging behind C++ compliance.
      - mhh__ 5y ago
        Was anyone trying to do it before LLVM existed properly?
        pjmlp 5y ago
        Naturally, better learn the history of GCC forks, their use in embedded and language research in universities. Which is one of the reasons why GNU C Compiler got renamed as GNU Compiler Collection. LLVM isn't even anything new as idea. At very least PL.8, Amsterdam Compiler Toolkit, TrenDRA, MSR Phoenix exist as prior art.
dapids 5y ago
This will be great. As it will allow me to offload code to compute shaders without switching compilers.
rjeli 5y ago
> DXIL, the intermediate representation used for DirectX 12, is based on LLVM-3.7 IR encoded as bitcode. For many reasons that have been discussed at length within the LLVM community in the past, this is not great, but it has already shipped and is the driver interface for all DirectX 12 GPU drivers. ouch!
- ruph123 5y ago
  Can someone please explain why this is is problematic?
  - hyperman1 5y ago
    I assume they can't upgrade to more recent LLVM versions, as the 3.7 bitcode is now found in a ton of published games. If they move to, say, 3.8, they need a LLVM 3.7 to 3.8 bitcode translator. Basically, microsoft published someone else's unstable, unsupported API.
    - pjmlp 5y ago
      Apple does the same with LLVM bitcode for watchOS, but apparently Microsoft doesn't want to control the whole stack.
    - my123 5y ago
      > they need a LLVM 3.7 to 3.8 bitcode translator. LLVM IR provides upwards compatibility, that’s not what the issue is. The issue is rather having your game binaries not work at all on older OS/driver releases when built with a newer LLVM version.
  - pjmlp 5y ago
    On most 3D APIs, with exception of OpenGL (and its Web variants), shaders are shipped as binaries, so if the driver expects another version that game won't play.
- mijoharas 5y ago
  Could someone expand upon the reasons? I can think of a few off the top of my head (it ties you to an old llvm version) but at the same time, presumably you need to reduce the size on the wire of this format so you need some kind of bitcode, and since it seems to be a binary interface for GPU drivers which can't be changing regularly the choice seems as good as any other? Note: these are all naive uneducated assumptions on my part, as I'm not well informed in this area.
nevi-me 5y ago
It's great to see stacks that forked off from earlier versions of LLVM coming back to the main tree. The SPIRV backend is mentioned in the discussion, and I'm hopeful that they'll find a way for all the components to compose well together at their various levels of the architecture. What I remain curious about, is whether NVIDIA will someday follow suite. IIRC CUDA is based on an oldish LLVM version. While there's an AMDGPU target that's actively developed, and a way for one to build CUDA with a recent LLVM version, it'd be great to have everything close to trunk.
- nevi-me 5y ago
  I meant NVPTX
TazeTSchnitzel 5y ago
Using LLVM to target GPUs is one of those ideas that's a lot prettier on paper than it is in practice. There are so many problems… nonetheless, multiple vendors invested a lot in this approach and are stuck with it. At least trying to integrate DirectX and HLSL upstream might force LLVM to fix some of the GPU pain points? The fact there is no upstream SPIR-V backend after all these years doesn't give me much hope though.

124 points by cglong 5y ago

> But in general, SPIR-V, as a standard, has two quite different “profiles” to accommodate the needs of graphics like Vulkan and compute like OpenCL. These two “profiles” correspond to the capabilities in the Shader and Kernel tree respectively. They have quite different approaches towards memory models, runtime shader/kernel ABI etc. For the Shader side, it’s using logical addressing mode where we have abstract pointers (no physical size, cannot store into memory by default, etc.) and generally rely on indices to access nested structures. There are quite a lot of requirements on how resources are represented (e.g., using structs with special decorations) and how they match across shader stages (vertex/geometry/fragment/etc.). For the Kernel side, it’s using physical addressing mode, where it’s more akin to LLVM’s approach towards pointers and you can do all sorts of casting. Resources and interfaces are also simpler, without the need to match multiple shader stages and interact with fixed-function stages. So to me, among the two, the Kernel side is more of a fit to go through LLVM flow. Letting the Shader side go through LLVM you might need to fight hard with LLVM transformations assuming more of the Kernel mentality, e.g., recovering structured control flow, handling convergence, threading decorations needed through various layers, etc. Some of the issues have been discussed for a long time in the community and I’m not sure we have a good answer towards them even today. Note that part of the thread specifically deals with the issues of SPIR-V being split into two different profiles (Shader for graphics and Kernel for compute APIs). The Shader dialect, which is used for OpenGL 4.6 and Vulkan, is not exactly especially practical for general GPGPU use. It's the Achilles' heel of Vulkan compute and significantly affects this effort too.

skywal_l 5y ago
I am a complete noob regarding these subjects so pardon my ignorance but does it mean they intent to compile C++ to SPIR-V (or something that's GPUs can understand)? Does it mean short circuiting CUDA?
- 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.
diamondlovesyou 5y ago
With the Physical Address Buffer extension, many of the pain points in this area aren't impossible anymore, even if Vulkan SPIR-V overall is still painfull vs CUDA/HIP/ROCM.

mhh__ 5y ago

Would love to see a GCC backend for these types of things although can't help but think the way GCC works wrt to cross compiling will always hold it back.

pjmlp 5y ago
What holds GCC back is that many companies using LLVM for these efforts never contribute to upstream, thanks license. They would never used GCC regardless of how GIMPLE and backend infrastructure might be.
- mhh__ 5y ago
  If we assume the first paragraph is true then only the second dominates the ability of the GCC developers to work on this kind of thing. LLVM allows you to build one compiler with N backends, whereas GCC basically doesn't. This is very annoying if you want to compile a mixture of code to (say) native object code and shaders.
  - pjmlp 5y ago
    That wasn't an issue before LLVM came to be. The first is definitely an issue, how many Nintendo or Sony contributions have landed on upstream? Or the interesting detail that while standard LLVM bitcode isn't stable, the one used by watchOS is. Finally the increasing pain that despite the amount of LLVM users topping Linux kernel like usage, clang is now lagging behind C++ compliance.
    - mhh__ 5y ago
      Was anyone trying to do it before LLVM existed properly?
      - pjmlp 5y ago
        Naturally, better learn the history of GCC forks, their use in embedded and language research in universities. Which is one of the reasons why GNU C Compiler got renamed as GNU Compiler Collection. LLVM isn't even anything new as idea. At very least PL.8, Amsterdam Compiler Toolkit, TrenDRA, MSR Phoenix exist as prior art.

dapids 5y ago

This will be great. As it will allow me to offload code to compute shaders without switching compilers.

rjeli 5y ago

> DXIL, the intermediate representation used for DirectX 12, is based on LLVM-3.7 IR encoded as bitcode. For many reasons that have been discussed at length within the LLVM community in the past, this is not great, but it has already shipped and is the driver interface for all DirectX 12 GPU drivers. ouch!

ruph123 5y ago
Can someone please explain why this is is problematic?
- hyperman1 5y ago
  I assume they can't upgrade to more recent LLVM versions, as the 3.7 bitcode is now found in a ton of published games. If they move to, say, 3.8, they need a LLVM 3.7 to 3.8 bitcode translator. Basically, microsoft published someone else's unstable, unsupported API.
  - pjmlp 5y ago
    Apple does the same with LLVM bitcode for watchOS, but apparently Microsoft doesn't want to control the whole stack.
  - my123 5y ago
    > they need a LLVM 3.7 to 3.8 bitcode translator. LLVM IR provides upwards compatibility, that’s not what the issue is. The issue is rather having your game binaries not work at all on older OS/driver releases when built with a newer LLVM version.
- pjmlp 5y ago
  On most 3D APIs, with exception of OpenGL (and its Web variants), shaders are shipped as binaries, so if the driver expects another version that game won't play.
mijoharas 5y ago
Could someone expand upon the reasons? I can think of a few off the top of my head (it ties you to an old llvm version) but at the same time, presumably you need to reduce the size on the wire of this format so you need some kind of bitcode, and since it seems to be a binary interface for GPU drivers which can't be changing regularly the choice seems as good as any other? Note: these are all naive uneducated assumptions on my part, as I'm not well informed in this area.

nevi-me 5y ago

It's great to see stacks that forked off from earlier versions of LLVM coming back to the main tree. The SPIRV backend is mentioned in the discussion, and I'm hopeful that they'll find a way for all the components to compose well together at their various levels of the architecture. What I remain curious about, is whether NVIDIA will someday follow suite. IIRC CUDA is based on an oldish LLVM version. While there's an AMDGPU target that's actively developed, and a way for one to build CUDA with a recent LLVM version, it'd be great to have everything close to trunk.

nevi-me 5y ago
I meant NVPTX

TazeTSchnitzel 5y ago

Using LLVM to target GPUs is one of those ideas that's a lot prettier on paper than it is in practice. There are so many problems… nonetheless, multiple vendors invested a lot in this approach and are stuck with it. At least trying to integrate DirectX and HLSL upstream might force LLVM to fix some of the GPU pain points? The fact there is no upstream SPIR-V backend after all these years doesn't give me much hope though.