Consider GPU Passthrough Support

[orlovskyjavaprofi]

I’ve been exploring GPU passthrough setups in containers/VMs and came across the dockur/windows Docker Compose example. It demonstrates an approach where the host’s NVIDIA GPU is dynamically unbound from the host drivers (like nouveau or nvidia) and bound to VFIO for passthrough into a Windows container, then switched back after shutdown.

Given this increasingly popular use case, I’d like to suggest that this X11Libre explicitly:

• Verify and ensure clean handling of GPU unbinding/binding cycles without crashing or destabilizing Xorg.
• Test and confirm compatibility with dynamic GPU device driver switching scenarios typical in passthrough workflows.
• Possibly provide hooks, logging, or support for seamless GPU reassignment to help container/VM users.
• Document any limitations or recommended configurations around GPU passthrough.

From what I’ve seen, GPU passthrough is often complicated by Xorg or Wayland sessions crashing or losing display when the GPU driver is unloaded on the host.
Since this fork is presumably will be a key part of the Linux graphics future stack, considering these scenarios and aiming for smooth, robust support would benefit users looking to run GPU-intensive workloads inside containers or VMs.
That would definitely help to migrate a lot of windows 10 users to Linux.

Happy to provide more context or help test if needed. Thank you for your work!

[orlovskyjavaprofi]

I found this github repo explaining how to do GPU passthrough.

It would be great if X11Libre would able to detect whenever this happens and result to:

• A fallback software renderer (like llvmpipe)
• A blank/disabled state instead of possible crashing
• A safe "headless" mode to keep user processes alive
• Better hotplug detection when a GPU is (re)attached
• Option to dynamically reinitialize GPU devices
• Avoid full X server restarts when GPU becomes available again

Outcome of such suggestion will result in following:
🛑 Gracefully handle GPU hot-unplug events: Prevent Xorg from crashing or freezing when the GPU is unbound for passthrough (e.g., VFIO use cases).

🔁 Support reinitialization on GPU rebind: Allow Xorg to detect and recover the GPU when it’s returned after the VM shuts down, without needing to restart the X session.

🖥️ Fallback rendering or status message: Provide a basic framebuffer or VESA-mode screen with a clear message (e.g., “GPU temporarily unavailable – running in fallback mode”) to inform the user during transitions.

[reaperx7]

We need to have a GPU partitioning system to allow an amount of GPU cores to be assigned/reserved for VFIO usage. This way we don't have to unbind a GPU in a single GPU system and leave the host system headless.

[Daniel-Abrecht]

With containers, you can do various things you can't do with full VMs. For example, you can pass through a socket for X. You can pass through a render node from /dev/dri/ for headless GPU rendering & acceleration. You can pass through a card node so you can do KMS / modesetting stuff (actually show things on the monitors connected to a card). In theory, you could pass through a drm lease for a specific output as an fd. There is also VKMS, which is basically virtual card nodes. VKMS was originally created for testing purposes, but I think it'd be interesting to see if it could be used as a fake display, and then show it in a window in the hosts display manager. That said, I don't think most of those things actually need any changes in X, I think this is mainly things that'd need to be added to container managers like docker, lxc, lxd, libvirt-lxc, and whatever else may be out there. Maybe some work may be needed on the kernel side too. This would then also work independent of the display manager in the container, so it'd work with wayland and mir too. And it doesn't require unbinding the graphics card from the host system.

[orlovskyjavaprofi]

@reaperx7
This is interesting, but in terms of usage, not such practical, let me explain: somebody plays a game in docker instance of win7 or win10 system, the GPU the video driver must be controlled in such scenario 100% by the guest system, sure its not perfect still people actually doing this in order to have "proper gaming experience".

@Daniel-Abrecht
I never though about this, but for me its seems it would require a lot of work to do such thing , as said early , two things which probably must be addressed by X11Libre like
detection of passtrough and then gracefully shutting down all the X11 related apps except those which used by the container app.

Is this perfect?
No, but it would bring a lot of former Windows 10 users to Linux, and one thing which I always missed in Xorg is the flexibility in how it handles support for dynamic multi-monitor setups and GPU hot-swapping

I found early discussions very important since i predict, that X11Libre will be very successful and highly adopted project in other Linux distros.

[reaperx7]

@reaperx7 This is interesting, but in terms of usage, not such practical, let me explain: somebody plays a game in docker instance of win7 or win10 system, the GPU the video driver must be controlled in such scenario 100% by the guest system, sure its not perfect still people actually doing this in order to have "proper gaming experience".

@Daniel-Abrecht I never though about this, but for me its seems it would require a lot of work to do such thing , as said early , two things which probably must be addressed by X11Libre like detection of passtrough and then gracefully shutting down all the X11 related apps except those which used by the container app.

Is this perfect? No, but it would bring a lot of former Windows 10 users to Linux, and one thing which I always missed in Xorg is the flexibility in how it handles support for dynamic multi-monitor setups and GPU hot-swapping

I found early discussions very important since i predict, that X11Libre will be very successful and highly adopted project in other Linux distros.

I've seen scenarios where Nvidia cards (single GPU) can be used in this manner, without going headless on the host. I wish I knew how they did it. But basically, you create, for example, a Virtual Geforce RTX 430MX or 4050 on a Geforce RTX 4090 for usage with KVM-QEmu with full passthrough, and under Windows, you just install the Nvidia driver normally but it shows up as the 430MX or 4050 with it's allocated RAM even. Usually 4-8GB.

I've seen Youtubers hint at how it's done, but it only works with Nvidia cards somehow, probably through their kernel driver(?) but I don't have a way to test this. I do have an old QuadroFX 470 PCIE but last time I tried using it as a secondary GPU to use for VFIO, my system refused to POST on it or my Radeon RX 5700XT.

[callmetango]

Moving this to X11Libre Ideas · Discussions · GitHub to refine this further.

[reaperx7]

I was thinking, the Virtual GPU system is already in place, why can't VFIO be redirected to the VirGL system through Mesa to use hardware resources still?

[callmetango]

Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the Good Ideas For Later category.