Comment by my123 | Hacker News Reader

Comment by my123 | Hacker News Reader

> 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.

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.

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?

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.

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

That extension was present in a lot of places before 1.3 in practice. It's nothing new.

(and indeed it helps significantly)

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

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.

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?

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.

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-sha...

[2]: https://arxiv.org/abs/2109.14682

Reply on news.ycombinator.com