Intel, Arm & Khronos Feel Ready to Land SPIR-V Backend Within LLVM

[phoronix]

Phoronix: Intel, Arm & Khronos Feel Ready to Land SPIR-V Backend Within LLVM

Engineers from Intel and Arm in cooperation with The Khronos Group feel ready now to begin landing their SPIR-V back-end within the upstream LLVM source tree! This SPIR-V back-end for LLVM would ultimately allow LLVM front-ends for different languages to more easily target this industry-standard shader representation so that it could be ingested by Vulkan / OpenCL drivers...

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Ready-For-SPIR-V-Backend

[Linuxxx]

Intel for their part has been initially focused on OpenCL compute portion of SPIR-V while acknowledging the possibility of extending it to support 3D shaders for Vulkan.

So will it be just as useless for real-time shader compilation as AMD's official LLVM Mesa compiler?

[shmerl]

So now this can enable using Rust for GPU programming?

[coder]

So now this can enable using Rust for GPU programming?

For writing kernels, but only if SPIR-V has all of the facilities needed to support the Rust language. I'm guessing it does, but it's not guaranteed.

Note that you might get poor performance from using general-purpose languages on GPUs. They're not designed to vectorize as well as purpose-built GPU programming languages, and their assumptions about the memory model could result in tons of memory barriers being emitted.

[shmerl]

For writing kernels, but only if SPIR-V has all of the facilities needed to support the Rust language. I'm guessing it does, but it's not guaranteed.

Note that you might get poor performance from using general-purpose languages on GPUs. They're not designed to vectorize as well as purpose-built GPU programming languages, and their assumptions about the memory model could result in tons of memory barriers being emitted.

I suppose if this gains more interest, Rust can address this use case same as variants of C++ were created for GPU programming.

I hope something will eventually be good enough to dislodge CUDA for real and Rust is probably the best candidate for it.

[coder]

I hope something will eventually be good enough to dislodge CUDA for real and Rust is probably the best candidate for it.

CUDA isn't only about the device-programming language. It's also about the host API, which this development doesn't address.

SYCL and Intel's DPC++ do address the host API, but only for specific use cases. Presumably, oneAPI has more general abstractions for the host API that could substitute for CUDA's, in most/all cases, but I don't actually have any detailed knowledge of it.

[ms178]

That graph looks complicated with a lot of middle-layers in between, I hope this doesn't cost too much performance or is prone to bugs due to the added complexity.

[Jabberwocky]

That graph looks complicated with a lot of middle-layers in between, I hope this doesn't cost too much performance or is prone to bugs due to the added complexity.

+1 IMO it's complicated because in the grand scheme of things everyone is doing their own thing until now. Upstream has been the issue for all these years. Well done Intel!

AMD seems to be focusing most of their resources on their own implementation but at least they are at trying to support other backends https://github.com/hipSYCL/featuresupport

Nvidia... well same as always only doing open source for marketing never contributing anything usable. In their latest marketing scheme they open sourced half-assed "alternative" to FSR https://github.com/NVIDIAGameWorks/NVIDIAImageScaling Nvidia knows 99% of people reporting on it will just use it to promote the terms "open source" and "DLSS", similar to what I'm doing right here. The difference is that I'm at least linking the repo but sites like these don't even bother. They just put Nvidia's hipster PR video at the very top of the page and hopes everyone watches it https://www.techspot.com/news/92242-...tive-dlss.html

Nvidia ****** you!