- Valve y Collabora están adaptando el driver de código abierto RADV para que funcione en Windows utilizando la interfaz WDDM2.
- El proyecto depende de la ingeniería inversa del driver propietario de AMD debido a la falta de documentación oficial del núcleo.
- Ya se ha logrado ejecutar Counter-Strike 2, aunque persisten retos de estabilidad y rendimiento en la presentación de imágenes.
Si te apasiona el mundo del gaming y el software libre, seguro que te suena el nombre de RADV. Básicamente, es el controlador Vulkan de código abierto que hace que las gráficas de AMD vuelen en Linux y que es el corazón del sistema en la Steam Deck. Ahora, resulta que Valve y Collabora se han liado la manta a la cabeza y están intentando llevar este motor a Windows, lo que podría cambiar la forma en que interactuamos con el hardware de AMD en el sistema de Microsoft.
La idea no es tirar a la basura los drivers oficiales, sino ofrecer una alternativa complementaria que permita mayor flexibilidad y facilidad para depurar errores. Aunque parece una locura técnica, ya han logrado que juegos como Counter-Strike 2 funcionen, demostrando que el camino es viable, aunque todavía tengan que pelear con un montón de obstáculos técnicos que dan más de un dolor de cabeza.
¿Qué es exactamente RADV y cómo funciona en Linux?
Para entender el lío, primero hay que saber que RADV es parte del proyecto Mesa. En el ecosistema Linux, actúa como un User Mode Driver (UMD) que se encarga de la parte «inteligente»: traduce las llamadas de la API Vulkan en instrucciones que la tarjeta gráfica entiende. Mientras tanto, el Kernel Mode Driver (KMD), llamado amdgpu, se ocupa de las tareas pesadas como la gestión de energía, la memoria de vídeo y la comunicación directa a través del puerto PCIe.
El proceso es bastante complejo. Cuando un juego pide dibujar algo, RADV utiliza un compilador de shaders llamado ACO (aunque también soporta LLVM para pruebas), que convierte el código SPIR-V en instrucciones nativas para la GPU. Después, genera paquetes en un formato llamado PM4, que se envían al núcleo del sistema para que la tarjeta los ejecute. Esta arquitectura es la que ha hecho que RADV sea el estándar de facto en Linux, superando incluso a las opciones propietarias de AMD.
El reto de aterrizar en Windows: La lucha contra lo oculto
Llevar esto a Windows no es simplemente copiar y pegar código. El gran problema es que en Windows no existe un controlador de núcleo abierto. Los desarrolladores tienen que interactuar con el driver propietario de AMD, que es básicamente una caja negra llena de código opaco y estructuras de datos privadas. Para avanzar, han tenido que recurrir a la ingeniería inversa mediante herramientas como wddm2-prev, que registra las llamadas del sistema para intentar adivinar cómo hablar con el hardware.
Este proyecto se apoya en la interfaz WDDM2 de Windows 10, que es mucho más flexible que las versiones antiguas. Sin embargo, hay un problema serio: el UMD y el KMD de AMD se distribuyen como un paquete cerrado. Si AMD actualiza el driver oficial, las estructuras internas pueden cambiar sin aviso, lo que rompe la compatibilidad de la versión de código abierto y obliga a los desarrolladores a empezar desde cero.
Avances técnicos y baches en el camino
A pesar de las dificultades, el equipo ha logrado hitos importantes. Han pasado de mostrar un simple modelo 3D girando en pantalla a soportar funciones avanzadas como task shaders, teselado y sparse bindings. No obstante, no todo ha sido color de rosa. Al pasar de hardware de décima generación (como la RX 7800 XT) a la generación 11 (como la RX 7900 XT), se encontraron con el hardware extremadamente sensible a los cambios, provocando cuelgues constantes que solo pudieron solucionar mejorando sus propias herramientas de registro y depuración.
Otro dolor de cabeza ha sido la compilación. Mesa se desarrolla principalmente con GCC y Clang, pero en Windows se usa MSVC. Resulta que MSVC gestiona los enumeradores de forma distinta, tratando algunos valores como signed, lo que provoca comportamientos erráticos y errores difíciles de rastrear. Además, la presentación de imágenes sigue siendo lenta porque utilizan una ruta basada en CPU, y para alcanzar el «santo gris» del zero-copy swap, necesitarían que Microsoft y AMD colaboraran directamente.
¿Qué necesitamos para que sea una realidad estable?
Para que RADV no sea solo una prueba de concepto y se convierta en algo usable para el gran público, se requieren dos cosas: que AMD publique una documentación clara y estable de su interfaz de núcleo, o que se cree una librería intermedia (shim) que proteja al controlador de código abierto de los cambios del driver oficial. Sin esto, el proyecto siempre será frágil y dependiente de la suerte.
- Soporte de Hardware: RADV es compatible con casi todas las GPUs GCN y RDNA, desde GCN 1 en adelante.
- Flujo de Trabajo: Al ser parte de Mesa, sigue reglas estrictas de revisión de código antes de integrar cualquier cambio.
- Ventaja Competitiva: Un driver abierto en Windows permitiría que los desarrolladores reporten fallos más rápido y optimicen el rendimiento sin depender de los tiempos de AMD.
Este ambicioso experimento, financiado por Valve, demuestra que es posible ejecutar un driver de Linux en Windows mediante el uso de WDDM2 y mucha ingeniería inversa. Aunque falta camino para lograr un rendimiento óptimo y una estabilidad total, el hecho de que ya existan juegos funcionales abre la puerta a un futuro donde el software libre domine la pila gráfica independientemente del sistema operativo que utilicemos.
