Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello World on the GPU (2019)

acko.net

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Hello World on the GPU (2019)

#31

Post by kimixa »

Const-me wrote: post #25
pjmlp wrote: post #21

Earlier quoted context omitted.

Because it is Rust code?!? "...An easy tutorial in Rust" A short visit to the authors blog clearly shows they know what they talk about.

It’s not just the language. That code is impossible to directly translate to a pixel shader because GPUs only implement fixed-function blending. Render target pixels (and depth values) are write-only in the graphics pipeline, they can be only loaded with fixed-function pieces of GPUs: blending, depth rejection, etc. It’s technically possible to translate the code into compute shader/CUDA/OpenCL/etc., but that gonna b…

Tilers (mostly mobile and Apple) generally expose the ability to read & write the framebuffer value pretty easily - see things like GL_EXT_shader_framebuffer_fetch or vulkan's subpasses.

For immediate mode renderers (IE desktop cards), VK_EXT_fragment_shader_interlock seems available to correct those "concurrency" issues. DX12 ROVs seem to expose similar abilities. Though performance may be hit more than tiling architectures.

So you can certainly read-modify-write framebuffer values in pixel shaders using current hardware, which is what is needed for a fully shader-driven blending step.

Re: Hello World on the GPU (2019)

#32

Post by JonChesterfield »

krackers wrote: post #27
JonChesterfield wrote: post #2

As of this year (ish), `int main() {puts("hello, world\n");}` stands a decent chance of running on a GPU and doing the right thing if you compile it with clang. Terminal application style. Should be able to spell it printf shortly, variadic functions turn out to be a bit of a mess.

What does that do under the hood though? What does it mean to execute puts from a GPU?

Libc on x64 is roughly a bunch of userspace code over syscall which traps into the kernel. Looks like a function that takes six integer registers and writes results to some of those same registers.

Libc on nvptx or amdgpu is a bunch of userspace code over syscall, which is a function that takes eight integers per lane on the GPU. That "syscall" copies those integers to the x64/host/other architecture. You'll find it in a header called rpc.h, the same code compiled on host or GPU. Sometime later a thread on the host reads those integers, does whatever they asked for (e.g. call the host syscall on the next six integers), possibly copies values back.

Puts probably copies the string to the host 7*8 bytes at a time, reassembles it on the host, then passes it to the host implementation of puts. We should be able to kill the copy on some architectures. Some other functions run wholly on the GPU, e.g. sprintf shouldn't talk to the host, but fprintf will need to.

The GPU libc is fun from a design perspective because it can run code on either side of that communication channel as we see fit. E.g. printf floating point handling seems prone to large numbers of registers needed on the GPU at the moment so we may move some work to the host to make the register usage better (higher occupancy).

Re: Hello World on the GPU (2019)

#33

Post by SubjectToChange »

JonChesterfield wrote: post #29
pjmlp wrote: post #26

Earlier quoted context omitted.

CUDA already does printf, and C++20 support, minus modules.

C++20 would be news to me. Do you have a reference? The closest I can find is https://github.com/NVIDIA/cccl which seems to be atomic and bits of algorithm. E.g. can you point to unordered_map that works on the target? I think some pieces of libc++ work but don't know of any testing or documentation effort to track what parts, nor of any explicit handling in the source tree.

IIRC, CUDA Toolkit 12.0 added partial support for C++20 in nvcc and nvrtc.

Re: Hello World on the GPU (2019)

#34

Post by pjmlp »

JonChesterfield wrote: post #29
pjmlp wrote: post #26

Earlier quoted context omitted.

CUDA already does printf, and C++20 support, minus modules.

C++20 would be news to me. Do you have a reference? The closest I can find is https://github.com/NVIDIA/cccl which seems to be atomic and bits of algorithm. E.g. can you point to unordered_map that works on the target? I think some pieces of libc++ work but don't know of any testing or documentation effort to track what parts, nor of any explicit handling in the source tree.

Yes, it is right there on the documentation.

https://docs.nvidia.com/cuda/cuda-c-programming-guide/index....

Existing restrictions,

https://docs.nvidia.com/cuda/cuda-c-programming-guide/index....

Re: Hello World on the GPU (2019)

#35

Post by pjmlp »

keldaris wrote: post #28
JonChesterfield wrote: post #16

Earlier quoted context omitted.

Documentation is lagging reality a bit, we'll probably fix that around the next llvm release. Some information is at https://libc.llvm.org/gpu/using.html That GPU libc is mostly intended to bring things like fopen to openmp or cuda, but it turns out GPUs are totally usable as bare metal embedded targets. You can read/write to "host" memory, on that and a thread running on the host you can implement a syscall equivale…

Is there a way to directly use these developments to already write a reasonable subset of C/C++ for simpler usecases (basically doing some compute and showing the results on screen by just manipulating pixels in a buffer like you would with a fragment/pixel shader) in a way that's portable (across the three major desktop platforms, at least) without dealing with cumbersome non-portable APIs like OpenGL, OpenCL, Direc…

CUDA allows for straight C++ for quite some time, that is how renderers like nanite are written.

https://docs.nvidia.com/cuda/cuda-c-std/index.html

"C++ Standard Parallelism"

https://www.youtube.com/watch?v=nwrgLH5yAlM

Or if you prefer more vendor neutral,

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-...

Currently with C++17 support.

Re: Hello World on the GPU (2019)

#36

Post by SubjectToChange »

keldaris wrote: post #28
JonChesterfield wrote: post #16

Earlier quoted context omitted.

Documentation is lagging reality a bit, we'll probably fix that around the next llvm release. Some information is at https://libc.llvm.org/gpu/using.html That GPU libc is mostly intended to bring things like fopen to openmp or cuda, but it turns out GPUs are totally usable as bare metal embedded targets. You can read/write to "host" memory, on that and a thread running on the host you can implement a syscall equivale…

Is there a way to directly use these developments to already write a reasonable subset of C/C++ for simpler usecases (basically doing some compute and showing the results on screen by just manipulating pixels in a buffer like you would with a fragment/pixel shader) in a way that's portable (across the three major desktop platforms, at least) without dealing with cumbersome non-portable APIs like OpenGL, OpenCL, Direc…

If you’re willing to deal with 5 layers of C++ TMP, then a library like Kokkos will let you abstract over those APIs, or at least some of them. Eventually if or when SYCL is upstreamed in the llvm-project it’ll be possible to do it with clang directly.

Re: Hello World on the GPU (2019)

#37

Post by SubjectToChange »

pjmlp wrote: post #35
keldaris wrote: post #28

Earlier quoted context omitted.

Is there a way to directly use these developments to already write a reasonable subset of C/C++ for simpler usecases (basically doing some compute and showing the results on screen by just manipulating pixels in a buffer like you would with a fragment/pixel shader) in a way that's portable (across the three major desktop platforms, at least) without dealing with cumbersome non-portable APIs like OpenGL, OpenCL, Direc…

CUDA allows for straight C++ for quite some time, that is how renderers like nanite are written. https://docs.nvidia.com/cuda/cuda-c-std/index.html "C++ Standard Parallelism" https://www.youtube.com/watch?v=nwrgLH5yAlM Or if you prefer more vendor neutral, https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-... Currently with C++17 support.

I’m cautiously optimistic for SYCL. The absurd level of abstraction is a bit alarming, but single source performance portability would be a godsend for library authors.

Re: Hello World on the GPU (2019)

#38

Post by pjmlp »

SubjectToChange wrote: post #37
pjmlp wrote: post #35

Earlier quoted context omitted.

CUDA allows for straight C++ for quite some time, that is how renderers like nanite are written. https://docs.nvidia.com/cuda/cuda-c-std/index.html "C++ Standard Parallelism" https://www.youtube.com/watch?v=nwrgLH5yAlM Or if you prefer more vendor neutral, https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-... Currently with C++17 support.

I’m cautiously optimistic for SYCL. The absurd level of abstraction is a bit alarming, but single source performance portability would be a godsend for library authors.

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over.

It took almost 20 years to move from GPU Assembly (DX 9 timeframe), shading languages, to regular C, C++, Fortran and Python JITs.

There are some efforts with Java, .NET, Julia, Haskell, Chapel, Futhark, however still trailing behind the big four.

Currently in terms of ecosystem, tooling and libraries, as far as I am aware, Rust is trailing those, and not yet being a presence on HPC/Graphics (Eurographics, SIGGRAPH) conferences.

Re: Hello World on the GPU (2019)

#39

Post by SubjectToChange »

pjmlp wrote: post #38
SubjectToChange wrote: post #37

Earlier quoted context omitted.

I’m cautiously optimistic for SYCL. The absurd level of abstraction is a bit alarming, but single source performance portability would be a godsend for library authors.

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over. It took almost 20 years to move from GPU Assembly (DX 9 timeframe), shading languages, to regular C, C++, Fortran and Python JITs. There are some efforts with Java, .NET, Julia, Haskell, Chapel, Futhark, however still trailing behind the big four. Currently in terms of ecosystem, tooling and libraries, as far as I…

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over.

I 100% agree. Although I have a keen interest in Rust I can’t see it offering any unique value to the GPGPU or HPC space. Meanwhile C++ is gaining all sorts of support for HPC. For instance the parallel stl algorithms, mdspan, std::simd, std::blas, executors (eventually), etc. Not to mention all of the development work happening outside of the ISO standard, e.g. CUDA/ROCm(HIP)/OpenACC/OpenCL/OpenMP/SYCL/Kokkos/RAJA and who knows what else.

C++ is going to be sitting tight in compute for a long time to come.

Re: Hello World on the GPU (2019)

#40

Post by pjmlp »

SubjectToChange wrote: post #39
pjmlp wrote: post #38

Earlier quoted context omitted.

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over. It took almost 20 years to move from GPU Assembly (DX 9 timeframe), shading languages, to regular C, C++, Fortran and Python JITs. There are some efforts with Java, .NET, Julia, Haskell, Chapel, Futhark, however still trailing behind the big four. Currently in terms of ecosystem, tooling and libraries, as far as I…

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over. I 100% agree. Although I have a keen interest in Rust I can’t see it offering any unique value to the GPGPU or HPC space. Meanwhile C++ is gaining all sorts of support for HPC. For instance the parallel stl algorithms, mdspan, std::simd, std::blas, executors (eventually), etc. Not to mention all of the development…

There is always the argument that it can help reduce the errors produced due to memory corruption.

However industry standards matter more.

Post reply on HN