How AMD Is Taking Standard C/C++ Code To Run Directly On GPUs

[phoronix]

Phoronix: How AMD Is Taking Standard C/C++ Code To Run Directly On GPUs

Back at the 2024 LLVM Developers' Meeting was an interesting presentation by AMD engineer Joseph Huber for how they have been exploring running common, standard C/C++ code directly on GPUs without having to be adapted for any GPU language / programming dialects or other adaptations...

https://www.phoronix.com/news/AMD-Standard-C-Code-GPUs

[aerospace]

This is really nice.

[Setif]

Will the code run on CPU and offload loops and array operations to GPUs automatically by the compiler, or run entirely on GPU. If the latter, Aren't some operations not possible or slow to run on GPUs?

[NeoMorpheus]

If this helps getting rid of the cuda monopoly and makes ROCm unnecessary then fine by me.

Sadly, if this does eliminate the need of ROCm, the local haters will need something else to keep the hate going. Lol

[chuckula]

I'm in favor of anything that makes GPUs less of a black box hidden behind millions of lines of driver code & convoluted APIs. Of course optimizing this to target the strengths of the GPU is the next step l, but this is very cool.

[habilain]

Will the code run on CPU and offload loops and array operations to GPUs automatically by the compiler, or run entirely on GPU. If the latter, Aren't some operations not possible or slow to run on GPUs?

GPUs are turing complete these days, so "slow" rather than "not possible". I think at the moment it's mainly "this code can be run on the GPU" rather than automatic offloading - which, while it would be nice for the lazy programmer, would probably not be possible on a standard GPU architecture. That's mainly because the GPU and CPU do not share the same memory, so offloading a loop from CPU to GPU has a high fixed cost and I really don't see a good way of being able to automatically determine when it's worth doing.

If this helps getting rid of the cuda monopoly and makes ROCm unnecessary then fine by me.

Sadly, if this does eliminate the need of ROCm, the local haters will need something else to keep the hate going. Lol

Do a little more research - LLVM is targetting ROCm in this case.

[Nille]

run entirely on GPU. If the latter, Aren't some operations not possible or slow to run on GPUs?

As far as i understand all runs on the GPU without concern of it fast or slow on it.

[DiamondAngle]

If this helps getting rid of the cuda monopoly and makes ROCm unnecessary then fine by me.

Sadly, if this does eliminate the need of ROCm, the local haters will need something else to keep the hate going. Lol

i mean this IS rocm. At the base level this is the rocm compiler and the rocm runtime just skipping the single source wrangling and without the syntactic sugar or the build system that supports it (hipcc).

95% of "ROCm" is a huge amount of libaries that provide domain specific kernels that perform well, because getting good performance across various gpus is _hard_ so everyone relies on the vendors to provide a tonne of premade kernels (often written in asm) that they then just use.
Even if you start adding syntactic sugar to this that makes it sane to use, preformance wise, you would have to port all of that from rocm/hip to this, a huge undertakeing with no real upside.
This is a fun and interesting toy but its really hard to see how it could ever be mutch more than that.

[andreano]

This appears to be not just about C or C++ or GPUs but Rust and FPGAs as well:

I saw a demo of Rust on an AMD Xilinx FPGA. Yes, the Rust code was synthesized to FPGA logic. The guy told me this:
Unlike Intel, which are reimplementing C++ in the form of SYCL with OneApi, which targets their GPU and FPGA products, AMD is doing the same using LLVM IR as input.

[ddriver]

Bad idea, you don't know which feature works, or how costly the feature implementation.

At the risk of sounding old-fashioned, I say compute kernels should be PODs, primitives and low level arithmetic only. There's no need for any more abstraction on the compute side of things.