How a VM Draws Pixels: Mesa, Gallium, and virtio-gpu 3D

Drawing a spinning cube on a physical machine sounds ordinary: an application calls a graphics API, the GPU renders the scene, and the result appears on the screen. But when the same program runs inside a virtual machine, the question becomes more interesting. The guest behaves as if it owns a GPU, while the real rendering resources usually live on the host. So where is the cube actually drawn?

This talk follows one 3D rendering path inside a Linux guest, starting from Mesa. Mesa receives rendering requests from userspace applications, organizes graphics state and resources through Gallium, and passes the work into VirGL, a driver path designed for virtual GPUs. From there, the work crosses the boundary between Linux DRM and virtio-gpu 3D, becoming contexts, resources, command streams, and synchronization events that a virtual GPU can understand. Finally, the host renderer receives those commands and turns them into pixels.

Using a small but complete rendering demo as the thread, we will connect the journey from guest userspace, through the guest kernel and virtual GPU device, to the host renderer. The audience will see that 3D graphics in a VM is not just framebuffer copying. It is a collaboration across Mesa, DRM, virtio-gpu 3D, and the host GPU. Once these boundaries are opened up, “drawing pixels” inside a virtual machine becomes much more interesting than the image that finally appears on screen.