Comentario#1:
El DLSS lo sacó Nvidia a la vez que el raytracing precisamente para poder soportarlo sin impacto en el rendimiento. La idea de dividir la resolución nativa es dividir el coste del raytracing, y con lo que te ahorras de tiempo de fotograma para lo demás, costeas el raytracing.
Eso es confundir la casualidad con la causalidad, el DLSS se implementó para hacer ver que los Tensor Cores que venían de Volta tenían sentido, es más, durante la primera versión del algoritmo la opinión generalizada por parte de los expertos es que no tenían sentido en un hardware gaming, aunque la cosa cambio con el 2.0.
Da lo mismo si es Checkerboard o FSR, la idea es la misma.
¿La falta de potencia de cara al Ray Tracing? Lo divertido es que las RTX 30 están muy por delante del resto en Ray Tracing y aun así necesitan el DLSS. Por cierto, no me compares soluciones vía shaders de computación con las de aprendizaje profundo, no son lo mismo.
Todo esto lo que nos dice es que en ningún momento se ha planteado el Ray Tracing en consolas sin sacrificios, claro que hay que hacerlos, pero son los mismos que ya se hacen en PC.
No, el problema es que en consolas la implementación del Ray Tracing por el hecho que pierdes potencia para tener que recorrer el árbol BVH a través de un Compute Shader en vez hacerlo desde la unidad de intersección, cosa que no ocurre con RTX 30. Es más, el hardware más avanzado en Ray Tracing hasta el momento es la arquitectura Photon de Imagination que presentaron hace unas semanas y el cual hace uso de Ray Tracing coherente y no aparece en ninguna consola y tampoco en PC desde el momento en que está pensado para dispositivos PostPC, aunque se puede escalar para hacer una tarjeta gráfica dedicada.
Y la culpa de esto la tiene Microsoft y su obsesión de «todo se tiene que poder hacer por computación en la GPU», lo que ha llevado a una implementación de medio pelo en consolas. No tiene ningún sentido una unidad de intersección a medias.
Es más, la gente de Imagination le han hecho esto a AMD en el whitepaper de su arquitectura Photon, bueno, no exactamente.

Esto es lo que planteaba Microsoft en el 2018 al presentar la versión preliminar de DirectX Ray Tracing, el que sean los Compute Shaders los encargados de ejecutar el recorrido del BVH y los cálculos de intersección. ¿El resultado? Demostraciones que requerían hasta 3 o 4 NVIDIA Volta combinadas, no exagero.

En NVIDIA fueron mucho más inteligentes, crearon una NVIDIA Volta para gaming a la que le añadieron los RT Cores que fueron las RTX 20. Eso sí, tuvieron que utilizar el DLSS y los Tensor Cores, pero se pasó de necesitar 4 tarjetas gráficas profesionales de 3000 euros cada una a una sola de 500 euros y todo por descargarle el trabajo de recorrido del BVH y la intersección a los shaders, es lo que se dice un sistema de nivel 3.

¿Y qué hace AMD? Pues no se les ocurre otra cosa que plantear un sistema a medias, un sistema de nivel 2,5 en la que han vendido la moto de la «versatilidad» para realizar algo tan recurrente y repetitivo como recorrer una estructura de datos.

El año que viene cuando salgan las RDNA 3 entonces veréis como AMD tendrá una solución de nivel 3 aparte de otras mejoras. En cuanto a las soluciones de nivel 4, estas tienen relación con el Ray Tracing Coherente.

En HardZone hice un artículo sobre el tema, la realidad es que el Ray Tracing se está implementando todavía en las GPU para gaming y aún faltan unas cuantas generaciones para que su rendimiento sea el adecuado.
Comentario#2:
«En el Ray Tracing los shaders no pueden correr en paralelo por el hecho que este utiliza shaders, por lo que lo has entendido mal».
Por lo que recuerdo de lo que vi en su momento, creo que lo ha entendido bien:
Es una arquitectura diferente de la de NVIDIA. Con NVIDIA los shaders se quedan parados esperando a que la parte de Ray Tracing haga su trabajo, mientras que en AMD se comparten recursos de hardware, se pierde rendimiento y se gana flexibilidad, y se hace en paralelo repartiendo la carga como estimen oportuno. Tiene pros y contras respecto al planteamiento de Nvidia, que sacrifica área de shaders.
No, no lo has entendido bien y deja de intentar defender lo indefendible y sacar cosas como «flexibilidad» que es la misma mierda que argumentaba SONY para defender la tocada de huevos que eran las arquitecturas del Emotion Engine y el CBEA en su día. El problema de la versatilidad es que no sirve para problemas concretos si tienes una función más eficiente que consume menos energía, usa menos transistores y funciona más rápido.
Por cierto, lo de que los shaders se quedan esperando en las GPU de NVIDIA a que la parte del Ray Tracing haga su trabajo es falso, para eso está la computación asíncrona, para que hagan cosas mientras están parados. Lo que no entendéis es que los shaders en RDNA 2 se ven forzados a hacer algo de más que no deberían hacer y eso afecta al rendimiento. Es una mierda de implementación que está siendo defendida por fanboys.
Comentario#3:
Como se tiraban lo Fanboy de Sony, cuando les decías que su PS5 a nivel de arquitectura era RDNA1, y te decían que era FUD XD, ahora ya se usa de manera más generalizada por lo que veo.
Se ha de tener en cuenta que RDNA 2 no es más que puro marketing de AMD, ya que en su negocio semi-custom ofrecen una serie de bloques desde los que sus clientes se pueden montar su propia GPU. Es más, hay elementos en ambas consolas que son más de RDNA que RDNA 2 como el planificador dentro de cada Compute Unit que es de 40 olas en vez de 32.
En todo caso las arquitectura de Microsoft es más RDNA 2 que la de SONY, que solo adopta las Ray Accelerator Units y punto, además que es algo adoptado a última hora que no tenía prioridad en PS5 según SONY. Vamos, que irónicamente a SONY le ha ocurrido lo mismo que SEGA con la Saturn, pero no han sido tan chapuceros.
En realidad el RT tampoco es tan malo comparado con el de Nvidia, la mayoría de juegos anda en torno a los 30% con eso que AMD implemento el tema de Wave32 en los drivers. La única diferencia de los RA y los RT Core, es que los RA no tienen unidad para recorrer el BVH lo hacen los CU(FP32).

El Ray Tracing en consolas es viable, pero actualmente estamos en transición y muchos desarrolladores tendrán que aprender jugar con el tema de optimizar(recortar), las consolas por ejemplo no podrán manejar renderizado full resolución en reflejos o GI por ejemplo, tendrán que hacerlo mitad de resolución o un cuarto para ganar rendimiento, temas de jugar con los materiales, los bounces sencundarios etc .
No, el hecho es que está limitado por el hecho que una pieza fundamental como es la unidad de intersección de rayos está incompleta, algo que debería servir para liberar a las unidades shader de la GPU para realizar otras tareas no lo hace por una implementación a medio pelo y la excusa es «flexibilidad».
Cuando te tienes que pasar horas solucionando un problema que debería estar solucionado a eso lo llaman flexibilidad. Me jode mucho que en la vida real siempre ocurra que te preparas para lo difícil y te viene lo fácil, lo que debería funcionar de por sí o no gastar esfuerzo y de repente se hace más complicado.
Por ejemplo años después los de 4games aprendieron usar rebotes infinitos en su GI en Metro Exodus a través de usar el truco de un fotograma previo, lo cual aumento en gran medida la calidad de GI en Metro Enhanced con un costo gratis.
Halo no emplea RT, porque es un juego pensando para Xbox One, conforme se vayan acomodando los desarrolladores en la Next Gen veremos más juegos con efectos RT.
Ya, pero eso no quita que la implementación a nivel de hardware en ambas plataformas, PlayStation y Xbox, sea mala.
Sería bueno que eventualmente hables de la implementación de la arquitectura Photon que hablas de Imagination que apenas me entero. Y como resultaría en una implementación a nivel de tarjeta gráfica dedicada.
Gracias, ¡saludos!
Me gustaLe gusta a 1 persona
«Por cierto, no me compares soluciones vía shaders de computación con las de aprendizaje profundo».
Lo que es lo mismo es el concepto de dividir la resolución nativa para liberar recursos.
«Eso es confundir la casualidad con la causalidad».
Al contrario, no confundas causalidad con casualidad. Es más que evidente que si no hubiesen tenido DLSS a tiempo hubieran recurrido al ya popular por entonces checkerboard de las consolas.
Veámoslo claro con un ejemplo:
60 FPS: 16 ms de tiempo de fotograma, de los cuales digamos que hay no 2, sino 4 milisegundos exclusivos para el raytracing. O sea, el 25%, como lo que se come MSAA x4 +FXAA en juegos como los Forza Horizon.
Le metemos checkerboard/FSR/DLSS utilizando la mitad de resolución nativa:
Como el coste de raytracing escala con la resolución según has dicho tú algunas veces, baja a 2 ms.
Qué más sucede?
Que los otros 14 ms sobran, porque trabajamos con la mitad de resolución, y la carga gráfica está en algún punto, cuellos de botella a parte, entre lo que tendría normalmente destinando entre 21 y 28 ms, entre +50 y +100% de rendimiento por usar la mitad de resolución.
O al revés, podemos hacer ese trabajo entre 7 y 10 ms. Y a eso le sumas los otros 2 ms.
Le añades el coste del DLSS/checkerboard o similar, y te sale la subida de rendimiento que luce nvidia al combinar DLSS con raytracing.
En consolas es exactamente igual, es un desperdicio hacer raytracing a 4K nativa, y usarán checkerboard y/o FSR o algún algoritmo de IA si sale más a cuenta procesado en los shaders, quizá con int16 y rapid packet math, que se supone que rinde el doble, y la IA no necesita alta precisión.
Sucede que he contado 4 ms en vez de 2 para que se parezca más al caso del raytracing en consolas, mientras que podemos cambiar DLSS por checkerboard y el resultado es el mismo, la ganancia de rendimiento mencionada.
Supongamos que el impacto es incluso mayor en consolas, ok, pues para eso tienes el tiempo que te ha sobrado del resto del fotograma por dividir la resolución.
El objetivo tanto en consolas como en PC es dividir la nativa para costear el RT, y cuanta mayor calidad tenga este, más grado de reconstrucción se usará; por ejemplo, FSR x2 + checkerboard x2 filtrados conTAA y sharpen. Ahí el presupuesto para raytracing se te dispara.
Me gustaMe gusta
Por cierto otro juego más wue funciona mejor en ps5 que en seriesX con 2 tf más.
Cerny no sabe diseñar consolas xD.
Seguiremos con la culpa del SDK
Me gustaMe gusta
Y cuando dicen que es más flexible a la manera de AMD, es en el sentido de que no sacrifican área de chip con hardware específicamente de raytracing o IA. Por ejemplo, 20% y 10% respectivamente. Entonces hay un 30% extra respecto a Nvidia, que a igual cantidad de texture units y rops digamos que es por ejemplo para tener un 40 o 50% más de shaders.
Esto significa que si el juego no usa raytracing, tiene más GPU aprovechable.
También es la razón por la que por una vez ganan a nvidia en rasterizado a igual gama, tras muchos años por detrás por tener peor arquitectura. Tiene más área de chip por no reservar para raytracing.
Me gustaMe gusta