Una tarjeta gráfica que no existe todavía acaba de recibir doce mil líneas de código en el kernel de Linux. El 9 de noviembre, el mantenedor de AMDGPU Alex Deucher envió a la lista del kernel una serie de ocho parches para habilitar GFX13, la arquitectura que todo el mundo da por hecho que será RDNA 5. Son 12.643 líneas repartidas en 32 ficheros, con 15 borrados, y no incluyen las cabeceras de registros que suelen acompañar este tipo de trabajo. Nadie fuera de AMD ha visto el silicio que ese código va a manejar.
El envío no es una sorpresa. Desde enero hay soporte de GFX13 en el compilador LLVM, en agosto llegó Display Core Next 6 y en septiembre aparecieron los parches de GDDR7, la memoria que se espera en la próxima generación. Lo que faltaba era la pieza central: el controlador que hace que el motor gráfico funcione bajo Linux. Eso es lo que ha llegado ahora, y es también la señal más clara de que el programa avanza en el orden habitual, primero el software y después el silicio.
La lectura útil para el usuario de Linux no es la del rendimiento, porque no hay rendimiento que medir. Es la del calendario: cuando las distribuciones reciban el kernel que incluya estos parches, el soporte existirá antes de que la tarjeta esté a la venta. Esa ventaja es la que ha permitido a Linux jugar con ventaja en cada generación de GPU, y la razón por la que Valve puede mover SteamOS con tanta soltura sobre hardware que aún no ha salido.
¿Qué habilita exactamente la serie de parches?
El envío no se limita a registrar identificadores de hardware, que es lo que suelen hacer los primeros parches de una arquitectura nueva. Incluye el controlador del motor gráfico de GFX13, nuevas implementaciones del Micro Engine Scheduler y del Integrated Management Unit, componentes del Kernel Fusion Driver que gestiona las cargas de cómputo, un manejador de trampas para guardar y restaurar hilos de cómputo y varios mecanismos de control de reloj. Es decir, sienta las bases de planificación, cómputo y gestión energética.
Los parches de GFX13 enviados por Deucher cubren dos objetivos concretos, GFX 13.0.1 y GFX 13.0.4. Que haya dos identificadores sugiere al menos dos configuraciones de hardware distintas en preparación, aunque no implica dos tarjetas comerciales: puede tratarse de variantes de silicio con el mismo nombre de mercado. Una de las notas del parche reconoce además una limitación explícita, que el reset por cola del MES todavía no está soportado y debe permanecer desactivado hasta que se desarrolle.
Ese detalle es el que mejor describe en qué punto está el trabajo. No es un controlador terminado, es la primera capa de una habilitación que se completará con envíos posteriores durante los próximos meses. Quien instale un kernel con estos parches no obtendrá una GPU nueva funcionando, porque no hay GPU que instalar.
Conviene traducir las siglas, porque el texto de los parches es árido. El Micro Engine Scheduler es el planificador que reparte el trabajo entre las colas de la GPU; la Integrated Management Unit gestiona el encendido y apagado de bloques internos; el Kernel Fusion Driver es la pieza que expone la tarjeta como dispositivo de cómputo para tareas de cálculo. Que los tres aparezcan en el primer envío indica que hablamos de una arquitectura completa.
Un controlador de GPU se construye por capas, y este envío es el primer ladrillo de la capa que importa. Lo que viene ahora son correcciones, pruebas sobre silicio de ingeniería y, más adelante, nombres comerciales.
El calendario que se puede leer entre líneas
Sumando las piezas aparece una secuencia bastante coherente. Enero de 2026 deja el backend de GFX13 en LLVM listo para compilar. Agosto trae el motor de pantalla DCN6. Septiembre añade los parches de GDDR7, que apuntan al tipo de memoria de la próxima generación. Noviembre entrega el motor gráfico. Cada hito llega con unos meses de separación, que es el ritmo con el que AMD suele preparar una arquitectura antes de que aparezca el primer producto.
La siguiente estación previsible es el kernel 7.5, aunque la inclusión no está confirmada. Si los parches entran en ese ciclo, las distribuciones que sigan el kernel estable los tendrán disponibles durante la primera mitad de 2027. El ciclo actual va por la rc2 de Linux 7.4, que llegó con FAT32 hasta 162 veces más rápido, así que la ventana encaja con el calendario habitual. Los rumores sitúan el primer producto RDNA 5 en la segunda mitad de 2027, empezando por una GPU de gama media llamada AT2, con el resto de la familia deslizándose hacia 2028.
Los hitos no son casualidad, son un método. Cada bloque de propiedad intelectual se habilita en el árbol del kernel cuando está listo, y el conjunto se completa meses antes de que la tarjeta llegue a una tienda.
Para el usuario de Linux eso significa algo concreto y poco glamuroso: el soporte estará ahí antes de que haga falta. La consecuencia práctica es que la compra de una tarjeta no obligará a esperar seis meses de controladores verdes ni a convivir con un escritorio que parpadea mientras el driver madura. Esa ventaja silenciosa depende de dos piezas separadas que avanzan a la vez: el controlador del kernel y el trabajo en Mesa, la biblioteca donde se implementa la API gráfica que consumen los juegos.
Lo que los parches no dicen
No hay número de unidades de cómputo, ni frecuencias, ni configuración de memoria, ni cifras de rendimiento. Tampoco hay nombres comerciales. AMD no ha confirmado oficialmente que GFX13 se venda como RDNA 5, ni ha anunciado fecha de lanzamiento. Todo lo que se puede afirmar con los parches en la mano es que la compañía está preparando al menos dos configuraciones de IP gráfica y que el trabajo de software va por delante del hardware, como es habitual.
Esa ausencia de datos alimenta la especulación, y ahí conviene ser explícito: cualquier cifra de rendimiento que circule estos días es inventada o filtrada sin verificación. El tamaño del parche, doce mil líneas, no dice nada sobre potencia. Dice que la arquitectura tiene cambios suficientes como para justificar un controlador nuevo, lo cual era esperable en un salto de generación.
Hay una lectura de mercado que también merece matiz. Los envíos de parches suelen preceder al muestreo de silicio en varios trimestres, así que noviembre de 2026 encaja con un lanzamiento comercial en 2027. Que AMD publique el trabajo en abierto permite a las distribuciones y a los desarrolladores independientes probar y reportar antes de que el producto exista, algo que los fabricantes que dependen de blobs propietarios no pueden ofrecer.
El driver antes que el silicio
La forma en que AMD construye sus controladores explica buena parte de su posición en Linux. Cada generación llega al árbol principal del kernel, se revisa en público y se prueba en hardware que nadie tiene todavía. El mismo enfoque abierto llevó ROCm a FreeBSD para cargas de cómputo e IA, y es lo que permite que una distribución menor tenga soporte el día uno. El resultado es un ecosistema donde la tarjeta funciona el día que se conecta, sin depender de un instalador que solo soporta una distribución y una versión concreta.
Faltan meses para saber si RDNA 5 cumple lo que promete el calendario, y faltan datos para cualquier comparación seria con la competencia. Lo único verificable hoy es que el trabajo de base está hecho y que se puede auditar línea por línea en la lista del kernel, que es más de lo que ofrecen quienes anuncian arquitecturas con diapositivas.
