Ray Tracing por CPU gracias a Vulkan: cuando las GPUs no son suficiente
Vulkan-2
Todos sabemos que la arquitectura Turing ha supuesto un antes y un después en el mundo de las GPU y de los motores de desarrollo, no en vano NVIDIA la cobra a precio de oro. Pero también hemos visto que su implementación para el cálculo de los algoritmos BVH se realiza de forma híbrida y no pura e independiente, como un proceso totalmente externo al Shading tradicional.
La falta de potencia de las GPU y sus unidades específicas limitan el rendimiento que se puede conseguir con esta técnica, ya que se necesita una potencia de cálculo muy alta para lograr un trazado de rayos alto y en tiempo real.
Pero, ¿y si la CPU echase una mano a dicho cálculo? Los usuarios que dispongan de procesadores rápidos y con bastantes núcleos habrán visto que los motores actuales raramente cargan todos los hilos más allá de un 20-50% en el peor de los casos, donde con seis núcleos es más que suficiente para jugar.
Khronos ha pensado en esto y ha habilitado una extensión exclusiva para Vulkan que permite precisamente cargar la CPU con cálculos directos para Ray Tracing.
La extensión en concreto es definida como VK_KHR_deferred_host_operations y permite que la API descargue costosas operaciones de los drivers a un grupo específico de subprocesos de la CPU, los cuales estarán administrados por la aplicación.
Con esto se permite el trabajo en varios subprocesos en segundo plano e incluso en paralelo y en múltiples núcleos. Esto es útil para la compilación de las pipelines de Ray Tracing o para la construcción de estructuras de aceleración basadas en la CPU con mismos fines.
Las operaciones de host diferidas están diseñadas en torno a un principio de «división del trabajo» y bajo él la aplicación es responsable de:
La configuración de comandos y solicitudes de ejecución diferida.
Asignación de subprocesos de trabajo para ejecutar comandos diferidos.
Establecer prioridades y budgets de CPU como mejor le parezca, eligiendo qué tareas ejecutar y cuándo ejecutarlas.
El driver también es responsable de una parte fundamental de esto, realizando:
Seguimiento del estado de ejecución de un comando diferido.
Implementación de ejecución distribuida, cualesquiera sean las construcciones paralelas que sean más apropiadas para la carga de trabajo (tareas, bucles paralelos, gráficos de dependencia, colas de trabajo y similares)
De esta manera, la aplicación controla la asignación y la priorización del trabajo, pero el driver gestiona los detalles de bajo nivel de la API.
La batalla está servida, ¿será esto uno de los reclamos para que los desarrolladores opten por Vulkan antes que por DXR? ¿copiará Microsoft la implementación de Vulkan antes de que siquiera estos se lo planteen? La guerra por la optimización está servida.
kepacha escribió:Un Dev sobre el Ssd de Series X
Una solución para Ps5 para mejorar el rendimiento del raytracing mediante Vulkan?Ray Tracing por CPU gracias a Vulkan: cuando las GPUs no son suficiente
Vulkan-2
Todos sabemos que la arquitectura Turing ha supuesto un antes y un después en el mundo de las GPU y de los motores de desarrollo, no en vano NVIDIA la cobra a precio de oro. Pero también hemos visto que su implementación para el cálculo de los algoritmos BVH se realiza de forma híbrida y no pura e independiente, como un proceso totalmente externo al Shading tradicional.
La falta de potencia de las GPU y sus unidades específicas limitan el rendimiento que se puede conseguir con esta técnica, ya que se necesita una potencia de cálculo muy alta para lograr un trazado de rayos alto y en tiempo real.
Pero, ¿y si la CPU echase una mano a dicho cálculo? Los usuarios que dispongan de procesadores rápidos y con bastantes núcleos habrán visto que los motores actuales raramente cargan todos los hilos más allá de un 20-50% en el peor de los casos, donde con seis núcleos es más que suficiente para jugar.
Khronos ha pensado en esto y ha habilitado una extensión exclusiva para Vulkan que permite precisamente cargar la CPU con cálculos directos para Ray Tracing.
La extensión en concreto es definida como VK_KHR_deferred_host_operations y permite que la API descargue costosas operaciones de los drivers a un grupo específico de subprocesos de la CPU, los cuales estarán administrados por la aplicación.
Con esto se permite el trabajo en varios subprocesos en segundo plano e incluso en paralelo y en múltiples núcleos. Esto es útil para la compilación de las pipelines de Ray Tracing o para la construcción de estructuras de aceleración basadas en la CPU con mismos fines.
Las operaciones de host diferidas están diseñadas en torno a un principio de «división del trabajo» y bajo él la aplicación es responsable de:
La configuración de comandos y solicitudes de ejecución diferida.
Asignación de subprocesos de trabajo para ejecutar comandos diferidos.
Establecer prioridades y budgets de CPU como mejor le parezca, eligiendo qué tareas ejecutar y cuándo ejecutarlas.
El driver también es responsable de una parte fundamental de esto, realizando:
Seguimiento del estado de ejecución de un comando diferido.
Implementación de ejecución distribuida, cualesquiera sean las construcciones paralelas que sean más apropiadas para la carga de trabajo (tareas, bucles paralelos, gráficos de dependencia, colas de trabajo y similares)
De esta manera, la aplicación controla la asignación y la priorización del trabajo, pero el driver gestiona los detalles de bajo nivel de la API.
La batalla está servida, ¿será esto uno de los reclamos para que los desarrolladores opten por Vulkan antes que por DXR? ¿copiará Microsoft la implementación de Vulkan antes de que siquiera estos se lo planteen? La guerra por la optimización está servida.
https://hardzone.es/noticias/procesador ... u-nucleos/
Ozryel escribió:Entonces la PS5 tendrá teraflops dinámicos ?
En momentos estará en 9 y en otros 10 y lo mismo la CPU ?
argam escribió:La respuesta de Dolby tampoco es tan tajante. Dicen que si, que teoreticamente su systema acepta mas fuentes, pero, y ahi esta la gracia, resulta que los desarrolladores no quieren mas fuentes, tienen de sobra con 32 (o las que sean). Y ya rematan con la mejor frase:
More is good, but more may not necessarily be "better."
Traduccion barata: Tener mas (objetos: fuentes de sonido) es bueno, pero tener mas puede no ser necesariamente "mejor"
Me gustaria saber que opinarian algunos si eso lo hubiese dicho Cerny de los TF...
argam escribió:La respuesta de Dolby tampoco es tan tajante. Dicen que si, que teoreticamente su systema acepta mas fuentes, pero, y ahi esta la gracia, resulta que los desarrolladores no quieren mas fuentes, tienen de sobra con 32 (o las que sean). Y ya rematan con la mejor frase:
More is good, but more may not necessarily be "better."
Traduccion barata: Tener mas (objetos: fuentes de sonido) es bueno, pero tener mas puede no ser necesariamente "mejor"
Me gustaria saber que opinarian algunos si eso lo hubiese dicho Cerny de los TF...
Nuhar escribió:El ssd de ps5 puede dar tiempos de carga menores, pero luego el rendimiento del juego sera superior en xbox serie x, mas fps, mas resolucion, mas hierbajos...
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
.Nuhar escribió:Cuanto tiempo de carga menos? Cuanta mejora de calidad mas? Pues yo creo que seran muy parejas, depende de tu color favorito supongo que optaras por una u otra cosa
Ferdopa escribió:Jur...
Sobre el tema de Dolby lo expliqué ligeramente en el hilo de PS5.
Sí bien Cerny mintió diciendo que Atmos se limita a 32 objetos a la vez (soporta mucho más), Dolby Atmos no es un sistema pensado para juegos. Cuando pones un cierto número de "beds" u objetos a la vez en Dolby Atmos, empieza a haber problemas.
Eso nos lleva a varias consecuencias:
- Por esas limitaciones y problemas de Dolby Atmos en juegos, tanto Sony como MS han apostado por soluciones ajenas a Dolby. Dolby ha perdido dos importantes clientes... y no está nada contenta.
- Las soluciones de MS y Sony tienen como forma de salida de audio el PCM multicanal... por lo que cualquier usuario con un receptor/amplificador que acepte HDMI multicanal (la inmensa mayoría de usuarios que ya lo han utilizado desde 2013 con PS4/Xbox One, incluso desde años antes) podrán disfrutarlo sin cambiar sus equipos.
- Usar Dolby Atmos multicanal obliga a los usuarios a disponer de un receptor/amplificador compatible, ya que Atmos es básicamente una señal PCM/True HD con una su señal de metadatos (los metadatos son los que generan el posicionamiento localización).
Sobre la potencia de las consolas, a todas luces Xbox One Series X es más potente. Para mí no hay ninguna duda.
Desde un analisis muy simplista (habría mucho que debatir), Sony parece que ha apostado por ofrecer rendimiento hasta 4K 60hz, mientras que MS ha apostado por potencia bruta para ir más allá de esa cifra y atreverse a llegar a 8K en algunos juegos más o menos complejos y 120hz en bastantes.
Para ir más allá: Sony apuesta por los usuarios tradicionales de consolas que utilizan el televisor (1080p 60hz, 4K 60hz), mientras que MS enfoca la consola hacia usuarios hardcore, máster RACE de PC y que utilicen monitores.
Xbox Series X será el sustituto perfecto de un PC gaming para muchos usuarios.
Ahora hay que esperar a que salgan los multis y comparar, juego por juego, las diferencias prácticas entre ambas.
Un saludo.
Blawan escribió:Le he puesto un SSD a la Switch y ahora es un PC de la NASA.
KinderRey escribió:eloskuro escribió:En los juegos exclusivos de Xbox Series X tmb usarán su sistema Velocity al máximo para hacer mundos más y más grandes y detallados.
Cada uno tiene su forma de hacer las cosas.
Sony con su disco ssd de hasta 9 GB/s
Y MS con el suyo de 5GB/s + sus 110GB/s de más en la RAM (que no es moco de pavo)
Mientras PS5 está cargando de nuevo a 3/4 GB/s de más su RAM de 440 GB/s, Xbox Series X ya tenía cargados de antes esos 110 GB/s extra, así que no le hace falta. Y eso sus first lo harán de lujo.
Sony con su bloque de descompresión de hasta 9 GB/s
MS con su bloque de descompresión de hasta 6 GB/s
Pero eso es sólo la punta del iceberg. MS tiene unidades customizadas en la GPU que trabajan codo con codo con el SSD para un resultado efectivo de 18 GB/s, puntualmente más.
Sony no tengo ni idea más allá del monólogo tipo club de la comedia de Cerny, donde hablaba de máximo de 22 GB/s del bloque de descompresión.
Distintos enfoques para un resultado probablemente similar en cuanto a SSD y eficiencia I/O.
Obviamente las diferencias en fuerza bruta de las dos GPU están ahí y son insalvables por mucho fuego de artificio que se lance a la prensa.
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
pixius escribió:vamos un poco de humor https://twitter.com/i/status/1241666646256816128
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
