[HN Gopher] Adding HLSL and DirectX Support to Clang and LLVM
       ___________________________________________________________________
        
       Adding HLSL and DirectX Support to Clang and LLVM
        
       Author : cglong
       Score  : 72 points
       Date   : 2022-03-11 00:29 UTC (22 hours ago)
        
 (HTM) web link (discourse.llvm.org)
 (TXT) w3m dump (discourse.llvm.org)
        
       | mhh__ wrote:
       | 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.
        
       | dapids wrote:
       | This will be great. As it will allow me to offload code to
       | compute shaders without switching compilers.
        
       | my123 wrote:
       | > 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 wrote:
         | 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 wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2022-03-11 23:00 UTC)