4 ms·

I wonder how GPU is going to access an unknown size NULL terminated string in system RAM, the strchr() source looks like normal C++. In my minimal Vulkan GPGPU

by fuhsnn 2y ago

I wonder how GPU is going to access an unknown size NULL terminated string in system RAM, the strchr() source looks like normal C++. In my minimal Vulkan GPGPU experience the data need to be bound to VkDeviceMemory to be accessible through PCI bus with compute shader, is LLVM libc runtime doing similar set-ups in the background, and if so, is it faster than glibc's hand-tuned AVX implementation?

JonChesterfield 2y ago
This is libc running on the GPU, not a libc spanning CPU and GPU. The primary obstruction to doing that is persuading people to let go of glibc. The spec of "host runs antique glibc, GPU runs some other thing that interops transparently with glibc" is a nightmare of hacks and tragedy. What would be relatively easy to put together is llvm libc running on the host x64 and also llvm libc running on the GPU. There's then the option to do things like malloc() on the GPU and free() the same pointer on the CPU. Making it genuinely seamless also involves persuading people to change what function pointers are, do some work on the ABI, and preferably move to APUs because PCIe is unhelpful. There's an uphill battle to bring people along on the journey of "program the things differently". For example, here's a thread trying to drum up enthusiasm for making function pointers into integers as that makes passing them between heterogenous architectures far easier https://discourse.llvm.org/t/rfc-function-pointers-as-integers-beyond-wasm/83208/7 https://discourse.llvm.org/t/rfc-function-pointers-as-intege....
- fuhsnn 2y ago
  >making function pointers into integers as that makes passing them between heterogenous architectures This is interesting, though function pointers are long expected to be address on binary, C-brained people like me would probably adapt to the concept of "pointer to a heterogeneous lambda object" or "shared id across heterogeneous runtimes" easier.
  - JonChesterfield 2y ago
    Yeah, I might need to take another angle at the branding / sales part, possibly with a prototype in hand. I was hopeful that wasm was sufficient prior art. Whether function pointers are absolute addresses, or relative to the start of text, or resolved through trampolines filled in by the loader, or are offsets into some table is all (nominally) invisible to the language. Integer in [0, k) has the nice feature that multiple GPUs can each index into their own lookup table containing pointers to the local code section. Or for calling into another machine - it's essentially a cheap serialisation / perfect hash done at linker time. It makes indirect calls slower, but indirect calls are slow anyway so hopefully saleable.
    - int_19h 2y ago
      One could argue that the MMU is a prior art of sorts. We haven't really been dealing with direct physical memory addresses on most platforms for a very long time.
- yjftsjthsd-h 2y ago
  If the host has an antique glibc, surely it has an antique llvm libc? Does llvm just have a more stable ABI or something?

by fuhsnn 2y ago

JonChesterfield 2y ago

This is libc running on the GPU, not a libc spanning CPU and GPU. The primary obstruction to doing that is persuading people to let go of glibc. The spec of "host runs antique glibc, GPU runs some other thing that interops transparently with glibc" is a nightmare of hacks and tragedy. What would be relatively easy to put together is llvm libc running on the host x64 and also llvm libc running on the GPU. There's then the option to do things like malloc() on the GPU and free() the same pointer on the CPU. Making it genuinely seamless also involves persuading people to change what function pointers are, do some work on the ABI, and preferably move to APUs because PCIe is unhelpful. There's an uphill battle to bring people along on the journey of "program the things differently". For example, here's a thread trying to drum up enthusiasm for making function pointers into integers as that makes passing them between heterogenous architectures far easier https://discourse.llvm.org/t/rfc-function-pointers-as-integers-beyond-wasm/83208/7 https://discourse.llvm.org/t/rfc-function-pointers-as-intege....

fuhsnn 2y ago
>making function pointers into integers as that makes passing them between heterogenous architectures This is interesting, though function pointers are long expected to be address on binary, C-brained people like me would probably adapt to the concept of "pointer to a heterogeneous lambda object" or "shared id across heterogeneous runtimes" easier.
- JonChesterfield 2y ago
  Yeah, I might need to take another angle at the branding / sales part, possibly with a prototype in hand. I was hopeful that wasm was sufficient prior art. Whether function pointers are absolute addresses, or relative to the start of text, or resolved through trampolines filled in by the loader, or are offsets into some table is all (nominally) invisible to the language. Integer in [0, k) has the nice feature that multiple GPUs can each index into their own lookup table containing pointers to the local code section. Or for calling into another machine - it's essentially a cheap serialisation / perfect hash done at linker time. It makes indirect calls slower, but indirect calls are slow anyway so hopefully saleable.
  - int_19h 2y ago
    One could argue that the MMU is a prior art of sorts. We haven't really been dealing with direct physical memory addresses on most platforms for a very long time.
yjftsjthsd-h 2y ago
If the host has an antique glibc, surely it has an antique llvm libc? Does llvm just have a more stable ABI or something?