- Valve y Collabora trabajan en portar el driver de código abierto RADV para que funcione en Windows utilizando la API Vulkan.
- El proyecto actúa como un driver en modo usuario que se comunica con el driver propietario de AMD en modo kernel.
- La falta de documentación oficial de AMD y el uso de blobs opacos complican la estabilidad y el mantenimiento del desarrollo.
Seguramente estéis acostumbrados a que, si quieres exprimir una tarjeta gráfica de AMD en Windows, no tienes más remedio que instalar los drivers oficiales y cerrados del fabricante. Sin embargo, hay un movimiento bastante interesante cocinándose en el mundo del código abierto. Valve, la mente detrás de Steam, no se conforma con haber hecho que Linux y SteamOS vuelen en la Steam Deck, sino que ha puesto la mirada en Windows para intentar trasladar la potencia de los drivers RADV a nuestro sistema operativo más común.
Para los que no estéis muy puestos en el tema, RADV es básicamente el motor que impulsa Vulkan en los sistemas Linux a través de Mesa, convirtiéndose en el estándar de facto por su eficiencia. La idea aquí no es tirar a la basura los drivers de AMD que ya tenemos, sino complementarlos con una implementación open source que permita a los desarrolladores y usuarios tener una alternativa más flexible y transparente, facilitando el debugging y la corrección de errores sin depender exclusivamente de los tiempos de AMD.
¿Cómo funciona técnicamente este traslado?
Para entender esto hay que saber que un driver se divide en dos partes: el modo usuario (UMD) y el modo kernel (KMD). RADV es un UMD, lo que significa que se encarga de traducir las instrucciones de la API Vulkan a algo que el hardware entienda. El problema es que, en Windows, no existe un driver de kernel abierto que sea viable, por lo que el equipo de Collabora ha tenido que hacer malabares para que RADV hable el mismo idioma que el driver propietario de AMD que ya reside en el núcleo del sistema.
Gracias al trabajo previo de Faith Ekstrand y el uso de la interfaz WDDM2 en Windows 10, se descubrió que era posible interceptar llamadas y hacer ingeniería inversa. De hecho, ya han logrado hitos impresionantes, como conseguir que Counter-Strike 2 funcione utilizando RADV en Windows, aunque para llegar ahí han tenido que pelearse con la arquitectura de las tarjetas, ya que pasar de una GPU de décima generación a una de undécima (como la RX 7900 XT) puede hacer que todo el sistema colapse si no se ajustan los valores del hardware.
Los muros que frenan el proyecto
No todo es color de rosa en este camino. El mayor dolor de cabeza para los programadores es que AMD utiliza lo que llamamos blobs opacos de código. Básicamente, son trozos de software cerrados que no dejan ver qué hay dentro, lo que convierte el proceso de comunicación entre el driver abierto y el cerrado en una labor de adivinación constante. Al no haber documentación oficial, cualquier actualización del driver de AMD puede cambiar la estructura de los datos y romper por completo la compatibilidad de RADV, haciendo que el avance sea muy frágil.
- Incompatibilidad de compiladores: Mesa se desarrolla con GCC y Clang, pero en Windows se usa MSVC, que gestiona los enums de forma distinta, provocando comportamientos erráticos.
- El problema de la presentación: Actualmente, RADV en Windows usa una ruta de CPU lenta para mostrar la imagen. Para mejorar el rendimiento, necesitarían usar DXGI swapchains, algo que requiere metadatos opacos de D3D12.
- Dependencia del Kernel: Sin una librería puente (shim) o documentación de AMD, el proyecto sigue siendo más una prueba de concepto que un producto final listo para el gran público.
La arquitectura interna de RADV
Para quienes quieran entrar en harina, RADV es un driver de espacio de usuario que implementa Vulkan para GPUs GCN y RDNA. Su flujo de trabajo es fascinante: recibe los shaders en formato SPIR-V, los traduce a una representación intermedia llamada NIR y, finalmente, utiliza el compilador ACO para generar el código nativo de la GPU. Este proceso es lo que permite que la Steam Deck sea tan eficiente gestionando los recursos gráficos.
Mientras que el KMD se encarga de las tareas pesas como la gestión de energía, la memoria de vídeo y la comunicación por el puerto PCIe, RADV se ocupa de programar los registros y organizar los paquetes PM4 que se envían al procesador de comandos de la tarjeta. Esta separación es la que permite que, en teoría, se pueda cambiar el driver de usuario sin tener que reinstalar todo el núcleo del sistema operativo, siempre y cuando la comunicación sea estable.
Este ambicioso proyecto demuestra que hay un camino hacia la apertura de los drivers en Windows, aunque dependa en gran medida de que AMD decida abrir sus puertas y proporcionar la documentación necesaria. Por ahora, la comunidad tiene el código disponible en GitLab, permitiendo que cualquier entusiasta experimente con una alternativa abierta a Vulkan que promete reducir los tiempos de corrección de errores y fomentar la colaboración entre desarrolladores de juegos y fabricantes de hardware.
