[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)