AMD muestra Dense Geometry Format, la respuesta a NVIDIA RTX Mega Geometry de las RTX 50 para acelerar el Ray Tracing en sus RX 9000 (RDNA 4)
Aunque el hardware en GPU evoluciona, y normalmente lo hace antes que el software, lo cierto es que sus diseñadores deben de implementar algunas mejoras propias para paliar déficit que tanto los SO como las API no hacen correctamente. Hoy tenemos el segundo de esos casos tras presentar NVIDIA su RTX Mega Geometry para las La entrada AMD muestra Dense Geometry Format, la respuesta a NVIDIA RTX Mega Geometry de las RTX 50 para acelerar el Ray Tracing en sus RX 9000 (RDNA 4) aparece primero en El Chapuzas Informático.
![AMD muestra Dense Geometry Format, la respuesta a NVIDIA RTX Mega Geometry de las RTX 50 para acelerar el Ray Tracing en sus RX 9000 (RDNA 4)](https://elchapuzasinformatico.com/wp-content/uploads/2025/02/AMD-Dense-Geometry-Format-DGF-portada.jpg)
Aunque el hardware en GPU evoluciona, y normalmente lo hace antes que el software, lo cierto es que sus diseñadores deben de implementar algunas mejoras propias para paliar déficit que tanto los SO como las API no hacen correctamente. Hoy tenemos el segundo de esos casos tras presentar NVIDIA su RTX Mega Geometry para las RTX 50 (no es exclusivo de Blackwell, aplica al resto de RTX), ya que AMD ha mostrado su Dense Geometry Format, o DGF, una respuesta a la tecnología de NVIDIA, que busca el mismo principio básico, pero desde otro punto de vista: comprimir la geometría en los juegos para acelerar el trazado de rayos.
Adelanto que este va a ser uno de esos artículos largos y complejos, donde la base que tengamos en cuanto a conocimientos debe ser amplia, así que ponte cómodo, porque hay algunos temas anexos a lo presentado por AMD que tendremos que explicar para entender qué está pasando y por qué ahora los dos grandes del hardware en gráficos están metidos de lleno en la geometría y el Ray Tracing.
El problema con los nuevos motores de los juegos, la geometría, el Ray Tracing y DX12 / Vulkan
Sentemos la base y focalicemos el problema y los motivos para lanzar estas tecnologías por parte de AMD y NVIDIA, ya que necesitamos, como suele pasar, el contexto previo. Los nuevos motores 3D, léase por ejemplo Unreal Engine (y sus problemas con el lag y el stuttering que vimos en profundidad) integran tecnologías de nueva generación como Nanite, que tienen una serie de ventajas claras y unos inconvenientes.
Para no centrarnos en un motor en concreto, ya que hay muchos, diremos que estas tecnologías han logrado que el renderizado de la geometría virtual permita crear modelos tan detallados en los juegos que elevan el listón un paso más allá para acercarnos al hiperrealismo. La idea original era no comprometer en ello el rendimiento, y al mismo tiempo, que los desarrolladores de los juegos no se preocupasen por optimizar manualmente cosas como el LOD.
El concepto que debemos tener en la cabeza es que estas tecnologías, aunque usan compresión de estructuras de datos propias para sus motores, normalmente lo hacen con la rasterización, pero no con los BVH para Ray Tracing, y por lo tanto, el trazado de rayos no tiene esta ventaja porque depende de la API, sea DX12 o Vulkan.
¿Qué ocurre? Que ni Microsoft ni los creadores de los motores contaban en un principio con que acelerar una parte y no hacerlo con la otra iba a suponer un problema de latencia y consumo de caché y VRAM descomunal cuando el jugador usase Ray Tracing en los juegos con soporte para estas tecnologías.
AMD y NVIDIA a escena: compresión de geometrías para Ray Tracing
Evidentemente, aumentar las capacidades de las unidades encargadas de trabajar y crear los BVH es una prioridad, pero se necesitaba algo desde la parte del software ya, ahora, en este momento. La solución es simple y compleja al mismo tiempo: necesitaban la parte del software para manejar modelos con una densidad de triángulos extrema para los motores de los juegos con estas tecnologías de compresión, pero para Ray Tracing, y que lo acelerasen, y así no retrasar el trabajo hacia la pipeline desde su parte híbrida.
Si se tienen motores con tecnologías de compresión para la rasterización, y no para los BVH de las API, se requiere una conversión intermedia para acelerar el Ray Tracing, el trazado de rayos, y ahí entran RTX Mega Geometry y Dense Geometry Format (DGF).
¿Cuál es el objetivo de ambas tecnologías? Acelerar desde el software hacia el hardware la estructura de datos, y optimizarla mediante compresión para que el resolver el BVH no retrase la pipeline gráfica, sin colapsar la caché o VRAM, y sin añadir latencia. Las diferencias entre AMD y NVIDIA están en el planteamiento y el cómo lo van a hacer.
NVIDIA quiere acelerar la construcción de los BVH sin comprometer el trabajo de la pipeline, donde para ello optimiza la forma en la que la geometría se almacena y procesa en dichos BVH, pero no modifica nada de cómo funciona DXR dentro de DX12. AMD ha tomado un camino algo distinto con Dense Geometry Format, y eso es exactamente lo que vamos a ver a continuación, puesto que es lo que han mostrado.
AMD Dense Geometry Format (DGF), así va a decodificar las estructuras de los BVH para DX12
Lo podemos resumir en el concepto clave de "tecnología de compresión de geometría", y ya podemos irnos a "tomarnos algo", no tienes que seguir leyendo, es lo importante y resume perfectamente lo que quiere hacer AMD. Pero el cómo lo logran es todavía mejor, y sé que seguirás leyendo para enterarte del trabajo de los rojos, así que permíteme explicártelo de la manera más sencilla que pueda.
AMD quiere reducir el tamaño de los datos de geometría sin que haya una pérdida de calidad, lo que implicaría aumentar el rendimiento en Ray Tracing sin pérdida, aparente, de calidad visual. Y digo aparente, porque por definición algo se perderá, no es una aceleración puramente dicha, es una compresión y descompresión, y ya sabemos que ahí siempre hay pérdidas, por mucho que digan que no.
Esto traerá ventajas, pero para lograrlo AMD tuvo que lidiar con el problema del trazado de rayos y la geometría, las cuales han crecido exponencialmente como comentamos al principio de este artículo. Como los motores y su desarrollo van normalmente por delante de las API, se necesita paliar ese volumen de cruces y triángulos en pantalla, donde AMD afirmaba que estábamos a punto de ver importantes cuellos de botella, dejando el rendimiento caer sin tener respuestas a tiempo.
¿Por qué este trabajo no lo hace la API, es decir DX12 (DXR) y Vulkan? Porque no pueden, de momento. El formato de compresión es personalizado y hay que "traducírselo" a estas API para que la integren en la pipeline. Dicho de otra manera, DX12 no tiene forma nativa de manejar geometrías altamente comprimidas dentro de la pipeline de DXR.
¿Se podrá hacer? Pues en un futuro sí, pero tienen que trabajar estructuras de aceleración demasiado grandes e imponer un formato de compresión que AMD, NVIDIA e Intel tendrán que soportar fuera de sus tecnologías, o forzar su uso a los motores y desarrolladores de juegos.
Comprimir los datos geométricos para que tanto caché como VRAM estén optimizadas
Para solucionar este dilema, AMD ha desarrollado Dense Geometry Format, o DGF, una tecnología de compresión de geometría basada en bloques, que según la propia compañía, "actúa de manera similar a lo que DXT, ETC y ASTC hicieron para las texturas". Al comprimir los datos geométricos de manera eficiente y alinearlos con la memoria caché, DGF permite acceder a cada triángulo con una sola transacción de memoria. Esto no solo mejora el rendimiento del trazado de rayos (Ray Tracing), sino que también beneficia el proceso tradicional de rasterización.
En otras palabras, AMD comprime la geometría asociada a los BVH para Ray Tracing y empaqueta con ello todos los triángulos que es posible para esta tecnología y con un solo objetivo: crear una estructura que se alinee al tamaño de la memoria caché de su arquitectura de marras, en este caso, RDNA 4. ¿Por qué alinearlo con la caché y su tamaño o ciclos?
Porque entienden que pueden recuperar cualquier triángulo con una sola transacción de memoria. En definitiva, es una tecnología que busca acelerar las increíbles estructuras BVH mediante su optimización para la caché de sus GPU. Y claro, ¿cómo se va a hacer esto desde el punto de vista del software?
Pues desde la implementación en el propio juego y no en el driver como tal. El motivo de esto es simple de comprender y ya ha sido respondido en parte más arriba: permite la optimización a más bajo nivel sin los problemas que presente la API de turno. ¿Qué unidades de AMD van a ejecutar Dense Geometry Format?
Deberían ser los Ray Accelerators (3ª Gen, con más unidades por CU), pero AMD también dice que es posible hacerlo con los Shaders. De hecho, desde el punto de vista del rendimiento en cuanto a precisión de la compresión y la tasa de datos a la que se hará, afirman que su sistema es muy competitivo frente a otras soluciones, entendemos que la de NVIDIA, obviamente.
DGF es sinónimo de flexibilidad para los desarrolladores de juegos, sin dependencia de un driver ni una API o Sistema Operativo
Es la última clave que nos da AMD y por la cual han optado también por este método, puesto que pone en manos de los desarrolladores la optimización en cada motor o juego, de manera que puedan lograr un mejor rendimiento en Ray Tracing. En concreto, AMD habla de evitar el mallado o re-muestreado:
"DGF comprime la malla de entrada preservando su conectividad. No es necesario volver a mallar ni re-muestrear para utilizarlo. El remallado manual es un proceso laborioso, y los algoritmos para automatizarlo pueden ser lentos y difíciles de controlar."
Esto tiene otra doble ventaja: no tendrá una precisión fija para la compresión de la geometría en sí, sean vertex o index. ¿Por qué no fijarla y punto? Porque lo que intentan es que cada desarrollador pueda ajustar de manera más precisa el equilibrio entre ser exactos en precisión y uso de la memoria, sea caché o VRAM, según a cada uno le interese y según el tipo de sombreado que use el juego:
"El codificador DGF funciona tomando una precisión objetivo (en bits) y cuantizando las coordenadas en enteros con ese ancho de bits. Esta cuantización inicial es la única fuente de error en DGF."
O lo que es igual, si no lo hace bien el desarrollador en cuanto a precisión y aparecen artifacts en el juego, con un simple setting a modo de control deslizante en la configuración del título que estemos jugado permitirá paliar este problema, o ajustarlo según creamos nosotros conveniente. Para terminar, la compresión de la geometría solo estará disponible para las tarjetas gráficas RX 9000 con RDNA 4, o por lo menos eso han comentado, puesto que es una tecnología de cara al futuro.
Lo que debemos tener claro es que Dense Geometry Format es una tecnología para hacer más eficiente el manejo tan inmenso de la geometría actual sin comprometer la calidad visual o el rendimiento, para potenciarlo con Ray Tracing en todo caso, sin depender de un driver o una API, todo a nivel del motor del juego. Por ello, los desarrolladores deberán adaptar sus títulos a ella, y lo lógico sería que los que estén por salir este 2025 ya lo integren de salida.
La entrada AMD muestra Dense Geometry Format, la respuesta a NVIDIA RTX Mega Geometry de las RTX 50 para acelerar el Ray Tracing en sus RX 9000 (RDNA 4) aparece primero en El Chapuzas Informático.