-Solo funciona en GPUs Blackwell
-Rendimiento en una 5070 Ti a 4K cae de 71 FPS a 35 FPS (debería escalar bien con la resolución de salida).
https://www.techpowerup.com/352033/nvid ... r-analysisHoy informamos que se filtró una DLL de DLSS 5 en una versión de acceso anticipado de NBA2K27 de 2K. NVIDIA anunció DLSS 5 a principios de este año y mostró más detalles en SIGGRAPH, indicando que se lanzaría "este otoño". Sin embargo, nos sorprendió que ya se esté distribuyendo, y con un título como NBA 2K27, sin ningún anuncio importante ni análisis, lo que nos impulsó a investigar qué estaba sucediendo. Quizás los desarrolladores simplemente incluyeron el archivo incorrecto en la versión antes de su lanzamiento.
Varias personas duplicaron copias de la DLL y las subieron a Reddit, donde obtuvimos la nuestra. Para que quede claro desde el principio: NVIDIA no proporcionó ninguna información para este artículo; no hubo ninguna presentación, ni versión de prensa, ni nada por el estilo. Todos los hallazgos aquí reportados provienen de analizar un archivo que circula públicamente e intentar descifrar su contenido. Además, antes de que te emociones demasiado, el archivo no se puede usar en el juego: NBA 2K27 no ofrece ninguna opción para activarlo, y nada en la versión final parece ser capaz de controlarlo. Tampoco puedes simplemente copiarlo en la carpeta de cualquier otro juego; el juego debe estar programado específicamente para cargar esa DLL y proporcionarle la información correcta, como veremos más adelante.
Propiedades del archivoComo puede ver, el archivo está firmado digitalmente por NVIDIA, por lo que es auténtico. La fecha de firma es el 11 de agosto, muy reciente, pero también significa con toda seguridad que este archivo no es la versión final de DLSS 5 que veremos el día del lanzamiento. El número de versión también es superior al de cualquier otra DLL de DLSS encontrada hasta ahora. Esta semana se lanzó DLSS 4.5 Ray Reconstruction, con la versión 310.7.129, esta es la 310.8.0, una versión menor más alta (8 frente a 7).
La DLL y todos sus parámetros usan "DLSSNR", y el binario nunca explica qué significa NR. No hay "Neural Rendering" en ninguna parte, pero estamos bastante seguros de que eso es lo que significa. También lo vimos en el controlador GeForce 610.47, que expuso una configuración de perfil de DLSS Neural Rendering a principios de este año.
El campo "nombre de archivo original" muestra "CL 38718415", un número de lista de cambios de Perforce, la revisión interna del control de versiones a partir de la cual se compiló.
158 MB, y casi todo es el modelo.Con 158,2 MB, esta es la DLL DLSS más grande que NVIDIA ha distribuido hasta la fecha, por un margen considerable. La pregunta obvia es si ese tamaño es real o simplemente lastre de desarrollo: símbolos de depuración, una compilación sin optimizar, ese tipo de cosas. No lo es. Al dividir el archivo por secciones, queda clara su composición:
Código ejecutable de la CPU: 0,7 MB
Datos de solo lectura: 0,2 MB
Kernels y tablas de GPU compilados: 16,4 MB
Pesos del modelo entrenado: 140,9 MB
Aproximadamente el 90% del archivo es la red neuronal en sí, almacenada como un único blob de recursos. La lógica del programa real ocupa menos de un megabyte.
Ese blob resulta ser un mapa de tensores con nombre, estructurado de forma muy similar a un diccionario de estado de PyTorch. Lo analizamos un poco más y encontramos 153 tensores con nombre.
148 millones de parámetros, en FP8El recuento de bytes solo se convierte en un recuento de parámetros si se conoce la precisión, y ahí es donde entran los kernels de GPU de la lista anterior. 111 de los 231 kernels CUDA de la DLL tienen "_fp8" en su nombre, lo que es una pista importante. Analizando los pesos en sí mismos y su distribución estadística se confirma que no son números de coma flotante de 16 bits: los bytes pares (exponentes) y los bytes impares (mantisas) mostrarían distribuciones estadísticas visiblemente diferentes. Si son de 8 bits, no hay ninguna estructura de dos bytes. Los datos tampoco se comprimen en función de una medida de entropía por byte (cuán aleatorio parece cada valor).


Así que, según nuestro propio análisis, el modelo tiene aproximadamente 148 millones de parámetros y se ejecuta en FP8. Para el uso de VRAM, eso significa que puede esperar que crezca en una cantidad similar, insignificante en cualquier GPU moderna. Además de eso, necesita algunos búferes, tal vez varios cientos de MB más, dependiendo de la resolución y los factores de escala, pero ciertamente no gigabytes. Un modelo de 148 millones de parámetros también es algo que casi cualquier capacidad de VRAM de GPU moderna puede manejar, ya que generalmente los modelos de generación de video son significativamente más intensivos en recursos. ¿
Solo GeForce RTX 50?Dentro de la DLL hay "cubins", un conjunto por arquitectura. Enumeramos cada uno: 15 cubins que contienen 231 kernels, y cada uno apunta a "sm_120", que es GeForce RTX 50, Blackwell. No hay "sm_75" (Turing), ni "sm_80" ni "sm_86" (Ampere), ni "sm_89" (Ada).
La sola falta de cubins no lo resolvería, ya que el código CUDA también puede incluir una forma intermedia (PTX), pero no pudimos encontrarla en la DLL. El binario también contiene una puerta de ejecución explícita que informa de una arquitectura de GPU no compatible junto con la mínima requerida.
Si bien esto significa que esta compilación específica, que definitivamente no es la final, contiene código ejecutable solo para GeForce RTX 50 y ninguna otra generación de GeForce, y ninguna ruta alternativa que pudiera generarlo, no prueba que en el lanzamiento DLSS 5 será exclusivo de RTX 50. Lógicamente, tiene mucho sentido desarrollar esta función primero para la arquitectura más moderna y hacerlo bien, antes de preocuparse por portarla o intentar admitir múltiples arquitecturas al mismo tiempo, mientras las cosas aún están en desarrollo.

Entradas del juegoLos juegos pasan datos a todos los algoritmos DLSS a través de parámetros con nombre, por lo que la lista de parámetros es, en efecto, la especificación de entrada, y podemos extraerla del archivo. Para DLSS 5 es breve: la imagen renderizada ("Backbuffer," "Color"), los vectores de profundidad y movimiento ("Depth," "MVec"), el manejo de la interfaz de usuario ("UI," "UIAlpha," "UICorrection"), el enmascaramiento ("ControlMask," "UseAutoMask"), algún tipo de campo de distorsión bidireccional compartido con la generación de fotogramas ("BidirectionalDistortionField"), además de parámetros de salida y tamaño que incluyen una "ScalingRatio".
Curiosamente, este es un conjunto de entradas mucho más pequeño que con DLSS 4.5 Ray Reconstruction, que acepta aproximadamente 25 buffers: albedo difuso y especular, normales, rugosidad, distancias de impacto de rayos, capas de transparencia, guías de dispersión subsuperficial. DLSS 5 no acepta ninguno de ellos.
En SIGGRAPH, NVIDIA dijo que usaron "los buffers internos del renderizado como albedos, normales de superficie y parte de la información de iluminación" para que el modelo supiera con qué mantenerse consistente. Esto nos confundió al principio, pero luego quedó claro que el portavoz formuló esta declaración sobre el entrenamiento: "entrenamos el modelo de una manera para..." También comprobamos si DLSS 5 podría recibir datos del G-buffer tomando esos datos de DLSS Super Resolution o Ray Reconstruction; no hace referencia a ninguno de los dos archivos.
Dos detalles más. "UI", "UIAlpha" y "UICorrection" junto con "Backbuffer" colocan esto al final de la canalización de fotogramas, después del mapeo de tonos, con la interfaz potencialmente ya compuesta; el modelo debe saber dónde está el HUD para que no lo rompa. Y "ScalingRatio", junto con los mensajes de registro que rastrean las dimensiones de la red por separado de las dimensiones de salida, muestra que DLSS 5 se ejecuta en su propia resolución separada, es decir, también realiza algún tipo de escalado. ¿
Ajuste específico del juego?Buscamos mecanismos por título y no encontramos ninguno. No hay tabla de perfiles, ni lista blanca de juegos, ni nombres de juegos incrustados, ni detección de motor. Pero aquí también hay que considerar que esta no parece ser la versión final, y NVIDIA tiene mecanismos de ajuste que se encuentran fuera de la DLL, en la base de datos de perfiles del controlador y las anulaciones de la aplicación NVIDIA. Sospecho que el ajuste de DLSS 5 en realidad se realiza del lado del desarrollador, por escena, a través de máscaras y controles deslizantes que se pasan en tiempo de ejecución. Esto también coincide con el enfoque de NVIDIA en el control por parte de los desarrolladores en la presentación de SIGGRAPH, donde una naturaleza muerta tenía su jarra, uvas y botellas enmascaradas por separado, cada una con su propio par de controles deslizantes de intensidad.
Definitivamente inacabadoEncontramos una cadena de error en el archivo, que informa de un módulo faltante, explica que el bloque en cuestión es parte del esqueleto pero que aún no se ha portado ningún envoltorio, y luego apunta a un archivo para la lista de tareas pendientes: ".cursor/rules/crazy-cuckoo.mdc". Dos cosas ahí. "crazy-cuckoo" suena como un nombre en clave interno, y también está "hnet-vigilant-squid", ¿quizás el nombre del modelo? ".cursor/rules/" es el directorio de configuración utilizado por Cursor, un editor de código asistido por IA.
La demostración de SIGGRAPH mostró a un desarrollador eligiendo entre los modelos A, B y C y cambiando entre ellos según la escena. Parece que la compilación en esta DLL solo incluye una de las tres redes y puede registrar un mensaje indicando que un preajuste no está disponible en esta compilación, por lo que recurre al predeterminado.
El panel de control de esa demo se corresponde casi a la perfección con los nombres de los parámetros en la DLL: deslizadores globales de "Intensidad de estructura" e "Intensidad de tono", una sección de "Máscara automática de modelo" con su propio deslizador de intensidad, una lista de "Enmascaramiento del desarrollador" de elementos individuales de la escena y el selector Modelo A / B / C en la parte inferior.




Reflexiones finales
La conclusión más importante de todo esto es que DLSS 5 es real y está cerca. Ya no es un proyecto de investigación interno ni una demo creada para una conferencia. Un binario finalizado, firmado y listo para su distribución llegó a un juego meses antes de lo esperado; los desarrolladores lo están usando y creando cosas para él ahora mismo. Lo que encontramos en su interior confirma que se trata de una tecnología completamente diferente a la que DLSS ha sido hasta ahora. Super Resolution, Ray Reconstruction y Frame Generation intentan reconstruir lo que el renderizador intentaba dibujar en primer lugar. Este añade algo que nunca antes había existido en la escena, utilizando un modelo generativo real que se ejecuta localmente.
Está claro que aún no está terminado, así que no juzguen DLSS 5 por nada de eso, y nosotros tampoco lo haremos. De hecho, descubrir todo esto nos ha generado aún más curiosidad: estamos deseando probarlo, conocer más detalles de NVIDIA y someterlo a pruebas exhaustivas.
