Un fallo de corrupción de vídeo que arrastran las gráficas Radeon de la era R600 desde hace casi veinte años tiene ya solución. El parche, desarrollado con ayuda de OpenAI Codex por un colaborador externo, ha sido aceptado por AMD y viaja en el envío de controladores que entrará en la ventana de integración del kernel Linux 7.5, prevista para fin de año. La corrección devuelve la reproducción de vídeo sin artefactos a equipos que AMD dejó de mantener oficialmente hace tiempo.
Os contamos el origen exacto del fallo: afectaba al bloque UVD (Unified Video Decoding), el componente que decodifica vídeo comprimido en estas GPU. AMD dejó de mantener oficialmente las R600 hace años, así que ha sido la comunidad de código abierto, con ayuda de un modelo de lenguaje, quien ha dado con el origen del problema y lo ha corregido en las Radeon HD 2000 y HD 3000.
El origen del fallo con los drivers en Linux
El problema aparecía cuando el decodificador UVD leía vídeo comprimido desde la memoria del sistema mientras la GPU dibujaba gráficos al mismo tiempo: esa lectura simultánea corrompía los fotogramas. Mover la entrada de datos a la VRAM, la memoria propia de la tarjeta, resolvía el fallo por completo, y desactivar el dibujado gráfico también detenía la corrupción, lo que confirmaba dónde estaba el conflicto.
La solución final mantiene los búferes UVD en la VRAM para toda esta familia de chips, tal y como el controlador ya hace con otros modelos más recientes. El parche cubre cinco GPU concretas, RV610, RV620, RV630, RV635 y RV670, todas con la misma ruta de decodificador RV6xx y el firmware heredado de la era R600. Son las gráficas que equiparon los portátiles y sobremesas con Radeon HD 2000 y 3000 hace casi dos décadas, y que AMD lleva mucho tiempo sin tocar en sus propios laboratorios.
Cómo se descubrió el fallo con ayuda de Codex
El autor del parche es Ted Bullock, un colaborador que se incorpora ahora al desarrollo del controlador de código abierto de AMD. Topó con la corrupción de vídeo en su propio equipo, un iMac7,1 equipado con una GPU RV610/M74 (identificador de dispositivo 1002:94c8), y decidió investigar el origen del fallo usando OpenAI Codex como asistente durante todo el proceso.
En el texto que acompaña a su propuesta, explica: «Investigué la corrupción de vídeo en mi antiguo iMac7,1 (RV610/M74, ID de dispositivo 1002:94c8). Cuando el decodificador leía vídeo comprimido desde la memoria del sistema mientras la GPU estaba dibujando, corrompía los fotogramas de vídeo. Mover la entrada a la VRAM permitió que los fotogramas se decodificaran correctamente».
Sobre su método de trabajo, añade: «Usé Codex para ayudar con la investigación, las pruebas y el parche». Nos parece revelador que la IA aparezca aquí como herramienta de apoyo y no como protagonista: el mérito del hallazgo y de la verificación sigue siendo de quien firma el parche.
El parche ya está camino del kernel Linux 7.5
AMD envió el lote de parches gráficos y de cómputo el 12 de noviembre de 2026, según recogió Phoronix. La corrección de Bullock figura entre ellos y queda camino de la ventana de integración de Linux 7.5, que se abrirá a finales de año. Es la vía habitual por la que el trabajo de un colaborador externo acaba convertido en código oficial del controlador amdgpu/radeon que mantiene el propio kernel.
Eso no significa que el arreglo llegue de inmediato a cualquier distribución. Hará falta que el núcleo 7.5 se publique en su versión estable y que cada distribución lo incorpore después a sus propios repositorios. Las de lanzamiento continuo, como Arch Linux u openSUSE Tumbleweed, suelen recibir estos cambios en cuanto el kernel queda empaquetado; las de soporte extendido tendrán que esperar a su siguiente actualización mayor para heredar un arreglo que llevaba pendiente casi veinte años. Si administráis alguno de estos equipos, podéis seguir el avance del parche en el propio repositorio del kernel antes de que llegue a vuestra distribución.
Qué más trae el envío de controladores de AMD para Linux
El mismo pull request incluye una lista larga de cambios pensados para hardware mucho más reciente, repartidos entre varios subsistemas del núcleo. Os dejamos los bloques principales para que veáis dónde se concentra el trabajo de AMD esta semana:
- amdgpu: correcciones en VCE, GC 11.0.2, SMU 15, manejo de reinicios de GPU, VRR/FreeSync, HDR y HDMI 2.x, además de actualizaciones de UALink, RAS y SR-IOV.
- amdkfd: arreglos en SVM y CRIU, y soporte para topologías NUMA discontinuas y sin CPU.
- drm: compatibilidad con EDID para las tasas HDMI 2.2 FRL.
- radeon: comprobación de límites en ATRM, además del propio arreglo de UVD.
Phoronix destaca que el envío no incluye los parches de la nueva generación AMD GFX13 (RDNA5). Según las versiones que circulan en el sector, podrían llegar en el pull request de la semana siguiente, aunque AMD no lo ha confirmado. Esa acumulación de cambios da una idea de la escala del trabajo que hace AMD cada semana en el núcleo, frente a la rareza que supone encontrar, en medio de todo ese volumen, un arreglo para hardware de hace veinte años.
A quién beneficia la solución que se acaba de descubrir
El parche beneficia sobre todo a quien mantiene vivo un equipo con gráfica RV6xx, ya sea un PC de la época o un Mac como el iMac7,1 de Bullock, bajo alguna distribución Linux. Para ese hardware, la corrección supone volver a ver vídeo sin los artefactos que durante años habían hecho casi inservible la reproducción multimedia en el escritorio. Es una familia de gráficas que muchos recordaréis de portátiles y sobremesas de mediados de la década de 2000, y que algunos seguís usando en equipos de repuesto o en proyectos de recuperación de hardware antiguo.
El propio Bullock deja claro en su propuesta que la verificación no está cerrada: solo probó el parche en el RV610/M74 de su iMac7,1 bajo Debian, y pide que alguien con un RV620, RV630, RV635 o RV670 confirme que el comportamiento es el mismo en esos otros chips. Si tenéis alguno de estos modelos a mano, podéis comprobarlo vosotros mismos cuando el parche llegue a vuestro kernel y dejar constancia en el hilo de desarrollo: es exactamente la verificación que falta para dar el caso por cerrado en toda la familia R600.