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.
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).
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 equivalent (e.g. https://dl.acm.org/doi/10.1145/3458744.3473357), and once you have syscall the doors are wide open. I particularly like mmap from GPU kernels.
Spectacular vibe! Combined with the fullscreen animation is almost reminiscent of the demo-scene. I enjoyed the rest of the actual web page much more after that.
I salute thee whoever made this. Much appreciated!
for y in 0..height {
for x in 0..width {
// Get target position
let tx = x + offset;
let ty = y;
A Pixel-shader is all sorts of complications in practice that deserves at least a few days of studying the rendering pipeline to understand. But the tl;dr is that a pixel-shader launches a thread (erm... a SIMD-lane? A... work-item? A shader?) per pixel, and then the device drivers do some magic to group them together.
Like, in the raw hardware, pixel0-0 is going to be rendered at the same time as pixel0-1, pixel0-2, etc. etc. And the values inside of this "for loop" are the code that runs it all.
Sure its SIMD and all kinds of complicated to fully describe what's going on here. But the bulk of GPU-programming (or at least, for pixel shaders), is recognizing the one-thread-per-pixel (erm, SIMD-lane per pixel) approach.
------------------
Anyway, I think this post is... GPU-enough. I'm not sure if this truly executes on a GPU given how the code was written. But I'd give it my stamp of approval as far as "Describing code as if it were being done on a GPU", even if they're cheating for simplicity in many spots.
The #1 most important part is that the "rasterize" routine is written in the embarrassingly parallel mindset. Every pixel "could" in theory, be processed in parallel. (Notice that no pixels have race-conditions or locks, or sequencing needed with each other).
And the #2 part is having the "sequential" CPU-code logically and seamlessly communicate with the "embarrassingly parallel" rasterize routine in a simple, logical, and readable manner. And this post absolutely accomplishes that.
Its harder to write this cleanly than it looks. But having someone show you, as per this post, how it is done helps with the learning process.
Pixel shaders in WebGPU / wgpu are written in WGSL. The above 2-dimensional for-loop is _NOT_ a proper pixel shader (but it is written in a "Pixel Shader style", very familiar to any GPU programmer).
57 created objects later
"Hm. Damn"
Well .. there is a reason it is usually "hello triangle" on GPU tutorials. Spoiler alert, GPUs ain't easy.
Nowadays using "legacy" APIs is relatively easy, however it requires a background knowledge on how GL became GL 4.6, DX became DX 11 and so.
Modern APIs are super low level, they are designed as GPU APIs for driver writers basically. Since they cut the fat legacy API drivers used to take care for the applications, now everyone has to deal with such complexity directly, or make use of a middleware engine instead.
It's pretty much what OpenGL "drivers" were doing past the introduction of hardware shaders anyway - acting as a pretty thick middleware translating that to low-level commands, only having the user API being locked into a design from decades ago.
And considering how hard it was to get Khronos to eventually agree on vulkan in the first place (that effectively being a drop from AMD in "Mantle" then only tweaked by the committee), I'm not surprised they haven't standardized a higher-level API. So third party middleware it is.
You don't really have to though, you can still use the higher-level older graphics APIs. It wouldn't have made much sense for Vulkan to include a high-level graphics API as well, as those APIs already exist and have mature ecosystems.
Similarly, in Windows land, you aren't forced to use D3D12, you can still use D3D11 or even D3D9.
glBegin(GL_TRIANGLES);
glVertex3f( 0.0f, 1.0f, 0.0f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glVertex3f( 1.0f,-1.0f, 0.0f);
And there you go you got a triangle.
It's great for beginners because they can see the results very fast and once they want to start having crazy graphical effects or need more performance you can move to shaders.
So it's not all that surprising that the one is easier than the other, in a way it is surprising that the other can be done at all. But as CPUs and GPUs converge it's quite possible that NV or another manufacturer eventually slips enough general purpose capacity onto their cards that they function as completely separate systems. And then 'Hello world' will be trivial.