@@ -36,8 +36,21 @@
```
Install `libvirglrenderer-dev` before configuring if the guest should render on the host's GPU
(`virtio-gpu-gl`, `-display dbus,gl=on`). QEMU disables VirGL silently when it isn't there — check
`VirGL support` in the configure summary, or `-device help` for `virtio-gpu-gl`. That needs a DRM render node
on the host, so it does nothing on a host without `/dev/dri`, where the guest renders in software.
(`virtio-gpu-gl`, `-display dbus,gl=on`), and pass `--enable-virglrenderer` so a missing library fails the
configure instead of disabling VirGL quietly. Check `VirGL support` in the configure summary, or `-device help`
for `virtio-gpu-gl`.
VirGL needs a DRM render node whatever else the host can do. QEMU looks for one directly:
```
qemu-system-x86_64: egl: no drm render node available
qemu-system-x86_64: egl: render node init failed
```
On WSL2 that is the end of it. The GPU is reached through `/dev/dxg`, and while Mesa's D3D12 driver does give
the host hardware OpenGL (`GALLIUM_DRIVER=d3d12 MESA_D3D12_DEFAULT_ADAPTER_NAME=NVIDIA glxinfo -B` reports the
discrete GPU and `Accelerated: yes`), QEMU never asks Mesa — it enumerates render nodes, finds none, and stops.
Setting the D3D12 driver or `EGL_PLATFORM=surfaceless` changes nothing. So a guest on such a host renders in
software, and the guest's own `virtio-gpu` render node is what makes the DMABUF tests below runnable.
## How Sunshine reaches the VM

@@ -711,3 +711,27 @@
  test doesn't run and pass, so a VM that silently skips everything isn't green.
- Still needs real hardware: the EGL import path, VAAPI encoding, and every latency number for REQ-CAP-003.
### QEMU rebuilt with VirGL, and why it still doesn't help here (2026-09-16)
The QEMU 11.1.1 build had `VirGL support: NO`: `libvirglrenderer-dev` wasn't installed when it was configured and
meson disables VirGL without saying so. Nothing about that was WSL-specific. Rebuilt with the same flags plus
`--enable-virglrenderer`, which makes a missing library fail the configure instead: `VirGL support: YES 1.0.0`,
and `-device help` now lists `virtio-gpu-gl-pci` and `virtio-vga-gl`.
It changes nothing on this host, which QEMU says itself:
```
qemu-system-x86_64: egl: no drm render node available
qemu-system-x86_64: egl: render node init failed
```
Identical with `GALLIUM_DRIVER=d3d12 MESA_D3D12_DEFAULT_ADAPTER_NAME=NVIDIA` and with `EGL_PLATFORM=surfaceless`.
QEMU enumerates DRM render nodes rather than asking Mesa what it can do, so the host's D3D12 path is invisible to
it — even though that path is real: `GALLIUM_DRIVER=d3d12 MESA_D3D12_DEFAULT_ADAPTER_NAME=NVIDIA glxinfo -B`
reports `D3D12 (NVIDIA GeForce RTX 4090)`, `Accelerated: yes`, where the default is llvmpipe and `Accelerated: no`.
Host Vulkan is software only (lavapipe; no `dzn` ICD), which is what Steam and Proton would need.
So for the SteamOS guest (#14) on this host: Game Mode boots on lavapipe and is worth testing for app switching,
input and audio, and games are out of reach. The rebuilt QEMU is still the right binary to keep — on a host with
`/dev/dri` it can now do VirGL without another rebuild. Checked afterwards that the shared-memory path is
unaffected: `e2e_stream.sh` passes and the desktop rig streams.