[C-programmer]

Genuinely, why?

- For new code, all of the functions [here](https://libc.llvm.org/gpu/support.html#libc-gpu-support) you can do without just fine.

- For old code:

  * Your project is large enough that you are likely use using an unsupported libc function somewhere.

  * Your project is small enough that you would benefit from just implementing a new kernel yourself.

I am biased because I avoid the C standard library even on the CPU, but this seems like a technology that raises the floor not the ceiling of what is possible.

[JonChesterfield]

> Genuinely, why?

> ... this seems like a technology that raises the floor not the ceiling of what is possible.

The root cause reason for this project existing is to show that GPU programming is not synonymous with CUDA (or the other offloading languages).

It's nominally to help people run existing code on GPUs. Disregarding that use case, it shows that GPUs can actually do things like fprintf or open sockets. This is obvious to the implementation but seems largely missed by application developers. Lots of people think GPUs can only do floating point math.

Especially on an APU, where the GPU units and the CPU cores can hammer on the same memory, it is a travesty to persist with the "offloading to accelerator" model. Raw C++ isn't an especially sensible language to program GPUs in but it's workable and I think it's better than CUDA.

[krackers]

>Disregarding that use case, it shows that GPUs can actually do things like fprintf or open sockets.

Can you elaborate on this? My mental model of GPU is basically like a huge vector coprocessor. How would things like printf or sockets work directly from the GPU when they require syscalls to trap into the OS kernel? Given that the kernel code is running on the CPU, that seems to imply that there needs to be a handover at some point. Or conversely even if there was unified memory and the GPU could directly address memory-mapped peripherals, you'd basically need to reimplement drivers wouldn't you?

[rbanffy]

> Lots of people think GPUs can only do floating point math.

IIRC, every Raspberry Pi is brought up by the GPU setting up the system before the CPU is brought out of reset and the bootloader looks for the OS.

> it is a travesty to persist with the "offloading to accelerator" model.

Operating systems would need to support heterogeneous processors running programs with different ISAs accessing the same pools of memory. I'd LOVE to see that. It'd be extremely convenient to have first-class processes running on the GPU MIMD cores.

I'm not sure there is much research done in that space. I believe IBM mainframe OSs have something like that because programmers are exposed to the various hardware assists that run as coprocessors sharing the main memory with the OS and applications.

[einpoklum]

> The root cause reason for this project existing is to show that GPU > programming is not synonymous with CUDA (or the other offloading > languages).

1. The ability to use a particular library does not reflect much on which languages can be used.

2. One you have PTX as a backend target for a compiler, obviously you can use all sorts of languages on the frontend - which NVIDIA's drivers and libraries won't even know about. Or you can just use PTX as your language - making your point that GPU programming is not synonymous with CUDA C++.

> It's nominally to help people run existing code on GPUs.

I'm worried you might be right. But - we should really not encourage people to run existing CPU-side code on GPUs, that's rarely (or maybe never?) a good idea.

> Raw C++ isn't an especially sensible language to program GPUs in > but it's workable and I think it's better than CUDA.

CUDA is an execution ecosystem. The programming language for writing kernel code is "CUDA C++", which _is_ C++, plus a few builtins functions ... or maybe I'm misunderstanding this sentence.

[nickysielicki]

https://developer.nvidia.com/blog/simplifying-gpu-applicatio...

[tredre3]

> this seems like a technology that raises the floor not the ceiling of what is possible.

In your view, how is making GPU programming easier a bad thing?

[convolvatron]

that's clearly not a bad thing. however encouraging people to run mutating, procedural code with explicit loops and aliasing maybe isn't the right path to get there. particularly if you just drag forward all the weird old baggage with libc and its horrible string conventions.

I think any programming environment that treats a gpu as a really slow serial cpu isn't really what you want(?)

[JonChesterfield]

One thing this gives you is syscall on the gpu. Functions like sprintf are just blobs of userspace code, but others like fopen require support from the operating system (or whatever else the hardware needs you to do). That plumbing was decently annoying to write for the gpu.

These aren't gpu kernels. They're functions to call from kernels.

[almostgotcaught]

> One thing this gives you is syscall on the gpu

i wish people in our industry would stop (forever, completely, absolutely) using metaphors/allusions. it's a complete disservice to anyone that isn't in on the trick. it doesn't give you syscalls. that's impossible because there's no sys/os on a gpu and your actual os does not (necessarily) have any way to peer into the address space/schedular/etc of a gpu core.

what it gives you is something that's working really really hard to pretend be a syscall:

> Traditionally, the C library abstracts over several functions that interface with the platform’s operating system through system calls. The GPU however does not provide an operating system that can handle target dependent operations. Instead, we implemented remote procedure calls to interface with the host’s operating system while executing on a GPU.

https://libc.llvm.org/gpu/rpc.html.