Soporte de hardware RDNA 3.5 en Linux: estado real y futuro cercano

Informatec Digital » Recursos » Soporte de hardware RDNA 3.5 en Linux: estado real y futuro cercano

La llegada de las nuevas APU de AMD con gráficos integrados RDNA 3.5 ha puesto a Linux en el punto de mira de muchos usuarios que se preguntan si el sistema del pingüino está realmente preparado para exprimir este hardware desde el primer día. Entre firmwares adelantados, mejoras en el kernel y avances en la pila gráfica de código abierto, la cosa está bastante más interesante de lo que podría parecer a simple vista.

En paralelo, fabricantes como Lenovo con su ThinkPad T14s Gen 6 están sirviendo como banco de pruebas perfecto para medir cómo se comportan estas iGPU frente a Windows 11 con los controladores propietarios de AMD. A eso se suma un goteo constante de parches para los drivers AMDGPU y AMDKFD, el aterrizaje de nuevos bloques IP como GFX 11.5.3 y ajustes clave en el subsistema de pantallas. Todo apunta a que el soporte de hardware RDNA 3.5 en Linux ya no es un experimento, sino una apuesta muy seria.

Estado actual del soporte RDNA 3.5 en Linux

Para entender de dónde venimos y hacia dónde vamos, merece la pena repasar cómo se ha ido consolidando el soporte de las iGPU RDNA 3.5 en Linux a varios niveles: firmware, kernel y capa gráfica de usuario. AMD ha cambiado el ritmo respecto a generaciones anteriores, moviendo ficha antes de que los productos estén plenamente en la calle (historia entre Intel y AMD).

En los últimos días, AMD ha actualizado el repositorio linux-firmware.git con los blobs de firmware necesarios para que las nuevas GPU integradas basadas en RDNA 3.5 funcionen correctamente en Linux. Sin estos archivos, los controladores abiertos que vienen con el kernel no pueden inicializar el hardware, de modo que, en la práctica, la GPU quedaría inútil o muy limitada.

Lo llamativo es que, en esta ocasión, AMD ha decidido publicar el firmware con bastante antelación respecto al lanzamiento comercial de las nuevas APU. Tradicionalmente, estos paquetes llegaban a la vez o incluso después de que los productos se pudieran comprar, lo que dejaba a los usuarios de Linux en una especie de “limbo” durante semanas o meses.

Con este movimiento más proactivo, las distribuciones pueden empaquetar el firmware RDNA 3.5 en sus imágenes antes de que el hardware llegue masivamente a las tiendas. Eso se traduce en un soporte casi inmediato: instalas una distro reciente, arrancas y el sistema ya reconoce y aprovecha la GPU integrada sin necesidad de malabarismos.

En paralelo, el kernel de Linux ha ido incorporando mejoras constantes en el controlador AMDGPU en el espacio de núcleo, que es la base sobre la que se apoyan los drivers de espacio de usuario como RadeonSI (para OpenGL) y RADV (para Vulkan). Estos cambios no solo habilitan el nuevo hardware, sino que pulen el rendimiento, la gestión de energía y la estabilidad.

APUs RDNA 3.5 y bloques IP: qué se está preparando

Dentro de los firmwares publicados por AMD destaca especialmente el archivo correspondiente al bloque gráfico GFX 11.5.3, una nueva revisión de la arquitectura RDNA 3.5 que apunta a productos todavía no anunciados de forma oficial, pero de los que ya se habla en filtraciones y rumores de la industria.

Hasta ahora, AMD ha ido distribuyendo las versiones de GFX para RDNA 3.5 de esta forma: GFX 11.5.0 en Ryzen AI 300 “Strix Point”, GFX 11.5.1 en las variantes Ryzen AI Max 300 “Strix Halo” y GFX 11.5.2 en los Ryzen AI 350 “Kraken Point”. Cada número identifica un bloque IP concreto dentro de la familia RDNA 3.5.

La aparición de GFX 11.5.3 en el repositorio de firmware sugiere la inminencia de una nueva APU conocida internamente como “Gorgon Point”, que, según las filtraciones, sería la base de una futura serie Ryzen 9000G para sobremesa con Zen 5 y gráficos RDNA 3.5 mejorados. AMD utiliza esta numeración de bloques IP para separar variantes, lo que complica saber qué chip exacto corresponde a cada versión solo mirando el código.

El paquete publicado no se limita al apartado gráfico puro y duro; también incluye otros componentes esenciales del hardware como PSP 14.0.5 (Plataforma de Seguridad), SDMA 6.1.3 (control de acceso directo a memoria) y, muy importante, nuevas versiones del subsistema de vídeo Display Core Next.

En este punto destaca la llegada de DCN 3.6 para algunas variantes RDNA 3.5, cuando hasta ahora las implementaciones conocidas se habían quedado en DCN 3.5 y 3.5.1. Este salto de versión abre la puerta a mejoras relacionadas con salida de vídeo: mayor compatibilidad con resoluciones altas, tasas de refresco elevadas o configuraciones multi-monitor más complejas.

Para los usuarios finales, este conjunto de firmwares significa que cuando estas nuevas APU RDNA 3.5 y posibles derivadas de sobremesa lleguen al mercado, Linux ya tendrá los ladrillos básicos necesarios para que el sistema arranque con soporte gráfico funcional y estable desde el primer día.

Mejoras en AMDGPU y AMDKFD para el próximo kernel

Más allá de los firmwares, AMD está alimentando la cola de DRM-Next con un paquete bastante grande de cambios para sus controladores AMDGPU (gráfico) y AMDKFD (cómputo) que se integrarán en el próximo gran ciclo del kernel, previsto en torno a Linux 6.20 o a un posible salto a la rama 7.0.

En el apartado gráfico, los parches traen la habilitación de nuevas IP gráficas asociadas a RDNA 3.5 y también soporte preliminar para hardware basado en RDNA4 GFX12.1. Aunque este último todavía está lejos del usuario de a pie, deja claro que el soporte en Linux va prácticamente en paralelo al desarrollo interno del hardware de AMD.

Es decir, aunque el usuario no pueda pinchar mañana una GPU RDNA4 en su equipo, el kernel ya va incorporando código y rutas específicas para futuras generaciones. De este modo, cuando el producto se lance comercialmente, la base de soporte ya estará bastante madura y no habrá que empezar de cero.

Junto con las IP futuras, llega un buen puñado de ajustes internos: nuevas actualizaciones en la gestión del sistema SMU 15 (System Management Unit), que controla aspectos como frecuencias, voltajes y estados de energía, además de correcciones para versiones anteriores de SMU 14.x presentes en generaciones pre-RDNA 3.5.

También se incluyen correcciones relacionadas con SR-IOV (virtualización de GPU), mejoras en la cola de usuario (UserQ), una reestructuración del manejo del “buzón” SMU y ajustes en el programador del micro-motor MES. Desde fuera puede sonar a detalles menores, pero este tipo de cambios son los que marcan la diferencia en estabilidad y rendimiento sostenido a medio plazo.

En paralelo, el controlador de cómputo AMDKFD también recibe su buena ración de arreglos. Entre ellos, destaca la corrección de una fuga de memoria y soluciones específicas para sistemas que no utilizan páginas de kernel de 4K, como ciertos servidores ARM64 que trabajan con páginas de 64K cuando ejecutan cargas de trabajo de cómputo con hardware Instinct o Radeon.

Novedades clave en la salida de vídeo y HDMI

Dentro de estas mejoras, hay un parche bastante tangible para el usuario de escritorio que afecta al subsistema de pantallas del controlador AMDGPU. Se trata de una actualización del código HDMI para permitir frecuencias de hasta 340 MHz cuando la configuración del monitor y el adaptador lo soportan.

Hasta ahora, el controlador estaba limitado a unos 165 MHz de reloj de píxel por HDMI, una cifra heredada que se había quedado vieja y, de hecho, ni siquiera cumplía con la especificación de HDMI 1.3, que permite llegar justamente a 340 MHz. Este tope afectaba sobre todo a quienes usan adaptadores DP-HDMI (dongles) para conectar pantallas exigentes.

Con el nuevo parche, las configuraciones basadas en RDNA 3.5 y sucesores podrán activar resoluciones más altas o mayores tasas de refresco por HDMI, siempre que tanto el monitor como el adaptador lo permitan. No hace milagros —el hardware físico sigue mandando—, pero elimina un cuello de botella artificial en el lado del software.

Esta mejora encaja con la introducción de DCN 3.6 en algunas variantes RDNA 3.5, que viene a reforzar el soporte de salidas de vídeo modernas, algo fundamental en portátiles ultraligeros o estaciones de trabajo compactas que dependen de uno o dos puertos para todo.

Para el entorno Linux, donde muchos usuarios trabajan con monitores de alta resolución y configuraciones multimonitor, estos cambios hacen que el stack gráfico tenga menos “sorpresas” desagradables: menos parpadeos, menos limitaciones absurdas y una experiencia más alineada con lo que se consigue en Windows con los controladores propietarios.

Lenovo ThinkPad T14s Gen 6 como banco de pruebas

Un caso muy ilustrativo del estado actual del soporte RDNA 3.5 en Linux es el Lenovo ThinkPad T14s Gen 6, un portátil empresarial que ha llegado a los laboratorios de pruebas con uno de los nuevos procesadores Ryzen AI 7 PRO 360 y gráficos integrados Radeon 880M basados en RDNA 3.5.

Este equipo combina un diseño ligero con una iGPU RDNA 3.5 bastante capaz, lo que lo convierte en una plataforma de prueba perfecta para comparar el rendimiento gráfico nativo en Linux frente a Windows 11 y para evaluar soluciones como tarjeta gráfica externa para portátil.

Este equipo combina un diseño ligero con una iGPU RDNA 3.5 bastante capaz, lo que lo convierte en una plataforma de prueba perfecta para comparar el rendimiento gráfico nativo en Linux frente a Windows 11. La idea no es tanto medir FPS en juegos vía Proton, sino ver hasta qué punto la pila de código abierto de AMD ha madurado frente a los drivers propietarios.

Configuración de software en Windows 11 y Ubuntu 25.04

En el lado de Windows 11, el entorno de pruebas se basa en un sistema totalmente actualizado con los últimos parches de seguridad y rendimiento. A esto se suman los controladores de la suite AMD Radeon Software, que suelen incluir optimizaciones específicas para cada generación de GPU y soporte pulido para DirectX, Vulkan y OpenGL.

Este entorno hace uso de ejecución nativa de las aplicaciones, sin necesidad de capas de traducción como Proton, DXVK o similares, de manera que el rendimiento de la Radeon 880M se mide de forma directa en la plataforma de Microsoft, sin interferencias de compatibilidad.

En la parte de Ubuntu 25.04 beta, el sistema se configura con un kernel Linux 6.14 que incorpora las últimas características y parches para las APU Strix Point y otras variantes RDNA 3.5. Este kernel trabaja de la mano del controlador AMDGPU integrado, que es el que se encarga de hablar directamente con el hardware.

Sobre el kernel se asienta Mesa 25.0, la implementación de drivers 3D de código abierto que incluye RadeonSI para OpenGL y RADV para Vulkan. Esta combinación de driver en el núcleo y drivers de usuario es la que permite sacar partido al hardware RDNA 3.5 con bibliotecas completamente abiertas.

También en Ubuntu se prescinde de cualquier capa de compatibilidad tipo DXVK, VKD3D o Proton. Las pruebas se ejecutan con herramientas nativas para que la comparación con Windows 11 sea lo más justa posible, centrándose en el rendimiento bruto de los controladores y no en el de posibles traductores de API.

Metodología de benchmarks y herramientas utilizadas

Para analizar el comportamiento de la Radeon 880M bajo RDNA 3.5 en ambos sistemas, se recurre a una batería de benchmarks variados y relativamente conocidos, con el objetivo de cubrir tanto el rendimiento gráfico clásico como las capacidades de cómputo de la iGPU.

Entre las herramientas utilizadas se encuentra Geekbench 6 en su apartado de GPU, capaz de medir tareas de cómputo general y operaciones gráficas; GFXBench 5.0 en sus modos OpenGL y Vulkan, que ofrece escenas complejas para poner a prueba distintos caminos de renderizado, y glmark2, un clásico de Linux para estresar la pila OpenGL con escenas sintéticas.

A esta lista se suman benchmarks como Basemark GPU y Unigine Superposition, utilizados en diferentes configuraciones (por ejemplo, 720p en calidades Low y Medium) para observar el comportamiento en escenarios más parecidos a un uso real de aplicaciones 3D pesadas.

Además de las herramientas públicas, se utilizan benchmarks internos diseñados para estresar shaders y cargas de cómputo, lo que ayuda a medir mejor la eficiencia de la iGPU en tareas paralelas, filtrados o simulaciones físicas básicas que empiezan a ser habituales en flujos de trabajo modernos.

El conjunto de pruebas se centra siempre en cargas nativas, evitando mezclar tecnologías de traducción que puedan distorsionar la comparación. El objetivo principal es ver hasta dónde llega la pila de controladores RDNA 3.5 en Linux por sí sola frente a la combinación Windows 11 + drivers propietarios.

Resultados en OpenGL, Vulkan y pruebas sintéticas

En el terreno de OpenGL y Vulkan, las pruebas con GFXBench y glmark2 dejan a Ubuntu 25.04 en una posición bastante competitiva respecto a Windows 11. Donde hace unos años Linux quedaba siempre muy por detrás, ahora la diferencia se ha reducido muchísimo e incluso se da la vuelta en algunos escenarios.

En glmark2, por ejemplo, las escenas con alto uso de partículas y shaders complejos muestran que Ubuntu puede superar a Windows 11 en torno a un 12% en rendimiento, gracias al trabajo continuo sobre RadeonSI dentro de Mesa. Esto se traduce en una experiencia de escritorio y aplicaciones 3D bastante fluida.

En GFXBench 5.0 bajo Vulkan, los resultados son más ajustados: RADV mantiene el tipo frente al controlador propietario de AMD para Windows, con diferencias pequeñas que, en muchos casos, no se notan en el uso del día a día. Es una muestra clara de que el driver Vulkan abierto ha madurado muchísimo.

Cuando se pasa a Unigine Superposition, una prueba particularmente exigente, Windows 11 conserva una ligera ventaja de entre un 5 y un 7% en promedio. Aun así, la distancia es mucho más corta que en generaciones anteriores, donde los drivers abiertos quedaban claramente descolgados.

En el terreno del cómputo, con benchmarks como Geekbench GPU y pruebas internas, Ubuntu 25.04 llega incluso a adelantar a Windows 11 en varias tareas de procesamiento paralelo. La combinación de mejoras en ROCm, soporte de Vulkan Compute en RADV y la optimización del stack de AMDGPU hace que Linux brille precisamente en cargas intensivas de cómputo.

Linux frente a Windows en rendimiento gráfico RDNA 3.5

Si se junta toda la información de estas pruebas, la sensación general es que Linux se ha acercado muchísimo al rendimiento de Windows en iGPU RDNA 3.5, y en algunos escenarios incluso lo supera. No siempre gana, pero ya no juega en una liga claramente inferior como sucedía hace unos años.

Entre los factores clave está la combinación del kernel 6.14 con un AMDGPU muy trabajado, el salto a Mesa 25.0 con continuas mejoras en RadeonSI y RADV y el esfuerzo constante de AMD por seguir enviando código y revisiones a tiempo para cada ventana de fusión del kernel.

Para quienes utilizan el portátil con cargas de trabajo nativas —desarrollo, edición ligera, aplicaciones 3D, ofimática con varias pantallas conectadas—, la experiencia en Ubuntu 25.04 sobre RDNA 3.5 es perfectamente viable y, en muchos casos, muy sólida. El sistema no necesita drivers propietarios adicionales para ofrecer un rendimiento competitivo.

Esto también se traduce en una mayor tranquilidad a medio plazo: las mejoras que van entrando en el kernel y en Mesa se aplican de forma transparente a toda la gama de hardware soportado, por lo que es de esperar que, a medida que avance la serie 6.x o un futuro 7.0, los usuarios de RDNA 3.5 sigan viendo pequeñas ganancias y correcciones sin necesidad de reinstalar todo.

Al mismo tiempo, el adelantamiento de firmwares y el soporte temprano a bloques IP como GFX 11.5.3 y DCN 3.6 indican que el próximo salto de APUs y GPUs de AMD llegará a Linux con el terreno preparado: menos sustos, menos parches de emergencia y más funcionalidad activa desde el primer arranque.

El panorama del soporte de hardware RDNA 3.5 en Linux es hoy mucho más maduro y atractivo para quien quiera combinar un equipo moderno con un sistema operativo abierto, sea para trabajo diario, desarrollo, cómputo acel erado o un uso multimedia exigente sin depender de drivers cerrados.