Paravirtualised graphics

A guest display can be a framebuffer the host copies, a virtio-gpu the guest already has a driver for, a real GPU assigned through passthrough, or MX GPU: an API-neutral paravirtualised device with guest additions on Linux and Windows. Those are different machines. They are not four skins on the same blit.

The four shapes

Scanout without a GPU is a framebuffer. The guest writes pixels. The host shows them. Fine for firmware and a serial-era install. Not a desktop.

Virtio-gpu is the standard paravirtualised GPU. Stock guests often already have the driver. MX implements it as a virtio device. It is the portable choice when you do not want MX guest additions.

MX GPU is MX's own protocol. The guest driver submits validated resources and work through fixed little-endian records. The device translates accepted work to the selected native host backend. Linux guests get a DRM/KMS driver. Windows guests get the WDDM path. Both consume the same shared core.

Passthrough is the guest talking to a real GPU. That is a different article. It is not paravirtualisation.

Why MX GPU is not a host-API tunnel

VirGL, many "GPU passthrough" shims, and raw handle-forwarding schemes leak host objects into the guest. A Metal, Vulkan, or Direct3D handle on the wire means the guest is no longer talking to a device. It is talking to this host's graphics stack.

MX GPU refuses that. The protocol is not VirtIO GPU, not VirGL, and not a transport for host object pointers. No field is a native pointer or an architecture-sized integer. AArch64 and x86_64 guests use the same records. The guest never sees host graphics objects. The host backend is chosen on the host, after the command has been accepted.

Every driver starts with a short negotiation. The device picks the highest common version and the feature bits it can honour. Scanout is required. Cursor, render, compute, and completion-fence signalling are optional. A driver that did not negotiate Render does not get a render node.

What the Linux guest sees

The Linux driver is a PCI device that speaks the protocol, then publishes DRM state.

With only scanout it is a KMS device: one primary plane, a virtual connector, dumb buffers, atomic flips. When Cursor is negotiated it gains an independent cursor plane. When Render or Compute plus completion-fence signalling are negotiated it also publishes a render node and syncobj timelines.

That split matters. A host that can only display frames still gets a working connector. Acceleration is not faked as a render node that cannot submit work.

Work on the host

Guest submission is non-blocking. PCI service does a bounded amount of descriptor work and enqueues validated commands. A worker owns the executor. Uploads, draws, dispatches, and presentation commit without waiting for the host GPU to finish before the next command is accepted.

The host backend is Metal, Vulkan, D3D12, or OpenGL, depending on the machine. The guest command stream does not change. The device translates after acceptance, which is why the same protocol works across guest and host architectures.

Integrate mode, the MX Studio feature that puts guest applications on the host desktop, depends on this path plus the guest agent. The debugger and the rest of the machine work against an unmodified guest. Accelerated display and Integrate need the additions.

When to pick which

Use MX GPU when the guest can take additions and you want MX's accelerated display, render, and Integrate path. Use virtio-gpu when the guest must stay stock. Use no GPU for firmware bring-up. Use passthrough when the guest's own driver and the physical device are the point, and you can spare that device from the host.