Re: [9front] Thoughts on Wayland?

[sirjofri <sirjofri+ml-9front@sirjofri.de>]

05.08.2024 13:48:41 hiro <23hiro@gmail.com>:
>> That's what I like about GPUs: they have dedicated memory and you have to upload manually. No synchronization issues, just what you upload is there. It's basically a different machine.
>
> whether you call it upload or synchronization makes no difference in practice.
> devdraw also has dedicated memory and you upload images into it
> manually. it doesn't only behave as if it was a different machine, but
> it is inspired by the difficulties that arose from having to run it on
> a dedicated terminal machine.
> from the point of view of devdraw and the whole development toolchain
> a gpu is a step back, bec. gpus aren't real computers, so the
> compilers stop working (i.e. the hardware target differs, just like
> the original blit). unlike with other cpu archs it's probably not
> worth getting our compilers ported into shaderland.

It surely isn't worth it, and I'd also not recommend it. It's a special case.

I'd more think about compiling the shaders "from source, on demand", which is common since the application cannot know which hardware the shader is run on.

Gpufs is based around vulkan, so you would compile your high level shader program to the SPIR-V intermediate language and just upload that to the filesystem. This cannot be run, but has to be compiled to the actual architecture of the GPU.

With that, in an ideal world, a host computer (cpu) runs and exports the gpufs and does the compilation of the shaders at this last stage, all bundled in the gpufs. My plan is to extend drawterm to do that, but it could also be just a single linux process, or a native plan 9 machine (if we ever get drivers).

>> With complex applications with hungry code and hungry graphics (many primitive draws) it would be a win-win: the hungry code gets more time on the client, because the client doesn't have to draw primitives, and you still get fancy graphics, because the hungry primitive drawing routines happens on the devdraw server side.
>
> i'm not sure why you care so much. mostly devdraw is a bandwidth
> optimization (preloaded textures).
> the primitives we have are more than enough to display 2D content
> efficiently. what usecase are you unable to implement with the given
> technique?

I'm a professional game developer working with Unreal. I could tell more, but I think that's enough.

>> My current plan for gpufs needs another round trip yet, because it doesn't integrate with devdraw at all. You'd have to kick off the drawing in gpufs, you have to download the resulting image, and load that into devdraw. Over network, it means a loss of performance, but I'm thinking about some kind of coupling, so that some devdraw-images are automatically linked with gpufs image buffers. At least on integrated systems like drawterm that should be possible. Still not perfect, but better than network round-trips.
>
> what are the ratios here? current perceived number of roundtrips for
> example graphical interaction, vs. theoretical minimum number of
> roundtrips  vs. your optimized -1 roundtrip?

Since this is early research, I don't have numbers. In the end, it can be all or nothing. As long as I'm unable to profile it, I can only speculate and say that there could be issues.

In a perfect world, the CPU sees an address and the GPU already knows the data, but that's magic, not engineering.

sirjofri