- AMD publicó por error el código de FSR 4 en GitHub bajo licencia MIT y lo retiró rápidamente, pero ya había sido replicado.
- El repositorio incluía modelos INT8 que apuntan a pruebas para compatibilidad con RDNA 3, pese a que el soporte oficial es para RDNA 4.
- El nuevo FidelityFX SDK 2.0 distribuye FSR 4 en DLL firmadas y permitirá actualizaciones vía drivers Adrenalin, similar al override global de DLSS.
- FSR 4 es un upscaler basado en aprendizaje automático con mejoras en nitidez, estabilidad temporal y ghosting; las GPU anteriores caen a FSR 3.1.5.
Un desliz en GitHub ha puesto a FSR 4 en el centro de todas las miradas: AMD subió por error el código fuente completo a su repositorio de GPUOpen y, aunque lo retiró poco después, para entonces ya circulaban copias y forks. El detalle no es menor: la publicación se realizó bajo licencia MIT, lo que da pie a un escenario inédito para esta tecnología.
Más allá del susto, el material filtrado ofrece pistas relevantes sobre la hoja de ruta del fabricante. Entre los hallazgos destacan referencias a modelos INT8 que sugieren pruebas con hardware anterior, mientras que el lanzamiento oficial del SDK desembarca con un modelo de distribución más controlado basado en DLL firmadas.
Qué ha pasado: el desliz en GitHub
La semana del lanzamiento del FidelityFX SDK 2.0 en GPUOpen, AMD incluyó soporte para FSR 4 y FSR 3.1.5 en su repositorio. En ese proceso, el equipo publicó por error la implementación completa del upscaler y no solo los componentes necesarios para integrarlo. El contenido apareció con licencia MIT y fue retirado al poco tiempo, pero los commits, capturas y forks ya habían asegurado su permanencia.
La compañía confirmó que la publicación fue accidental y sustituyó el material por el SDK habitual, dejando rastro en el historial del repositorio con referencias a archivos eliminados. A efectos prácticos, el código quedó diseminado entre terceros, algo difícil de revertir cuando se trata de un repositorio público.
Para desarrolladores y entusiastas, el incidente ha supuesto una ventana poco común al interior de FSR 4. Para la competencia, ofrece una visión de enfoques y técnicas; aun así, no parece que vaya a proporcionar una ventaja inmediata, dado que la ejecución y el entrenamiento del modelo siguen requiriendo hardware y pipelines específicos.
En paralelo, AMD anunció que la rama oficial continúa mediante el SDK 2.0 con bibliotecas de FSR 4 disponibles de forma binaria, y que la evolución de la plataforma seguirá su curso con nuevas funciones y optimizaciones bajo un marco más cerrado y certificado.
Qué revela el código: modelos INT8 y soporte potencial
Entre las rutas y carpetas filtradas aparecían elementos con sufijos como “i8”, interpretados por la comunidad como variantes en precisión INT8. Esto sugiere que AMD, al menos en fase de pruebas internas, exploró la viabilidad de FSR 4 en GPUs con RDNA 3, por ejemplo familias como la RX 7800 XT, cuyos aceleradores de IA son más modestos que los de RDNA 4.
De forma oficial, FSR 4 se apoya en FP8 (y FP32 en partes del pipeline), algo que encaja con las unidades de IA de RDNA 4. La presencia de modelos INT8 en el código indica experimentos para reducir coste computacional a cambio de precisión, pero no equivale a una promesa de soporte. Es decir, el rastro técnico apunta a pruebas reales, mientras que la compatibilidad no está confirmada.
Ya se habían visto intentos de la comunidad por hacer funcionar FSR 4 fuera de su target, con “hacks” en FP16 que eran operativos pero penalizaban en exceso el rendimiento. En ese contexto, una variante INT8 podría ofrecer un equilibrio mejor para RDNA 3, si bien la calidad final dependería de entrenamiento específico y optimizaciones del runtime.
AMD había deslizado en el pasado que estudiaba opciones para ampliar la compatibilidad, y la filtración encaja con esa narrativa. Aun así, el hecho de que las rutas existan en el repo no implica que el fabricante vaya a publicar oficialmente una versión para hardware anterior.
Cambio de estrategia: SDK 2.0, DLL firmadas y drivers
El paquete actualizado del FidelityFX SDK 2.0 ofrece FSR 4 mediante DLL firmadas (con un cargador tipo amd_fidelityfx_loader.dll), dejando atrás el enfoque más abierto de iteraciones previas. Con este modelo, AMD puede empujar actualizaciones de las bibliotecas a través de los drivers Adrenalin, en línea con el override global de DLSS que popularizó Nvidia.
Para los estudios, este sistema acelera la adopción y el mantenimiento: quien ya integró FSR 3.1 puede migrar con menos fricción a FSR 4, y hay plugin para Unreal Engine (UE 5.1–5.6) que simplifica la integración. En tarjetas no compatibles, el SDK aplica un fallback a FSR 3.1.5 de forma automática.
El soporte oficial de FSR 4 se limita a Radeon con RDNA 4 bajo Windows 10/11 y DirectX 12. Además, la rama pública enumera mejoras en estabilidad y correcciones, con FSR 4 en la versión 4.0.2 dentro del SDK 2.0, y mantiene en paralelo el frame generation de FSR 3.1.5.
En lo técnico, FSR 4 es el primer upscaler de AMD con aprendizaje automático: modelos entrenados con datos de juego y acelerados en Instinct, con el objetivo de ofrecer más detalle, menos ghosting y una temporalidad más estable que FSR 3.1. El salto cualitativo existe, pero con un acceso más restringido que en generaciones previas.
Impacto y reacciones: legalidad, comunidad y mercado
La publicación accidental bajo licencia MIT es clave: esa licencia es permisiva e irrevocable, de modo que quienes obtuvieron el código durante la ventana pública conservarían derechos de uso, copia y modificación, con independencia de su retirada posterior del repositorio.
En la comunidad, el movimiento ha reavivado el debate entre apertura y control. Es probable que veamos mods y pruebas para activar FSR 4 en RDNA 3, aunque sin garantías de calidad ni rendimiento frente a una implementación oficial. AMD, por su parte, ha marcado el rumbo con un SDK más cerrado y actualizaciones centralizadas.
En el frente tecnológico, la hoja de ruta sigue apuntando a FSR Redstone, una actualización mayor que traerá Neural Radiance Caching, mejoras de ray regeneration asistidas por ML y un modelo renovado de frame generation para recortar distancias con alternativas rivales.
El mercado acusó el golpe con tibias caídas en el valor de AMD tras conocerse el error, una reacción lógica ante el riesgo de exposición de técnicas y el giro estratégico de distribución. Aun así, no hay indicios claros de que la competencia vaya a capitalizar a corto plazo este desliz.
La fotografía actual deja un mensaje claro: FSR 4 avanza como salto tecnológico pero con una política de acceso más cerrada; la filtración ha evidenciado que hubo experimentos para ampliar compatibilidad, mientras el SDK oficial consolida un modelo binario con actualizaciones vía drivers y soporte preferente para RDNA 4.