3 ms·
> 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
by 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 agoI 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 agoCompiling 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 agoIsn'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 agoThat extension was present in a lot of places before 1.3 in practice. It's nothing new. (and indeed it helps significantly)
- baggiponte 5y agoI’m afraid I’m lost - what’s the relationship between HSLS, CUDA and OpenCL?
- raphlinus 5y agoI'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.
- 5y ago
- diamondlovesyou 5y agoWith 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.