Re: [9front] Thoughts on Wayland?

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

05.08.2024 10:58:57 Noam Preil <noam@pixelhero.dev>:
> Of course, for e.g. treason, it's trickier, since frame buffers are
> decoded on the CPU side, and the entire frame buffer gets uploaded to
> devdraw.
>
> Best case, with gpufs, would be tossing the encoded data instead -
> which _would_ be a major bandwidth reduction. That might actually be
> sufficient for treason over 9p?

It could even be better: you can probably stream the data of a few frames. It could decode asynchronously what's there, which is likely more than just that one frame. You'd end up with a few frames before you need them, and you only have to clock the frames to get the exact frame you need (e.g. from a swapchain). Older frames can just safely be discarded.

Even better would be, streaming the data and decode it using the builtin GPU "hardware" decoders. That way you could also decode DRM-protected stuff, but I think those are also bound to direct display from the GPU on a monitor that supports DRM/HDCP/whatever. DRM stuff is horrible...

That feature is also currently not planned, I want the GPU as just a giant array of compute shaders with its own fast memory (GPGPU). Theoretically, you can call it gpgpufs, but since it's likely ending up in /dev as a driver and not as a client program, it's probably more like devgpu. Gpufs could be a client program for cpu emulation to make programs work without GPUs.

It might even make more sense to allow access to the GPU at an even lower level (basically the individual API calls) and have filesystems for the higher level stuff (e.g vulkanfs), but since that would mean more 9p messages that would probably decrease performance even more.

sirjofri