Valve ha financiado la primera fase de un proyecto desarrollado por Collabora para adaptar RADV, el controlador Vulkan abierto de Mesa para GPU AMD, al sistema operativo Windows. El prototipo ya consigue ejecutar Counter-Strike 2 mediante Vulkan, aunque todavía no alcanza la estabilidad, compatibilidad ni rendimiento necesarios para utilizarse como alternativa cotidiana.
RADV constituye actualmente la implementación Vulkan utilizada por Steam Deck y por numerosas distribuciones Linux con gráficos Radeon. Trasladarlo a Windows permitiría compartir más código entre plataformas, facilitar la depuración y abrir las correcciones a desarrolladores externos, pero el proyecto continúa condicionado por la interfaz privada del controlador de AMD en modo kernel.
RADV funciona en Linux sobre el controlador amdgpu
RADV es un controlador en espacio de usuario integrado dentro de Mesa, responsable de implementar Vulkan, compilar shaders, programar los registros gráficos y preparar los comandos que ejecutará la GPU. En Linux se comunica con el controlador amdgpu incluido en el kernel, utilizando una interfaz pública y diseñada para mantener esa separación.
El controlador en modo kernel se ocupa de tareas como la gestión de memoria gráfica, las frecuencias, la alimentación, las colas de ejecución y la comunicación mediante PCIe. RADV administra la parte superior de la pila gráfica, mientras que amdgpu proporciona el acceso de bajo nivel necesario para enviar finalmente el trabajo al hardware.
Esta estructura ha permitido que RADV se convierta en el controlador Vulkan de facto para GPU AMD dentro de Linux. Mesa ofrece soporte para arquitecturas GCN y RDNA, mientras que las GPU desde GCN 3 en adelante pueden alcanzar compatibilidad con Vulkan 1.4, dependiendo del modelo y de la conformidad certificada.
Counter-Strike 2 ya funciona mediante el controlador experimental
El proyecto parte del trabajo presentado por Faith Ekstrand durante XDC 2024, donde demostró que RADV podía enviar comandos a una GPU AMD utilizando el modelo WDDM 2 de Windows. Collabora ha ampliado posteriormente esa base para reducir valores codificados manualmente, funcionar de forma nativa fuera de WSL y mejorar considerablemente la estabilidad.
La adaptación incorpora mejoras en la gestión de command streams, la sincronización y la consulta dinámica de las propiedades de la GPU. También añade soporte para funciones como sparse bindings, teselación y task shaders, aumentando el porcentaje de pruebas Vulkan ejecutadas correctamente, aunque el controlador todavía no cumple todos los requisitos de conformidad.
El resultado más visible es que Counter-Strike 2 ya puede iniciarse utilizando RADV sobre Windows. Collabora activa la ruta Vulkan mediante el parámetro «-vulkan», demostrando que el proyecto ha avanzado desde representar una escena sencilla hasta ejecutar una carga gráfica real, pero esto continúa siendo una prueba de concepto y no un controlador preparado para usuarios finales.
El controlador propietario de AMD representa el principal obstáculo
Windows separa igualmente los controladores entre una parte en espacio de usuario, conocida como UMD, y otra ejecutada en modo kernel, denominada KMD. El problema es que RADV necesita comunicarse con el KMD oficial de AMD mediante estructuras privadas, datos opacos e interfaces que no disponen de documentación pública.
Collabora ha tenido que reconstruir parte de este funcionamiento analizando llamadas de WDDM 2, asignaciones de memoria, creación de colas y envíos de comandos realizados por el controlador oficial. El equipo también desarrolló herramientas capaces de registrar command streams, registros y código de shaders, compensando parcialmente la ausencia de utilidades públicas para investigar bloqueos gráficos.
La principal limitación es que el UMD y el KMD propietarios se distribuyen como una pareja coordinada sin garantía de compatibilidad hacia atrás. AMD puede cambiar las estructuras privadas entre dos versiones del controlador, provocando que una implementación basada en ingeniería inversa deje de funcionar sin previo aviso.
Desarrollar un KMD completamente nuevo tampoco se considera una opción realista. Para alcanzar una versión mantenible, Collabora necesitaría una interfaz estable y documentada proporcionada por AMD o una biblioteca intermedia que traduzca las comunicaciones privadas y preserve una superficie compatible frente a futuras actualizaciones.
La presentación de imágenes todavía utiliza una ruta lenta
Además de ejecutar los comandos gráficos, un controlador debe presentar cada imagen terminada dentro de la ventana o pantalla correspondiente. La versión actual de RADV para Windows utiliza una ruta de presentación procesada mediante la CPU, considerablemente menos eficiente que las cadenas de intercambio nativas empleadas normalmente por las aplicaciones gráficas.
El siguiente paso sería integrar swapchains mediante DXGI para evitar copias y reducir la intervención del procesador. Sin embargo, esta ruta exige importar imágenes procedentes de D3D12 junto con sus metadatos privados, reproduciendo nuevamente el problema causado por las estructuras opacas del controlador propietario.
Collabora considera que alcanzar una presentación zero-copy podría multiplicar hasta por tres el rendimiento en aplicaciones que no estén limitadas por la GPU. La estimación no representa una mejora garantizada en juegos y requeriría la colaboración directa de AMD y probablemente Microsoft para resolver las restricciones relacionadas con el intercambio de imágenes.
El proyecto no garantiza todavía un lanzamiento público
El trabajo financiado por Valve demuestra que un controlador Vulkan abierto para GPU AMD puede funcionar sobre Windows, pero no confirma que vaya a distribuirse próximamente como producto estable. La compatibilidad actual depende de información reconstruida, carece de conformidad completa y puede romperse al actualizar el controlador oficial.
Una versión utilizable aportaría una base común para Linux y Windows, depuración pública y correcciones compartidas entre sistemas operativos. También permitiría que desarrolladores de juegos investigasen errores directamente dentro del código del controlador, en lugar de depender exclusivamente de informes enviados a AMD.
El código de esta fase permanece publicado en una rama de desarrollo de Mesa para que otros programadores puedan examinarlo y continuar el trabajo. Su futuro dependerá principalmente de conseguir una interfaz estable con el KMD de AMD, completar la presentación mediante DXGI y superar las pruebas de conformidad y estabilidad.
Vía: TechPowerUp
