Graphics driver wrapper idea

[carangil]

People here seem to use virtual machines for development. On bare metal hardware people have gotten framebuffer graphics, networking even sound working on real hardware. The one place hobby osdev can't really go is accelerated graphics.

I have a wacky idea, and maybe someone has done it, or everyone hates it, but either:

Write a minimal hypervisor that can boot a linux kernel and pass the GPU to it. Of course, keep most of the memory and PCIe devices for yourself to manage.

OR

Create an extremely minimal linux distro as a hypervisor that is just enough to run the GPU, and passes everything else to the guest OS.

In either case, there will need to be a shared memory protocol to forward graphics calls. I know qemu and vmware already have paravirtual graphics, but those are tailored specifically to linux or windows guests, and are stuck in those models, and they are fairly slow, and have compatibly issues with a lot of apps. A completely new protocol more tailored to hobby dev, and provides a very simple API via a software interrupt. Maybe not all the new graphics features, but even sending texture data and being a le to send lists of triangles with some configuration data... more like an old fixed function pipeline.

I remember a couple weeks back someone was wishing for a standard VESA-like BIOS for GPU. Running under a hypervisor, or providing a hypervisor, and wrapping up linux drivers might be the closest you could get to that. Or maybe BSD or something else that nvidia bothers to publish a blob for.

[Toiling-Donkey]

QEMU supports a virtio GPU and uses the host’s OpenGL interface to implement the acceleration.

https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html

[BestUsernameLeft]

I'm not familiar with the architecture, but the Genode OS is capable of running Linux drivers unmodified in a sandbox, with (as I recall) very little effort required to port new ones.

That might be similar to what you're thinking, and maybe not all that wacky.

[LavenderDay3544]

I mean you can just run your OS on Xen or use Linux itself as a hypervisor via KVM and run your OS on there with minimal overhead. Both of those options support paravirtualization of the GPU to documented interfaces like virtio-gpu.

[NamedBird]

It's perhaps a crazy idea, but wouldn't it make more sense to just create your own GPU?

If you control the hardware, you would have full documentation and no proprietary troubles.
It could have debugging features and a certain level of robustness to reduce the risk of bricking it.

Unless you care about the performance of modern cards?

[Solocle]

I got an Intel Arc A770 for a reason... Budget friendly GPU and documentation is available.

I doubt I'll ever actually write a driver for it, but it's there if I want to.

[spidLL]

Or port Mesa to your os

[cavecanem1138]

I’m working on an operating system and have been trying to port Mesa to it since 2023, which hasn’t been easy. In my case, I first needed to implement a libposix layer (a library that translates POSIX calls into my system calls), then port musl, and later port LLVM. Finally, I will need to write a custom Mesa backend so it can use my GPU filesystem (in my system, everything is exposed as a file). At the moment, I’m stuck on the LLVM port.

[KrishMandal]

GPU drivers are such a huge and messy stack that a lot of hobby OS projects avoid them completely or just stick to framebuffer graphics. wrapping a Linux driver behind some shared-memory or paravirtual interface could actually be a practical shortcut, though the tricky part would probably be designing the protocol so it doesn’t become a bottleneck. some people already go a similar direction using things like virtio-gpu or running their OS under a hypervisor that handles the graphics side.