El mod FSR 4 para AMD BC-250 reduce a la mitad el tiempo de escalado, pero la verdadera prueba es el juego

El procesamiento de AMD BC-250 FSR 4 se ha vuelto notablemente más rápido, según benchmarks publicados junto con una DLL de FidelityFX desarrollada por la comunidad. A 1440p, el coste de escalado reportado cayó de 11,51 milisegundos a 5,92 milisegundos. Esa reducción transforma FSR 4 de un experimento costoso en una opción más plausible para esta inusual placa basada en RDNA.

El resultado importa porque la BC-250 nunca fue diseñada como un PC gaming convencional. AMD fabricó su procesador semipersonalizado para sistemas de minería de ASRock, utilizando silicio estrechamente relacionado con el procesador de PlayStation 5. Posteriormente, entusiastas de Linux reutilizaron placas descartadas para convertirlas en máquinas gaming compactas mediante firmware personalizado, controladores, refrigeración y herramientas de instalación.

El nuevo lanzamiento desplaza el problema central de la compatibilidad básica al rendimiento práctico. Los trabajos de optimización anteriores dependían de una pila gráfica Mesa modificada. La implementación más reciente integra sus cambios en una biblioteca portátil de FidelityFX que los usuarios pueden instalar junto a herramientas como OptiScaler y Proton.

Sin embargo, las cifras reportadas miden el propio escalador, no el rendimiento completo de los juegos. El desarrollador ha publicado mediciones sintéticas de RC9, mientras que las nuevas pruebas de juego siguen siendo limitadas. El logro es suficientemente real como para analizarlo, pero su valor aún depende de la estabilidad, la calidad de imagen y los resultados en juegos reales.

El procesamiento FSR 4 de AMD BC-250 se reduce en tres resoluciones

La versión RC9 reduce aproximadamente a la mitad el coste medido de FSR 4.1.1 a 1080p, 1440p y 4K.

El resultado más importante procede de una salida de 2560 x 1440 utilizando una entrada Quality de 1706 x 960. Según se informa, los shaders originales de FSR 4.1.1 requerían 11,51 milisegundos para el despacho de escalado completo. La versión 4.0.0-rc9 completó la misma carga de trabajo medida en 5,92 milisegundos.

Eso representa una reducción de alrededor del 49 por ciento. También devuelve casi 5,6 milisegundos al resto de la cadena de renderizado. Esa diferencia es considerable cuando un juego que apunta a 60 fotogramas por segundo dispone de solo 16,67 milisegundos para cada fotograma.

Las otras resoluciones registradas siguen el mismo patrón. A 1920 x 1080, el tiempo de procesamiento bajó de 7,13 milisegundos a 3,93 milisegundos. A 3840 x 2160, descendió de 25,72 milisegundos a 12,08 milisegundos.

Esos resultados equivalen a reducciones de aproximadamente el 45 por ciento y el 53 por ciento, respectivamente. Por tanto, la mejora no parece limitarse a un único tamaño de salida. El ahorro absoluto aumenta a medida que crece la resolución de salida y el escalador procesa más píxeles.

La versión RC9 del desarrollador incluye el código optimizado como amd_fidelityfx_upscaler_dx12.dll. Esta biblioteca actúa como proveedor de escalado FidelityFX dentro de las rutas de integración compatibles. Sustituye el componente de escalado relevante sin requerir la anterior compilación personalizada de Mesa.

Según el resumen de pruebas publicado, estas cifras representan costes aislados del despacho de FSR. No son mediciones del tiempo de fotograma completo ni del rendimiento medio en juegos. El trabajo de CPU, el renderizado del juego, la compilación de shaders, las capas de traducción y la sincronización de pantalla quedan fuera de la medición.

Esa distinción impide convertir directamente los milisegundos ahorrados en fotogramas ganados. Un juego limitado por su CPU podría mostrar poca mejora. Un juego muy limitado por GPU podría beneficiarse más, especialmente cuando el pase de escalado anterior consumía una gran parte del presupuesto de fotograma.

Aun así, las cifras abordan un obstáculo concreto. Ejecutar FSR 4 en la BC-250 ya era técnicamente posible antes de RC9, pero el escalador podía consumir la mayor parte del presupuesto de un fotograma a alta frecuencia. Reducir esa carga casi a la mitad hace que merezca la pena realizar pruebas más amplias.

Por tanto, el lanzamiento cambia la pregunta. La comunidad ya no necesita preguntar únicamente si FSR 4 puede ejecutarse en la placa. Ahora puede preguntarse si la ruta optimizada mejora suficientemente la experiencia de juego completa como para justificar su instalación.

Una DLL portátil de FidelityFX sustituye la ruta de Mesa personalizada

El avance central es la portabilidad, porque la optimización ahora acompaña al escalador en lugar de depender de un controlador gráfico especializado.

La optimización original de la BC-250 se dirigía a Mesa, la pila gráfica de código abierto utilizada habitualmente por sistemas Linux. Modificaba el manejo del controlador Vulkan RADV de las operaciones INT8 usadas por FSR 4. INT8 se refiere a la aritmética de enteros de ocho bits, que los modelos de aprendizaje automático utilizan para reducir los costes de procesamiento y memoria.

Ese trabajo abordaba una limitación inusual del procesador gráfico GFX1013 de la BC-250. La placa puede ejecutar la carga de trabajo requerida, pero su ruta de producto punto de enteros empaquetados con signo ofrece un rendimiento deficiente. Un producto punto combina múltiples multiplicaciones y sumas, por lo que es una operación común en los modelos neuronales de procesamiento de imagen.

El proyecto anterior sustituyó esa ruta costosa por una secuencia más adecuada para la BC-250. Su repositorio describe una compilación experimental de Mesa que utiliza instrucciones enteras alternativas en lugar de depender de la problemática ruta nativa. La modificación se dirigía a un identificador de dispositivo y un conjunto de shaders validados específicos.

Ese enfoque demostró la oportunidad de rendimiento, pero situó el despliegue dentro de la pila de controladores. Los usuarios necesitaban una compilación dedicada de Mesa y debían iniciar los juegos mediante la configuración Vulkan correcta. Las modificaciones del controlador también conllevan costes de mantenimiento cuando cambian Mesa, Proton o una distribución Linux.

La implementación portátil traslada la optimización a la DLL de FidelityFX. Eso convierte al escalador en un componente sustituible, en vez de una variación de controlador para todo el sistema. Los usuarios pueden colocar la biblioteca en una configuración de juego o adaptador compatible y eliminarla sin recompilar Mesa.

La guía de instalación del proyecto indica que RC9 no requiere la antigua herramienta de compatibilidad ni una instalación especial de controladores. Su alcance probado se limita al hardware BC-250 ejecutando Linux mediante Proton convencional. Proton es la capa de compatibilidad de Valve para ejecutar juegos de Windows en Linux.

OptiScaler puede actuar como adaptador entre un juego y la biblioteca FidelityFX. Intercepta una ruta de escalado disponible y después proporciona el backend seleccionado. El menú de un juego puede seguir mostrando DLSS, FSR o XeSS incluso cuando el proveedor FidelityFX inyectado realiza el escalado final.

Esa disposición ofrece flexibilidad, pero también añade variables de configuración. El juego necesita una entrada temporal compatible, es decir, vectores de movimiento y otros datos de fotograma necesarios para reconstruir una imagen de mayor resolución. La DLL por sí sola no puede añadir esa información a un título que nunca la genera.

Los usuarios también deben verificar que RC9 sea el proveedor activo. El proyecto recomienda activar la marca de agua integrada y comprobar las etiquetas FSR-INT8, 4.1.1R9 y de fuente local. Una suma de comprobación confirma el archivo instalado, mientras que la marca de agua renderizada verifica qué proveedor procesó la imagen.

Esto importa porque varios componentes de escalado pueden coexistir dentro de un prefijo de Proton o un directorio de juego modificado. Las actualizaciones automáticas de controladores, los archivos existentes de OptiScaler y los parches de juegos pueden restaurar silenciosamente otra biblioteca. Un menú funcional no demuestra que el modelo optimizado esté renderizando la escena.

La portabilidad, por tanto, no significa compatibilidad universal. Significa que la optimización se ha trasladado a un paquete más fácil de instalar, verificar, sustituir y revertir. Es una mejora operativa importante para un proyecto comunitario construido alrededor de hardware no compatible oficialmente.

Por qué la BC-250 convierte este resultado en algo más que una curiosidad de modding

El escalador más rápido amplía un esfuerzo mayor para recuperar hardware gaming útil a partir de un producto de minería especializado.

La BC-250 combina una CPU Zen 2 de seis núcleos y 12 hilos con un procesador gráfico integrado GFX1013. Las placas de serie exponen 24 unidades de cálculo e incluyen 16 GB de memoria unificada GDDR6. A diferencia de un equipo de escritorio convencional, el sistema no depende de módulos de memoria DDR independientes.

La documentación de hardware de la comunidad describe la placa como un diseño personalizado para minería con un factor de forma no estándar. El hardware de codificación y decodificación de vídeo no está disponible, y las cajas o disipadores convencionales de PC no encajan sin adaptación. La conectividad de almacenamiento también es más limitada que en una placa base normal.

El procesador procede de la misma familia amplia de silicio semipersonalizado asociada con la PlayStation 5 de Sony. Sin embargo, llamar a la BC-250 una PS5 de escritorio exageraría la relación. Sus núcleos de CPU habilitados, configuración gráfica, firmware, E/S y entorno operativo difieren de los de la consola.

La placa llegó al mercado de entusiastas después de que la demanda de minería de criptomonedas se debilitara. Los modders desarrollaron entonces parches de firmware, soporte de controladores Linux, controles de ventilador, carcasas y distribuciones centradas en gaming. Cada mejora eliminó una limitación de un hardware que carecía de un canal normal de soporte para consumidores.

Los proyectos anteriores demostraron que la configuración de serie podía ejecutar exigentes juegos de PC mediante Linux. Más tarde, miembros de la comunidad experimentaron con la restauración de núcleos de CPU desactivados y la exposición de más unidades físicas de cálculo gráfico en procesadores compatibles. Esas modificaciones dependen del chip y no funcionan en todas las placas.

FSR 4 añade otra capa a ese esfuerzo de recuperación. El actual SDK de FSR de AMD combina datos espaciales y temporales con modelos de aprendizaje automático para reconstruir fotogramas de mayor resolución. Se dirige a plataformas gráficas más nuevas mediante implementaciones compatibles oficialmente, mientras que el soporte para BC-250 procede de ingeniería comunitaria.

La tensión es evidente. FSR 4 promete una calidad de imagen reconstruida superior a la de los escaladores anteriores, pero su modelo conlleva un coste de procesamiento significativo. En una placa limitada, el escalador puede eliminar el rendimiento obtenido al renderizar a una resolución de entrada inferior.

A 1440p, el coste original de 11,51 milisegundos consumía alrededor del 69 por ciento del presupuesto de un fotograma a 60 fps. Ese cálculo cubre únicamente el despacho de FSR. El juego aún necesitaba tiempo para geometría, iluminación, efectos, simulación de CPU, trabajo del controlador y presentación final.

RC9 reduce esa proporción a aproximadamente el 36 por ciento. La nueva cifra sigue siendo costosa, pero deja mucho más margen para el juego propiamente dicho. A 4K, la reducción de 25,72 milisegundos a 12,08 milisegundos sitúa al escalador por debajo del presupuesto completo de un fotograma a 60 fps.

Eso no hace probable jugar a 4K y 60 fps en la BC-250. El resto de la carga de trabajo aún necesita tiempo de procesamiento y el rendimiento gráfico de la placa sigue siendo limitado. Sí demuestra por qué optimizar el escalador importa más que simplemente conseguir que se inicie.

El proyecto AMD BC-250 FSR 4 también ilustra el valor de los componentes abiertos de Linux. Los desarrolladores pudieron inspeccionar el comportamiento de los shaders, identificar la ruta de instrucciones costosa, probar alternativas y empaquetar el resultado. Ese proceso sería más difícil dentro de una cadena de controladores y aplicaciones totalmente cerrada.

Sin embargo, el proyecto depende en parte de ingeniería inversa e integración de terceros. AMD no ha presentado RC9 como una versión oficial para BC-250. Los usuarios deben tratar la DLL como software experimental para un dispositivo de nicho, no como una función compatible oficialmente de los controladores Radeon.

El verdadero rival es la compatibilidad sin rendimiento práctico

RC9 cuestiona la distancia entre hacer que FSR 4 funcione y lograr que sea útil dentro de un fotograma completo de juego.

Las demostraciones de compatibilidad suelen producir capturas de pantalla convincentes. Una función se carga, aparece una marca de agua y el hardware renderiza una imagen que su proveedor nunca admitió oficialmente. Eso demuestra acceso técnico, pero dice poco sobre la latencia, la estabilidad o la experiencia de juego sostenida.

El BC-250 ya había superado el umbral de compatibilidad. Trabajos previos de la comunidad mostraron que FSR 4.1.1 podía ejecutarse mediante la pila gráfica de Linux de la placa. El problema era el tiempo que consumían sus sombreadores de aprendizaje automático, especialmente las operaciones de enteros empaquetados con signo.

A 1440p, un pase de escalado de 11,51 milisegundos genera una presión considerable sobre cualquier objetivo de rendimiento. Un fotograma a 30 fps permite 33,33 milisegundos, lo que facilita absorber esa sobrecarga. Un objetivo de 60 fps permite la mitad de ese tiempo, mientras que 120 fps solo permite 8,33 milisegundos.

El resultado de 5,92 milisegundos de RC9 cabe por sí solo dentro del presupuesto de un fotograma a 120 fps. Evidentemente, el juego completo no cabe una vez que se incluye todo el resto del trabajo. Aun así, el envío optimizado ya no supera todo ese presupuesto antes de que el juego renderice nada más.

Esta es la inversión fundamental detrás del proyecto. FSR normalmente mejora el rendimiento al permitir que un juego renderice menos píxeles. En la ruta no optimizada del BC-250, el proceso de reconstrucción podía consumir gran parte del tiempo ahorrado. La solución de la función corría el riesgo de convertirse en otro cuello de botella.

La DLL optimizada reduce esa contradicción. No elimina el coste, pero acorta la distancia entre el soporte teórico y el rendimiento utilizable. Esto da a desarrolladores y usuarios mayor libertad para comparar FSR 4 con FSR 3, XeSS o una resolución nativa inferior.

Estas comparaciones requieren controles cuidadosos. Cada escalador utiliza una lógica de reconstrucción distinta y puede ofrecer diferentes modos de calidad. Un ajuste de Calidad en una implementación no coincide necesariamente con la resolución de entrada, la nitidez o el comportamiento visual de otra.

La calidad de imagen también importa más que el tiempo de envío por sí solo. Un sombreador más rápido aporta poco valor si introduce inestabilidad, imágenes fantasma, parpadeos, errores de desoclusión o elementos de interfaz dañados. Estos problemas suelen aparecer durante el movimiento, no en capturas estáticas.

El mismo problema se aplica a las tasas medias de fotogramas. Un benchmark puede mostrar una media superior mientras sufre una entrega irregular de fotogramas. Los percentiles de tiempo de fotograma y los tirones visibles suelen determinar si un juego realmente se percibe como mejorado.

Por tanto, RC9 debe competir con opciones más sencillas. Los usuarios pueden elegir una implementación anterior de FSR que cueste menos, reducir los ajustes nativos o aceptar una tasa de fotogramas inferior. La ruta optimizada de FSR 4 solo gana cuando su mejora de calidad de imagen justifica su sobrecarga restante y la complejidad de instalación.

El proyecto no necesita superar a todas las alternativas. Una herramienta comunitaria puede ser valiosa si mejora unos pocos juegos exigentes en un dispositivo concreto. Sin embargo, ese estándar más limitado debe seguir siendo explícito al interpretar el benchmark.

Por eso la DLL portátil importa tanto como la cifra principal. Una instalación más sencilla reduce el coste de realizar comparaciones reales. Más usuarios pueden probar el mismo binario, comunicar resultados reproducibles e identificar los títulos en los que la compensación funciona.

Lo que el benchmark aún no establece

Los datos publicados muestran un envío de escalado más rápido, pero todavía no establecen una calidad visual equivalente ni ganancias predecibles entre juegos.

La primera incertidumbre es el alcance de las pruebas. La documentación del proyecto indica que sus siete comprobaciones registradas en juegos utilizaron una compilación RC7 anterior. RC9 cuenta con validación sintética y una configuración instalada de Cyberpunk 2077, pero la guía no afirma haber realizado una nueva ronda de juego con RC9 en todos los títulos.

Esa brecha no invalida el benchmark. Las pruebas sintéticas aíslan el escalador y facilitan las comparaciones de antes y después. Simplemente responden a una pregunta más limitada que un benchmark en un juego.

Una evaluación completa necesita tasas medias de fotogramas, resultados del uno por ciento más bajo y gráficos de tiempo de fotograma procedentes de escenas repetibles. También debería comparar resoluciones de entrada y salida idénticas. Sin esos controles, la variación de la CPU o cambios de renderizado no relacionados pueden ocultar el efecto de la DLL.

La segunda incertidumbre se refiere a la equivalencia visual. El benchmark indica que la ruta optimizada procesa la carga de trabajo más rápido. No establece de forma independiente que cada píxel de salida coincida con la ruta original de AMD ni que el comportamiento temporal permanezca sin cambios durante el juego.

Los escaladores de aprendizaje automático pueden fallar de formas específicas según la escena. La geometría fina puede centellear, los efectos transparentes pueden romperse, las partículas pueden dejar estelas y las superficies recién reveladas pueden mostrar errores de reconstrucción. Los movimientos rápidos de cámara suelen revelar problemas que una captura fija oculta.

La tercera cuestión es la compatibilidad con juegos. OptiScaler ofrece varias rutas de inyección, pero cada juego expone distintas API y datos temporales. Los sistemas antitrampas, los lanzadores, las actualizaciones y los cambios de renderizador pueden impedir que una instalación por lo demás correcta funcione.

Las integraciones nativas de FidelityFX también varían. Un juego documentado requiere una biblioteca de cargador con un nombre específico, mientras que otro utiliza un backend de OptiScaler. El proyecto advierte explícitamente contra aplicar la sustitución de archivos de un título a juegos no relacionados.

La cuarta incertidumbre es el alcance de la plataforma. RC9 está dirigido al hardware BC-250 bajo Linux con Proton. La guía no promete compatibilidad con Windows nativo ni con otras GPU. Una DLL portátil es más fácil de trasladar, pero la portabilidad del archivo no demuestra la portabilidad de su comportamiento optimizado.

La implementación también es software de terceros sin firma. Los usuarios deberían obtenerla de la versión indicada, verificar su suma de comprobación y conservar copias de seguridad de los archivos sustituidos. Las actualizaciones de los juegos pueden sobrescribir la biblioteca o crear incompatibilidades que requieran una reversión.

Las implicaciones más amplias para RDNA 2 siguen siendo especialmente inciertas. El BC-250 utiliza un procesador GFX1013 inusual con un comportamiento de instrucciones específico. Una solución alternativa que ayuda a este dispositivo no puede predecir automáticamente el rendimiento en tarjetas Radeon RX 6000, hardware Steam Deck o procesadores de consola.

El benchmark reportado también surge de un pequeño ecosistema de modding. La reproducción independiente debería confirmar las cifras en distintas placas, frecuencias, versiones de firmware y condiciones térmicas.

Las temperaturas merecen atención porque las cargas sostenidas de sombreadores pueden comportarse de forma distinta a las pruebas breves. Una placa con refrigeración insuficiente puede reducir las frecuencias tras jugar durante un periodo prolongado. Eso podría reducir u ocultar el beneficio de rendimiento observado durante una ejecución sintética breve.

La variación entre placas añade otra complicación. Algunos procesadores BC-250 toleran núcleos o unidades de cálculo desbloqueados, mientras que otros solo se mantienen estables en su configuración de fábrica. Los benchmarks deben identificar claramente el hardware habilitado, las frecuencias, los límites de potencia, el firmware, la versión de Mesa y la compilación de Proton.

Ninguna de estas limitaciones elimina la reducción reportada. Definen lo que las pruebas actuales respaldan. RC9 parece hacer que el envío de FSR sea sustancialmente más rápido en su sistema objetivo, mientras que el valor en juegos completos sigue siendo una afirmación comprobable.

Esta lectura cautelosa sirve mejor al proyecto que tratar el resultado como soporte universal para FSR 4. Los límites claros ayudan a los usuarios a reproducir el trabajo y a los desarrolladores a identificar qué problemas aún requieren ingeniería.

Tres señales mostrarán si RC9 transforma los juegos en BC-250

La siguiente fase debe conectar la eficiencia sintética con una experiencia de juego reproducible, estabilidad visual y distribución mantenible.

La primera señal es una suite controlada de benchmarks de juegos con RC9. Cyberpunk 2077 y Control son puntos de partida razonables porque el proyecto ya documenta rutas de instalación para ambos. Las pruebas deberían comparar los sombreadores originales, RC9 y un escalador anterior con ajustes idénticos.

Los informes más útiles incluirán el rendimiento medio y los percentiles de tiempo de fotograma. Deberían registrar el tiempo de fotograma completo junto al coste aislado de FSR. Si RC9 produce ganancias consistentes en escenas limitadas por la GPU, la conclusión actual basada en el mecanismo se volverá mucho más sólida.

Si el rendimiento del juego completo apenas cambia, el benchmark aún enseñará algo a los desarrolladores. Indicaría que otra parte de la canalización de renderizado domina. La optimización podría seguir siendo técnicamente eficaz sin mejorar de forma material un juego concreto.

La segunda señal es la validación independiente de la calidad de imagen. Los usuarios deberían capturar movimiento, geometría fina, partículas, reflejos, elementos de interfaz y superficies desocluidas. Las comparaciones necesitan trayectorias de cámara y resoluciones de entrada idénticas, en lugar de capturas no relacionadas.

Una coincidencia estable con la salida original reforzaría la afirmación de que RC9 ofrece casi la misma reconstrucción a un coste mucho menor. Las imágenes fantasma o los parpadeos recurrentes debilitarían su caso práctico, aunque se mantenga la ventaja de tiempos.

La tercera señal es la adopción mediante paquetes de Linux y herramientas de instalación mantenidos. La DLL ya reduce la dependencia de una compilación personalizada de Mesa. La integración continuada en distribuciones para BC-250, flujos de trabajo de Proton y paquetes con suma de comprobación fijada haría las pruebas más reproducibles.

Un proyecto de Linux ya presenta la bifurcación como una opción experimental de OptiScaler, al tiempo que advierte que las compilaciones sin firma no constituyen recomendaciones. Ese enfoque es apropiado. El empaquetado reproducible puede hacer más seguro el software experimental sin convertirlo en soporte oficial.

El mantenimiento tras las actualizaciones de juegos, Proton y controladores revelará si la portabilidad resiste el uso real. Una biblioteca de sustitución que se rompe con frecuencia impone un coste oculto. Un paquete estable con instrucciones claras de reversión convertiría la optimización en infraestructura práctica.

La respuesta de AMD es menos importante a corto plazo, pero sigue mereciendo atención el soporte oficial. La compañía controla el desarrollo de FSR y las rutas compatibles de Radeon. Los descubrimientos de la comunidad pueden revelar demanda, pero no garantizan que AMD admita este procesador derivado de minería.

Para los propietarios de BC-250, el siguiente paso sensato es la experimentación medida. Verifiquen el archivo de la versión, preserven las bibliotecas originales, confirmen la marca de agua renderizada y hagan un benchmark de una escena repetible. Comparen el comportamiento visual antes de decidir si la sobrecarga restante merece la pena.

Para los desarrolladores gráficos, el proyecto ofrece una lección más amplia sobre las suposiciones de software. Un modelo diseñado en torno a hardware de enteros más reciente puede comportarse mal en un procesador inusual, incluso cuando ese procesador ejecuta las instrucciones necesarias. El trabajo específico sobre sombreadores puede recuperar rendimiento que una ruta genérica deja sin aprovechar.

Por tanto, el resultado de AMD BC-250 con FSR 4 es prometedor por una razón precisa. Convierte un experimento especializado de controlador en un paquete portátil y reduce casi a la mitad la carga de trabajo medida. No establece compatibilidad universal ni ganancias garantizadas de tasa de fotogramas.

La prueba decisiva debería llegar de juegos normales, no de otra cifra aislada. ¿Mejora RC9 la regularidad de los fotogramas durante escenas exigentes mientras preserva detalles reconstruidos estables? Las respuestas reproducibles a esa pregunta determinarán si esta DLL se convierte en una parte duradera de los juegos en BC-250 o sigue siendo una impresionante demostración técnica.