Triton: DirectX 11 en QEMU ya no es un chiste — es una realidad

El sueño húmedo de todo sysadmin: DirectX 11 corriendo en QEMU

Si alguna vez has intentado virtualizar Windows con aceleración gráfica, sabes que es una pesadilla. O te conformas con el escritorio remoto lento, o haces GPU passthrough con dos tarjetas de video y un ritual de configuración que parece más un exorcismo que una instalación. Pero el equipo de UTM acaba de soltar algo que cambia las reglas del juego: Triton, un driver de Windows que trae soporte completo de DirectX 11 a máquinas virtuales QEMU.

Y no es un hack de «copiar este DLL al lado del .exe y rezar». Es un driver de verdad, a nivel de kernel, que implementa la DDI (Device Driver Interface) de DirectX. La diferencia es brutal: el compositor de escritorio de Windows (DWM) lo reconoce como un driver legítimo, lo que significa que tienes aceleración en todo el sistema, no solo en juegos específicos.

La magia negra: de DDI a API y de vuelta

Lo que hace Triton es elegantemente retorcido. Normalmente, cuando una app llama a Direct3D, la DLL del sistema (d3d11.dll) traduce esas llamadas a comandos DDI que van al driver. Triton hace el camino inverso: recibe los comandos DDI y los convierte de vuelta en llamadas a la API de DirectX. ¿Para qué? Para pasárselas a Neptune, el protocolo de serialización que ya tenían funcionando, y mandarlas por VirtIO al host.

Es como si agarraras una carta, la tradujeras a código Morse, y después alguien la volviera a traducir a español para leerla. Suena redundante, pero es brillante: evita tener que inventar un protocolo nuevo para serializar comandos DDI, y aprovecha todo el trabajo ya hecho en Neptune. Menos pasos de transformación = menos bugs.

Shared textures en Apple Silicon: el truco del shm_open()

Una de las partes más interesantes es cómo resolvieron el problema de compartir texturas entre procesos en macOS. En Linux es relativamente fácil con DMAbuf, pero en macOS… bueno, Apple no te la pone fácil. Probaron MTLSharedTextureHandle (requiere XPC, un infierno), IOSurface (deprecado y con penalización de GPU blit), y CALayerHost (API privada, peor todavía).

La solución vino de un colaborador que sugirió usar shm_open() para crear un objeto de memoria compartida, mapearlo a un MTLBuffer, y pasar el file descriptor entre procesos con SCM_RIGHTS. Funciona porque Apple Silicon usa UMA (Unified Memory Architecture): CPU y GPU comparten el mismo espacio de direcciones físico. Es un hack hermoso que solo es posible en hardware moderno.

Fences emulados: cuando no tienes GPU fences de verdad

Otro problema peludo: la sincronización. Cuando el proceso A dibuja una textura y el proceso B la consume para compositar el escritorio, necesitas fences de GPU para evitar tearing. Apple no expone MTLSharedEvent sin XPC, así que tuvieron que emularlos.

El truco es usar ClearUnorderedAccessViewUint —una llamada de DirectX que escribe un entero en un buffer— para escribir un valor de timeline en memoria compartida. El productor ejecuta esto en la GPU (así que está ordenado con los draws anteriores), y el consumidor hace polling en CPU hasta que ve el valor actualizado. No es perfecto —introduce latencia— pero para fences que ocurren una vez por frame, funciona.

DXMT vs D3DMetal: la guerra de los backends

En el host macOS, Triton puede usar dos backends distintos. DXMT traduce Direct3D 11 directamente a Metal (open source, ARM64 nativo). D3DMetal es el framework de Apple para Game Porting Toolkit, que corre en Rosetta (solo tiene binario x86_64) pero aún así le saca el doble de rendimiento a DXMT. El problema: la licencia de D3DMetal prohíbe su distribución fuera de «desarrollo y evaluación de juegos». Así que por ahora, DXMT es la opción que puede ir en UTM.

¿Qué significa esto para nosotros?

Como alguien que administra VPS y pasa más tiempo del que me gustaría lidiando con virtualización, esto me parece enorme. QEMU siempre fue el patito feo en aceleración gráfica para Windows —VirtualBox tenía algo, VMware también, pero QEMU se quedaba atrás. Triton cierra esa brecha y lo hace de forma limpia: open source, con upstreaming en mente, y con una arquitectura que no depende de hacks frágiles.

Si usas UTM en macOS para correr VMs de Windows, prepárate. Cuando esto llegue a la versión estable, vas a poder jugar juegos modernos en una VM sin GPU passthrough. Y si eres de los que corre Linux como host, la arquitectura de Neptune+Triton también funciona con DXVK+Vulkan. El futuro de la virtualización gráfica se ve bien, y por primera vez en mucho tiempo, QEMU va a la cabeza.

Fuente de inspiración: Introducing Triton: DirectX 11 driver for QEMU