DLSS 5 en AMD ya funciona en tres generaciones de Radeon, pero la brecha de hardware persiste
Daniel Blanco ha ampliado DLSS 5 en AMD, pasando de un único efecto experimental a una suite gráfica de cuatro partes que abarca tres generaciones de Radeon. La versión Alpha 0.8.0 del 17 de octubre añade DLSS Frame Generation a una colección existente que incluye Super Resolution, Ray Reconstruction y Neural Rendering.
Supone un cambio significativo para unas funciones comercializadas en torno al hardware RTX de Nvidia. El proyecto DLSS-NR-on-AMD de Blanco ahora se dirige a las tarjetas Radeon RX 9000, RX 7000 y RX 6000, aunque el soporte difiere según la arquitectura. También convierte las tecnologías independientes de Nvidia en módulos seleccionables dentro de un único gestor.
El logro técnico no elimina la división de hardware. El proyecto sigue siendo no oficial, varios resultados proceden de pruebas del desarrollador y los primeros ensayos independientes han revelado bloqueos o graves pérdidas de rendimiento. Nvidia sigue controlando los modelos originales, el hardware compatible y las integraciones en juegos.
Lo que ha cambiado es el acceso. Los propietarios de Radeon ahora pueden experimentar con casi todos los componentes principales de DLSS mediante un único marco, incluso cuando las alternativas oficiales de AMD tienen un soporte más limitado de hardware o juegos. El debate ha pasado de si estas funciones pueden ejecutarse en Radeon a si funcionan lo suficientemente bien como para importar.
DLSS 5 en AMD se convierte en una suite gráfica completa
Alpha 0.8.0 transforma DLSS-NR-on-AMD de un experimento de Neural Rendering en un paquete modular que cubre las principales funciones DLSS de Nvidia.
Blanco lanzó por primera vez el proyecto el 3 de septiembre, el mismo día que Nvidia puso DLSS 5 a disposición en NBA 2K27. Su propósito original era más limitado: ejecutar el nuevo modelo Neural Rendering de Nvidia en hardware AMD mediante un tiempo de ejecución de redes neuronales específico para Radeon.
Neural Rendering es el componente inusual. Nvidia lo describe como una etapa final de renderizado que utiliza un modelo generativo para mejorar la iluminación, la piel, los materiales, los reflejos y otros detalles visuales. A diferencia del escalado convencional, modifica la apariencia final en lugar de limitarse a reconstruir un fotograma de mayor resolución.
La actualización de octubre de Blanco añade las tecnologías circundantes necesarias para construir una canalización DLSS más amplia. Según las notas de la versión 0.8.0 del proyecto, el paquete ahora incluye DLSS Super Resolution 4.5, DLSS Ray Reconstruction, DLSS Frame Generation y Neural Rendering.
Super Resolution reconstruye una imagen de mayor resolución a partir de una entrada de menor resolución. Ray Reconstruction sustituye varios reductores de ruido ajustados manualmente por un modelo entrenado que reconstruye detalles con trazado de rayos. Frame Generation crea fotogramas adicionales entre los renderizados de forma convencional.
La versión 0.8.0 admite hasta 4X Multi Frame Generation cuando un juego proporciona las entradas necesarias para DLSS Frame Generation. La denominación significa que la canalización puede mostrar hasta cuatro fotogramas por cada fotograma renderizado convencionalmente, incluida la salida generada.
La actualización también acepta los archivos Neural Rendering 310.9.16 de Nvidia e incorpora el escalado FSR 4.1.1. Incluir una versión de FSR proporciona al mod una base coherente en lugar de depender de la implementación concreta distribuida con cada juego o controlador.
Blanco agrupa estas funciones dentro de lo que denomina un Neural Rendering Supermod. Los usuarios pueden elegir módulos mediante una superposición en lugar de instalar una solución alternativa distinta para cada función. El gestor NeuralHub del proyecto analiza los juegos, instala el cargador, centraliza los archivos de modelos grandes y mantiene actualizados los componentes instalados.
El gestor importa porque el proceso de instalación anterior exigía más manipulación manual de archivos. Los usuarios tenían que colocar bibliotecas en directorios de juegos individuales y resolver problemas en cada título por separado. NeuralHub reduce esa fricción, aunque no convierte el proyecto en una función compatible con controladores oficiales.
Un juego compatible debe usar DirectX 12 y exponer entradas de FSR, DLSS o Intel XeSS. Tras instalar el cargador, el jugador habilita una de esas tecnologías en el juego. El mod intercepta esa canalización y dirige las entradas disponibles a través de los módulos de salida seleccionados.
Los usuarios deben proporcionar sus propios archivos DLL de Nvidia para las funciones DLSS pertinentes. FSR viene incluido con el gestor, pero las bibliotecas de Nvidia no. Este requisito mantiene el proyecto dependiente de archivos distribuidos con juegos compatibles con esas tecnologías.
El soporte de arquitectura también requiere matices. El proyecto afirma que todas las principales funciones DLSS operan en RDNA 4 y RDNA 3, que alimentan las tarjetas Radeon RX 9000 y RX 7000. El soporte para RDNA 2 sigue en pruebas, con Neural Rendering disponible antes de que varios otros módulos lleguen a esa generación.
Esto hace que «tres generaciones» sea preciso a nivel de proyecto, pero no equivale a una paridad completa de funciones en todas las tarjetas compatibles. Los propietarios de Radeon RX 6000 deberían considerar la compatibilidad actual como parcial y en evolución.
La versión añade un modo nativo de DirectX 12 destinado a reducir las pausas asociadas con la interoperabilidad entre los sistemas gráficos y de computación. También incorpora la ejecución DirectX 12 a varias funciones en RDNA 3, junto con cargas más rápidas y optimizaciones generales de red.
No son simples añadidos de menú. Blanco afirma que el tiempo de ejecución es una reimplementación desde cero de la ruta de ejecución de redes neuronales para arquitecturas AMD, incluidos los kernels HIP, las disposiciones de memoria y la integración con juegos. El proyecto afirma que no traduce código de Nvidia durante la ejecución.
Esta distinción explica por qué la actualización representa más que un interruptor de marca. El sistema debe tomar modelos diseñados en torno a la pila de Nvidia y ejecutar sus cargas de trabajo mediante código compatible con Radeon, al tiempo que conserva las entradas esperadas por cada juego.
Por tanto, el nuevo paquete crea la tensión central del artículo. El software ha hecho que la suite de Nvidia sea lo bastante portátil como para ejecutarse en otros entornos, pero una ejecución satisfactoria no equivale a eficiencia nativa, fiabilidad o soporte oficial.
El acceso en Radeon presiona la estrategia de funciones de AMD
El mod presiona a AMD porque revela una demanda de compatibilidad más amplia, incluso cuando Radeon ya cuenta con alternativas para la mayoría de las funciones DLSS.
AMD no parte de una pila gráfica vacía. Su familia FSR cubre el escalado y la generación de fotogramas, mientras que FSR «Redstone» añade Ray Regeneration y Radiance Caching basados en aprendizaje automático. Radeon Anti-Lag 2 aborda la latencia en juegos compatibles.
La brecha reside en una disponibilidad desigual. AMD afirma que su actual suite de funciones FSR depende de los juegos compatibles, las generaciones de Radeon y requisitos específicos de integración. No todas las funciones FSR llegan a todos los propietarios de Radeon por la misma vía.
La colección completa de FSR Redstone se dirige al hardware Radeon RX 9000. AMD enumera el escalado basado en aprendizaje automático para tarjetas RX 7000 y RX 9000, con soporte para RX 6000 previsto para 2027. Las versiones anteriores de FSR cubren más hardware, pero no ofrecen los mismos modelos entrenados.
El proyecto de Blanco aborda esa fragmentación desde otra dirección. Utiliza puntos de integración existentes de FSR, DLSS o XeSS como vías de entrada y, después, permite a los jugadores seleccionar entre varios módulos de Nvidia y AMD reconstruidos.
Esto no significa que el mod sea compatible con todos los juegos DirectX 12. Un título aún necesita una interfaz de escalado adecuada y las entradas requeridas para la función elegida. Ray Reconstruction necesita datos de trazado de rayos, mientras que DLSS Frame Generation necesita una ruta compatible de Frame Generation y actualmente requiere suplantación de GPU.
Aun así, el enfoque amplía el espacio de búsqueda práctico. En lugar de esperar a que un desarrollador añada una función específica de un proveedor, los modders pueden intentar reutilizar información ya disponible en la canalización de renderizado de un juego.
Esto importa porque los jugadores de PC tratan cada vez más la reconstrucción de imagen y los fotogramas generados como parte del valor de una tarjeta gráfica. El rendimiento bruto de rasterización ya no cuenta toda la historia cuando el exigente trazado de rayos puede depender del escalado, la reducción de ruido y la síntesis de fotogramas.
Nvidia ha reforzado esa asociación al empaquetar sus tecnologías bajo DLSS. Un juego con soporte para DLSS puede exponer Super Resolution, Ray Reconstruction y Frame Generation mediante interfaces relacionadas, aunque la elegibilidad de hardware varía según la función.
AMD dispone de herramientas comparables, pero la historia de implementación es menos uniforme. FSR abarca múltiples generaciones y métodos técnicos, desde el escalado espacial hasta la reconstrucción temporal y los modelos de aprendizaje automático. Estas diferencias protegen la compatibilidad amplia, pero también complican las expectativas sobre las funciones.
Por ello, el mod presiona a AMD en alcance de software, más que en un simple recuento de funciones. Radeon ya tiene una respuesta oficial para el escalado, los fotogramas generados y los detalles reconstruidos mediante trazado de rayos. Aún no ofrece una contraparte directa para la etapa generativa de renderizado final de DLSS 5.
La investigación sobre Neural Rendering de Nvidia describe un modelo de difusión de un solo paso, en espacio de píxeles, condicionado por el fotograma actual, los vectores de movimiento, el estado temporal y los controles del desarrollador. La empresa afirma que conserva la estructura creada por los autores mientras añade detalles de apariencia aprendidos.
Ese es un objetivo distinto de reconstruir resolución faltante. DLSS 5 puede sintetizar propiedades visuales que el renderizador convencional no calculó por completo. Nvidia lo presenta como un complemento del renderizado basado en la física, no como un sustituto de los activos del juego o la dirección artística.
Blanco se dirigió inicialmente a esa capacidad ausente porque ninguna función directa de Radeon podía habilitarla. La suite completa llegó después, transformando una solución para una función inexistente en una capa de compatibilidad más amplia.
Esto crea una comparación incómoda para AMD. Un desarrollador independiente está demostrando que el hardware Radeon puede ejecutar cargas de trabajo asociadas con la pila gráfica de Nvidia, incluso si los resultados siguen siendo más lentos y menos fiables.
La implicación no es que AMD deba adoptar la tecnología de Nvidia. Es que los usuarios de Radeon valoran un acceso flexible en más juegos y generaciones de hardware. La popularidad de los cargadores no oficiales refleja una demanda que las listas oficiales de compatibilidad no siempre satisfacen.
El proyecto tenía alrededor de 2.800 estrellas en GitHub cuando fue revisado el 20 de octubre. Esta cifra no demuestra un uso diario generalizado, pero señala una atención significativa para una utilidad alpha que requiere bibliotecas manuales y modificaciones de juegos no compatibles.
Para AMD, la respuesta obligada es a largo plazo. La empresa debe ampliar el soporte de Redstone, mejorar la disponibilidad entre generaciones y animar a los desarrolladores a exponer entradas coherentes. De lo contrario, los proyectos de la comunidad seguirán definiendo lo que el hardware Radeon más antiguo puede intentar.
El port de software no elimina la ventaja de hardware de Nvidia
DLSS 5 en AMD invierte la restricción de acceso, pero no invierte el control de Nvidia sobre los modelos ni su ventaja en hardware ajustado para cargas de trabajo neuronales.
DLSS 5 se dirige oficialmente a las GPU GeForce RTX serie 50. La guía de DLSS 5 de Nvidia de septiembre afirma que la tecnología funciona junto con Super Resolution, Frame Generation, Ray Reconstruction, trazado de rayos y path tracing.
El hardware RTX incluye Tensor Cores dedicados a las operaciones matriciales utilizadas por las redes neuronales. Las arquitecturas Radeon también pueden ejecutar cálculos matriciales, pero su asignación de recursos y los formatos compatibles difieren. Una implementación de software debe trabajar dentro de esas limitaciones arquitectónicas.
Blanco hace precisamente eso al reconstruir la ruta de ejecución para las GPU AMD. Mapea las redes neuronales a kernels HIP y diseños de memoria compatibles con Radeon, en lugar de depender de un runtime nativo de Nvidia.
Ese es el mecanismo detrás del logro y de sus límites. La portabilidad proviene de reimplementar la ejecución, no de otorgar a las tarjetas Radeon un hardware idéntico. Cuanto más se acerque una carga de trabajo a la inferencia neuronal sostenida, más podrán afectar a la velocidad esas diferencias arquitectónicas.
El rendimiento del proyecto ha mejorado rápidamente. Las notas de la versión 0.8.0 afirman una mejora del 25 por ciento en Neural Rendering en RDNA 3. También afirman una ganancia de entre el 6 y el 16 por ciento bajo cargas intensas de juego con DirectX 12, gracias a cambios en la acumulación temporal introducidos junto con la versión 0.7.0.
Estas cifras describen cambios reportados por el desarrollador entre compilaciones. No son comparaciones estandarizadas frente a la ejecución nativa de Nvidia. La configuración del juego, la resolución de salida, la selección de modelos, los controladores y las entradas de renderizado pueden alterar el resultado.
Blanco afirma que una RX 9070 XT puede alcanzar entre 90 y 100 fotogramas por segundo a 1080p utilizando el modelo completo de HT Neural Rendering. También asegura que la salida es similar a DLSS nativo, aunque algunos efectos no funcionan por completo.
El objetivo de desarrollo declarado es igualar el rendimiento de una GeForce RTX 5070 Ti. Por ahora, sigue siendo una aspiración, no un resultado verificado. Ninguna batería amplia de pruebas independientes establece aún la paridad entre juegos o condiciones de calidad de imagen.
Las pruebas anteriores ilustran tanto la rapidez con que puede evolucionar el rendimiento como la dificultad de mantener comparaciones válidas. Las pruebas de septiembre citadas por la cobertura de DLSS-NR mostraron que Cyberpunk 2077 pasó de aproximadamente 30 fotogramas por segundo a unos 50 tras rápidas mejoras en el runtime.
La misma cobertura describió una mejora reclamada del 74 por ciento entre dos compilaciones alfa sucesivas. Esa ganancia fue importante para el desarrollo, pero partía de una base baja. El juego seguía funcionando de forma considerablemente más rápida sin Neural Rendering activado.
Ese historial apunta a margen de optimización dentro del runtime. No demuestra que el software por sí solo pueda cerrar la brecha restante. La ejecución en Radeon podría llegar finalmente a un techo impuesto por el rendimiento matricial disponible, el movimiento de memoria o los recursos de cálculo compartidos.
Frame Generation también complica las afirmaciones de rendimiento. Los fotogramas generados elevan las tasas de fotogramas mostradas sin aumentar la frecuencia de las nuevas actualizaciones del estado del juego. Un contador más alto puede mejorar la fluidez visual mientras la capacidad de respuesta de entrada sigue ligada a la tasa de renderizado subyacente.
Multi Frame Generation hace que esa distinción sea más importante. Si el sistema crea varios fotogramas alrededor de cada fotograma renderizado de forma tradicional, los artefactos y el comportamiento de la latencia dependen en gran medida de la calidad y sincronización del flujo base.
Ray Reconstruction tiene una dependencia diferente. Se basa en vectores de movimiento, profundidad, información de superficie y entradas trazadas por rayos procedentes del juego. Una ruta de entrada incompleta o incompatible puede reducir la calidad incluso cuando el propio modelo neuronal se ejecuta correctamente.
El diseño modular del proyecto permite a los usuarios combinar entradas y salidas de formas poco convencionales. Por ejemplo, las entradas XeSS de un juego pueden alimentar Neural Rendering mientras FSR se encarga del escalado. Esa flexibilidad resulta valiosa para experimentar, pero cada combinación crea otra superficie de compatibilidad.
Nvidia conserva una ventaja importante porque coordina los modelos originales, los controladores, las integraciones de desarrolladores y los objetivos de hardware. Puede ajustar la ruta completa en lugar de adaptarse a interfaces diseñadas para otro proveedor.
AMD mantiene una ventaja diferente mediante la estrategia de amplia implantación de FSR. Algunas versiones de FSR funcionan en GPU de varios proveedores, y los desarrolladores pueden integrarlas sin requerir hardware Radeon. Redstone reduce esa universalidad a medida que AMD añade más componentes de aprendizaje automático.
El proyecto de Blanco se sitúa entre ambos enfoques. Trata las tecnologías de los proveedores como módulos que pueden separarse de la ruta de hardware para la que fueron concebidos. Su existencia sostiene que las interfaces son más reutilizables de lo que sugieren sus límites de marketing.
El port no vuelve irrelevantes esos límites. El soporte oficial sigue determinando qué configuraciones reciben pruebas de controladores, asistencia para desarrolladores, actualizaciones previsibles y servicio al cliente. La compatibilidad del mod puede romperse cuando cambia un juego, un controlador o una biblioteca del proveedor.
Por tanto, la auténtica inversión es específica. Nvidia ya no tiene exclusividad técnica absoluta sobre dónde pueden aparecer sus resultados visuales de DLSS. Aun así, mantiene una posición más sólida en cuanto a rendimiento y soporte controlados.
El rendimiento, la estabilidad y el anti-cheat mantienen el logro condicionado
La mayor incertidumbre no es si las funciones de DLSS pueden iniciarse en Radeon, sino si los jugadores comunes pueden depender de ellas en juegos reales.
El proyecto sigue siendo software alfa. Las notas de la versión 0.8.0 enumeran correcciones para una fuga de memoria de GPU y un fallo de inicio poco frecuente, al tiempo que identifican problemas de instalación aún sin resolver. El nuevo launcher de Epic Games no es compatible, y añadir juegos manualmente puede fallar.
Los requisitos declarados incluyen Windows 11, un controlador Adrenalin versión 26.1.1 o posterior, un juego DirectX 12 y bibliotecas DLSS aportadas por el usuario. El soporte para Vulkan y Linux está previsto, pero no está disponible en la versión actual.
El anti-cheat presenta un límite más firme. El proyecto advierte que los juegos con anti-cheat bloquearán su DLL. Los usuarios deben desactivar el anti-cheat cuando un juego permita esa opción, lo que por lo general limita la experimentación a modos sin conexión o aprobados de otro modo.
Esa restricción excluye muchos títulos multijugador competitivos de la audiencia práctica. También refleja un diseño de seguridad razonable: se espera que los sistemas anti-cheat rechacen código no reconocido inyectado en el proceso de un juego.
La instalación ha mejorado mediante NeuralHub, pero una instalación más sencilla no equivale a un comportamiento listo para el consumidor. Un gestor puede centralizar archivos y automatizar la detección mientras la compatibilidad subyacente con los juegos sigue siendo frágil.
Las pruebas independientes ya han demostrado esa fragilidad. Una prueba con una RX 9070 XT encontró una advertencia de seguridad de Windows, una escena 3D negra, bloqueos, reversión del controlador y problemas para iniciar Cyberpunk 2077 mediante Steam.
Esa prueba finalmente ejecutó Neural Rendering, pero el rendimiento cayó de 61 fotogramas por segundo a 9 en 4K con trazado de rayos y FSR equilibrado. El resultado representó una reducción del 85 por ciento en esa configuración.
Una sola prueba no puede definir todas las compilaciones o configuraciones actuales. Precedió a algunas optimizaciones posteriores, y el rendimiento de Neural Rendering cambia sustancialmente según la resolución, la configuración del modelo, la complejidad de la escena y el número de pasadas.
No obstante, ofrece un contrapeso necesario al resultado del desarrollador a 1080p. Una función que alcanza entre 90 y 100 fotogramas por segundo en una configuración puede seguir siendo impracticable bajo una carga de trabajo más exigente.
Tom’s Hardware informó de resultados de usuarios igualmente dispares tras la versión 0.8.0. Algunos usuarios describieron poca o ninguna pérdida respecto a FSR nativo, mientras que otros reportaron reducciones de un solo dígito o pérdidas de hasta el 25 por ciento en distintos juegos.
Esos relatos carecen de los controles de una batería formal de benchmarks. Aun así, muestran que «funciona en Radeon» abarca un amplio abanico de experiencias, desde una implementación útil hasta una experimentación inestable.
La calidad de imagen exige la misma cautela. Blanco afirma que la salida se asemeja a DLSS nativo, salvo por efectos que no funcionan por completo. Ese matiz importa porque Neural Rendering modifica materiales e iluminación, en lugar de limitarse a aumentar la nitidez.
Un reflejo ausente, un rostro inestable, una superficie alterada o un detalle temporalmente inconsistente pueden ser más difíciles de cuantificar que la tasa media de fotogramas. Las capturas de pantalla lado a lado pueden ocultar problemas que se hacen visibles en movimiento.
El modo multipass añade otra contrapartida. La versión 0.8.0 puede ejecutar hasta tres pasadas de Neural Rendering por fotograma, con estilos e intensidades independientes. Más pasadas pueden aumentar el efecto visual, pero también añaden trabajo de cálculo.
El proyecto también depende de bibliotecas de modelos propietarios proporcionadas por juegos compatibles. Aunque Blanco afirma que su código no incluye implementación de Nvidia, los usuarios siguen necesitando DLL de Nvidia compatibles. Una futura actualización de biblioteca podría alterar el comportamiento o introducir un nuevo desafío de compatibilidad.
Tampoco hay garantía de que los estudios de juegos respalden errores causados por el loader. Un desarrollador no puede validar razonablemente cada combinación de runtime inyectado, archivo de modelo, entrada de escalador y controlador Radeon.
Ninguna de estas cautelas borra el logro técnico. Los proyectos de modding alfa suelen comenzar con compatibilidad limitada, instalación manual y grandes costes de rendimiento. La iteración rápida puede resolver problemas que inicialmente parecen fundamentales.
Sin embargo, la carga de la prueba ha cambiado ahora. La primera versión demostró que DLSS 5 Neural Rendering podía ejecutarse en Radeon. La versión 0.8.0 demuestra que una colección más amplia puede compartir un marco modular.
La siguiente prueba debe provenir de resultados repetibles. Los analistas necesitan escenas, controladores, resoluciones, versiones de modelos y mediciones de latencia equivalentes en RDNA 2, RDNA 3, RDNA 4 y hardware GeForce nativo.
Hasta que lleguen esos resultados, las afirmaciones de calidad Nvidia nativa o rendimiento de RTX 5070 Ti deben seguir atribuyéndose al desarrollador. El proyecto ha demostrado acceso, no paridad.
Tres señales determinarán si el mod transforma el juego en Radeon
La siguiente etapa estará determinada por benchmarks repetibles, soporte completo para RDNA 2 y respuestas oficiales de AMD o Nvidia.
La primera señal es un conjunto de benchmarks independientes para la versión 0.8.0 o posterior. Debería comparar las mismas escenas de juego en una RX 9070 XT y una tarjeta GeForce adecuada, separando Super Resolution, Ray Reconstruction, Frame Generation y Neural Rendering.
La tasa media de fotogramas por sí sola no será suficiente. Las pruebas deberían incluir rendimiento en percentiles bajos, latencia de entrada, cadencia de fotogramas, uso de memoria de vídeo, estabilidad temporal y artefactos visuales. Los fotogramas generados deben identificarse por separado de los fotogramas renderizados de forma tradicional.
Resultados consistentes cercanos a las afirmaciones del desarrollador a 1080p reforzarían la idea de que el runtime ha pasado de demostración a uso práctico. Grandes variaciones entre títulos sugerirían que el trabajo de compatibilidad sigue siendo más importante que la optimización bruta.
La segunda señal es la expansión prometida del proyecto para las tarjetas Radeon RX 6000. La documentación actual indica que RDNA 2 puede ejecutar Neural Rendering en fase de pruebas, mientras que aún faltan varias otras funciones.
Ofrecer la mayor parte de la suite en RDNA 2 demostraría que la abstracción de arquitectura escala más allá de los diseños Radeon más recientes. También daría a una gran base instalada acceso a funciones que difícilmente llegarán pronto mediante la nueva pila oficial de AMD.
No extender esos módulos debilitaría la formulación de «tres generaciones». Dejaría la suite completa concentrada en RDNA 3 y RDNA 4, con RX 6000 funcionando como un objetivo experimental limitado.
La tercera señal es una respuesta de los proveedores de GPU. AMD podría acelerar la disponibilidad de Redstone, ampliar el soporte para hardware más antiguo o mejorar las rutas de actualización a nivel de controlador para juegos con integraciones FSR compatibles.
Nvidia podría dejar el proyecto intacto, cambiar el comportamiento de sus bibliotecas o aclarar cómo pueden utilizarse sus archivos de modelos fuera de configuraciones GeForce compatibles. Incluso una actualización técnica que rompa el mod de forma no intencionada revelaría hasta qué punto el proyecto sigue dependiendo del ciclo de lanzamientos de Nvidia.
Los desarrolladores de juegos también forman parte de esta señal. Entradas más estandarizadas de movimiento, profundidad, exposición y trazado de rayos facilitarían el intercambio de tecnologías de reconstrucción. Sistemas de validación o anti-manipulación más estrictos empujarían en la dirección opuesta.
El resultado más probable a corto plazo no es ni la paridad total ni un fracaso inmediato. DLSS-NR-on-AMD puede convertirse en una herramienta útil para entusiastas, aunque seguiría sin ser adecuada para compradores que esperan fiabilidad con un solo clic.
Eso seguiría siendo relevante. Los modders han ampliado repetidamente la vida útil de las funciones gráficas mediante la creación de wrappers, la sustitución de bibliotecas y la exposición de opciones que los proveedores restringen según la generación del producto.
La versión 0.8.0 va más allá al reunir cuatro tecnologías destacadas bajo un mismo gestor orientado a Radeon. Demuestra que partes de las pilas gráficas modernas pueden separarse de la ruta prevista por su proveedor, incluso cuando la experiencia final sigue dependiendo del hardware.
Para los propietarios de Radeon, la pregunta práctica es sencilla: ¿cambiarías el soporte oficial y la compatibilidad predecible por acceso a funciones de renderizado que tu tarjeta nunca estuvo destinada a ejecutar? Sigue los próximos lanzamientos de benchmarks, la lista de funciones de RDNA 2 y las actualizaciones de los proveedores antes de considerar DLSS 5 en AMD como algo más que un experimento convincente.



