Supuestas especificaciones PS4 Neo/PS4K comentadas.

Comentario Original:

Buenas Urian, es la primera vez que comento algo en tu blog, aunque te siga desde hace algunos años, supongo que ya estas al “loro” de los ultimo rumores sobre la ps4K/NEO, podrias comentarlos y sus especificaciones, para ti tienen alguna veracidad o son creibles como minimo?

Un saludo y gracias, no pares nunca de aportar al Blog.

PD: enlace de Neogaf: http://www.neogaf.com/forum/showthread.php?t=1209238

Voy a comentar lo que parecen ser las especificaciones de la PS4K, lo de “Neo” creo que es en relación a los nombres en clave dentro de Sony, recordad que PS VR era “Morpheus” por lo que de ser cierta la información de Giant Bomb esto sería una relación a la película “The Matrix”. Bueno, Sony Computer Entertainment lleva años obsesionada con esta película, pero esto es un tema aparte que no se si comentare en alguna entrada.

En fin, al grano:

Captura de pantalla 2016-04-19 a las 13.24.04

#1 “Jaguar”
Si se utiliza “Jaguar” entonces el Soc de PS4K es a 28nm ya que no hay un diseño del módulo Jaguar con un nodo de menor tamaño.  Aunque el nombre Jaguar es extraño desde que hay una versión mejorada y mejor optimizada de la arquitectura de Jaguar llamada Puma… No tiene sentido utilizar Jaguar a estas alturas existiendo una versión mejorada del mismo núcleo bajo el mismo nodo.
La Familia Puma 16h es una arquitectura de bajo consumo por AMD para sus APUs. Sucede a Jagar como una segunda generación (de esta) y pertenece a la misma Familia en cuanto a Arquitectura, 16h… Lo núcleos Puma utilizan la misma microarquitectura que Jaguar y heredan su diseño.
Al fin y al cabo son el mimo núcleo pero su uso como he dicho antes significa el uso de un nodo de 28nm para el chip y no parece que hayan cambios ni en la CPU ni en el uncore, más bien los cambios parecen venir de la GPU unicamente, aunque ya llegaremos a ella, aunque hay cosas que no me cuadran de los rumores, todo se ha de decir aunque no veo rara la configuración descrita y la veo viable.
#2 Correlación velocidad CPU:GPU y Memoria RAM
En PS4 la CPU y la GPU funcionan a una correlación 2:1 (1.6 Ghz/0.8 Ghz). Hay un motivo técnico para ello que no voy a contar aquí en esta entrada para no liar a la gente. Si la CPU va a 2.1 Ghz por lógica la GPU ha de ir 1.05 Ghz. Si la GPU va a 0.911 Ghz entonces la CPU ha de ir a 1.822 Ghz en el caso de que PS4K utilice el mismo uncore, es decir, la parte encargada de conectar los núcleos entre si y con la memoria. Lo único que se me ocurre para esta falta de correlación directa en velocidad es que Sony y AMD hayan decidido cambiar por completo el uncore de PS4, el cual se basaba en el el del AMD Kaveri para colocar el del AMD Carrizo.
amd_zen_apu_roadmap_hbm
PS4 tiene dos buses, el FCL/Onion y el Onion+ que sirven para acceder al Northbridge/Crossbar Switch donde esta conectada la CPU y es completamente coherente y el otro es el RMB/Garlic que es por donde la GPU accede a todo el ancho de banda de la memoria RAM y no es coherente con el resto de elementos del sistema. La coherencia ocurre cuando la información de los tags de memoria de la cache L2 de los diferentes procesadores conectados coincide. Digamos que la arquitectura de PS4 estándar es la siguiente:
AMDUncore
Mientras que el nuevo uncore viene a ser así:
export
Teniendo en cuenta la nueva velocidad de reloj de la CPU y que el bus de los dos modulos Jaguar es de 256 bits y funciona al 50% de la velocidad de reloj entonces esto explicaría el aumento del ancho de banda de la RAM en parte ya que:

0.8 Ghz*32 bytes (256 bits) = 25.6 GB/seg.

1.05 Ghz*32 bytes (256 bits= 33.6 GB/seg.

No es un salto muy espectacular pero la falta de caudal en la memoria puede suponer una perdida de rendimiento en los juegos. En cuanto a la RAM… ya comente que yo colocaría 16GB en modo clamshell o “dos chips por canal”. Obviamente la solución que yo comento es más cara y tiene sentido que ante una subida de vueltas de la GPU se aumente la velocidad de reloj de la memoria. En este caso el coste que habría ido para los 16GB parece que se utilizará para un SoC más grande. Lo que me parece curioso es lo de los 0.5GB disponibles, creo que es un cruce de información en el que Sony va a dejar esos 0.5 GB disponibles para juegos. Actualmente PS4 funciona con 4.5 GB para los juegos:

infamous-Playstation-4-4.5gb-gddr5-memory-analysis

Supongo que será para el búfer de imagen a mayor resolución, la descripción de la información en la fuente original dice lo siguiente:

Los juegos funcionando en modo NEO serán capaces de utilizar las memorias de hardware y unos 0.5 gB adicionales en la memoria para ofrecer tasas de fotogramas estables y una fidelidad visual más alta, al menos en estos juegos que funcionan 1080P en las HDTVs

¿A que se puede referir? Lo que se me ocurre es que Sony haya incorporado una solución a lo G-Sync/FreeSync y teniendo en cuenta que estamos hablando de un SoC de AMD entonces estamos hablando de FreeSync a través de HDMI.

RTG_Page_26

La idea es que la tasa de fotogramas que aparecen en pantalla, no los que se rendirían en el búfer de imagen, coincida con la tasa de renderizado de la GPU para evitar artefactos de imagen. Los 0.5 GB adicionales se utilizarían para almacenar la información del fotograma previo o en el modo “4K” como búfer de imagen para el renderizado a mayor resolución y pongo los 4K entre comillas porque más bien creo que Sony va a ir a los 1440P pero los va a promocionar como 4K porque es una resolución que requiere de televisores 4K.

#3 GPU

La GPU tiene la particularidad de duplicar su número de CUs y con ello su número de unidades de captación de texturas por lo que la RAM pasa a ser un cuello de botella en este aspecto. No es lo mismo tener 72 TMUs hambrientas de datos que tener 144 y sin apenas ampliar el bus de memoria. Pero es que además esta la relación entre los “Pixel Shaders” y lo ROPS como programas ya que unos son dependientes de los otros, los ROPS son los encargados de dibujar sobre el búfer de imagen y un aumento en el número de ROPS de 32 a 64 hubiese sido lo normal pero 64 ROPS suponen aumentar la RAM de un bus de 256 bits a uno de 512 bits. Por lo que en ese aspecto tenemos un cuello de botella a no ser que a los desarrolladores les de por utilizar la computación asíncrona y utilicen los Compute Shaders que no utilizan los ROPS y tienen la ventaja de que cuando se trabaja con ellos se puede trabajar desde cualquier lado de la memoria. Es decir, podemos manipular una serie de datos con un Compute Shaders que se encuentre en la misma CU sin tener que leer el dato de origen de la memoria.

Async_Shaders

Esto aumenta el nivel de utilización de la GPU al reducir la latencia en el cambio de contexto, de gráficos a computación. Tampoco es algo que resulta exótico para los desarrolladores y en PS4 ya hay varios juegos que utilizan la Computación Asíncrona para el renderizado de los gráficos. El problema actual con las APIs de alto nivel en consola (DX11 en el caso de Xbox One y GNMX en el caso de PS4) es que no tienen soporte para multihilo desde la GPU  por lo que de esto se verían beneficiados los juegos haciendo uso de la API de bajo nivel, la llamada GNM.

captura-de-pantalla-2014-11-16-a-las-13-16-33-e1416219818667
captura-de-pantalla-2014-11-16-a-las-13-14-31-e1416219773491

Hay que tener en cuenta que cuando hablamos de pipeline de computación no hablamos del clásico pipeline gráfico, el cual tanto en las APIs modernas tiene el siguiente camino de datos:

IC504917

Mientras que la computación:

IC504918

¿Y que beneficios supone esto? Hay dos escenarios teóricos. En el primer caso son las paradas, es cuando una cola/queue tiene que esperar a un evento que no controla. Dado que tenemos múltiples listas de comandos podemos hacer que una unidad que este parada no lo este y la GPU funciona al 100% de su rendimiento con todas sus unidades funcionando al máximo rendimiento posible. El segundo caso es cuando la carga de trabajo esta limitada por la limitación de recursos o por el hardware de función fija y aquí es donde entra el tema de los ROPS ya que son hardware de función fija. Hay que tener en cuenta que el hardware de función fija hace que haya una cantidad máxima de geometría rasterizada, una cantidad máxima de tasa de relleno, de ratio de filtrado de texturas, el ancho de banda de la memoria y la cache también esta limitado. La computación asíncrona permite realizar operaciones que rompan esas limitaciones a través de tomar como origen y final la memoria dentro de la Compute Unit y el hecho de que los Compute Shaders no utilizan los elementos de función fija de los gráficos.

En PS4 (como en Xbox One) podemos crear múltiples listas de comandos para la GPU, aunque solo un contexto será para gráficos y el resto son para computación, la ventaja de utilizar la computación asíncrona es que esta se puede ejecutar al mismo tiempo que los gráficos. Esto permite pasar de un pipeline de este tipo:

Captura de pantalla 2016-04-19 a las 15.22.49

A otro de este tipo:

Captura de pantalla 2016-04-19 a las 15.23.06

Por lo que se recorta enormemente el tiempo por fotograma pero esto tiene utilidad sobretodo en los efectos de post-procesado y aquí entramos en algo que ya existía desde PS3 con los SPEs del CBEA aunque en PS4 la tarea se ha derivado a la GPU. El hecho de que el postprocesado del fotograma anterior es trabajado desde un contexto distinto en paralelo al renderizado del actual fotograma. En PS4 es la propia GPU aprovechando su soporte para múltiples contextos la que se encarga de ello, dividiendo la potencia según su carga de trabajo entre  las diferentes tareas. Es decir, la falta de ROPS se va a suplir con el uso de computación asíncrona.

#4 PlayStation VR

El elemento más importante de la VR es la latencia total de todo el proceso, la cual ha de estar por debajo de los 20ms en todos los dispositivos HMD.

presence-latency

¿Cosas con las que se puede utilizar la mayor potencia de la GPU? En primer lugar para disminuir al máximo posible el tracking de la escena.

slashgear_samsung_sony_project_morpheus12

en segundo lugar para disminuir el tiempo de renderizado y en tercer lugar para poder aplicar efectos especiales que por falta de tiempo en la versión de PS4 estándar se habrían quitado en los juegos del  PSVR con tal de llegar a los tiempos estipulados en lo que a latencia se refiere en algunos casos. Es decir, este modelo de PS4 puede mejorar la calidad visual de la experiencia VR al utilizar la potencia adicional para aplicar ciertos efectos especiales que por motivos de tiempo de renderizado no serían posibles en la PS4 estándar dentro de un entorno VR. Sony recomienda que los juegos se rendericen a 90fps y sabemos por otro lado que no hay un aumento en el número de ROPS y por tanto no existe en lo que a la tasa de relleno se refiere por lo que la potencia adicional no parece estar relacionada con un aumento de resolución pero si con el número de operaciones por pixel y esto de cara a la VR es muy importante porque como he dicho no solo permite reducir la latencia sino que además permite mejorar la calidad de imagen de la escena.

 

#5 Iluminación de tres rebotes.

Hace unos años Tim Sweeney de Epic hizo una presentación llamada Samaritan para demostrar como se vería una escena renderizada donde los fotones de la escena representados realizaran tres o más rebotes.

Samaritan2

La escena era espectacular y la idea fue llevada al Unreal Engine 4 y a la famosa Elemental Demo.

UE4_Elemental_Cine_screen_00013

¿La potencia necesaria para renderizar la escena de Samaritan?

samaritan_2011_technox4fh5

Unos 2.5 TFLOPS, curiosamente es la misma cifra con la que según Tim Sweeney se necesita de potencia para poder aplicar la iluminación de tres rebotes utilizando una técnica de iluminación global llamada SVOGI.

SweeneyTFLOPS

La demostración original de la Elemental Demo utilizaba un tipo de estructura de datos llamada Octree para almacenar el recorrido de los fotones de la escena. ¿Y como funciona el Octre? Para empezar no almacena la trayectoria de la luz sino que es una división espacial de la escena tridimensional.

Octree

Lo que se hace no es almacenar la trayectoria de la iluminación por cada pixel sino por cada uno de los cubos que forman el Octree, cuanto más niveles tiene el Octree más precisión tiene la iluminación de la escena por lo que de nuevo estamos ante una aproximación y como bien sabréis una aproximación no es lo mismo que el dato real.
VolumeRayCastingWithRay2

Pero para manejar el Octree tenemos dos opciones, la primera es tirar de la CPU, la segunda es a través de los Compute Shaders.

captura-de-pantalla-2015-12-17-a-las-12-11-14

Pero claro, estamos hablando de que esto requiere 2.5 TFLOPS según Sweeney y PS4 tiene una potencia de 1.84 TFLOPS y Sony hasta ahora recomienda una solución de menor precisión prescindiendo de los Octrees por la potencia que tiene PS4 que parece no ser suficiente para dicha solución.

20130821-101514

Pero…

Axxtgrx

¿El motivo? PS4 no tiene en su GPU suficiente potencia… ¿Y donde entra PS4K en todo esto? Tengamos en cuenta que con una GPU a 0.911 Ghz y con 36 CUs la potencia pasa a ser de 1.84 TFLOPS a 4.19 TFLOPs aproximadamente, más que suficiente para que los juegos apliquen la iluminación de tres o más rebotes mejorando enormemente la calidad visual de los mismos sin cambios profundos en el nivel artístico, en el código y en el presupuesto de los juegos. ¿Pero que es la luz de tres rebotes? La iluminación más simple es el llamado Ray Casting, utilizada en el clásico Doom, en ella se proyecta un foco de luz desde la cámara a cada pixel y este es devuelto cuando choca contra un pixel hacía la cámara, a esto se le llama Ray Casting.

 

Captura de pantalla 2015-12-20 a las 13.11.09

El Ray Casting genera un solo rayo por cada pixel de la imagen, su algoritmo de forma simplificada es el siguiente:

  1. Por cada pixel (x,y) lanza un rayo desde la cámara a través de cada uno de ellos y calcula la intersección más cercana.
  2. Por cada una de estas interacciones calcula la normal de la superficie.
  3. Por cada fuente de luz, haz modificaciones sobre el pixel afectado.

Pero la iluminación no rebota, por lo que el comportamiento de las superficies no es simulado y esta no es más que una simple variación de color. ¿Pero que ocurre cuando decidimos simular el comportamiento de la luz y hacer que esta rebote en lo objetos como en la vida real? Lo que se ha conseguido hasta ahora en los juegos es que cada fotón rebote una vez más contra una superficie generando una fuente de luz indirecta que modifica la información de la escena a representar, pero no de forma recursiva como ocurre con el Raytracing. Pero al menos esto permite fuentes de luz indirectas que pueden ser de los siguientes tipos:

 

Image3

Cada material genera luz ambiental, dificula y especular de forma combinada en mayor o menor grado. ¿Y en que consiste la luz de tres rebotes o más? Pues en el hecho de que a la hora de renderizar la escena cada fuente de luz inicial no solo rebotará dos veces como ocurre en los juegos hasta ahora sino que lo hará una vez adicional generando una iluminación mucho más cercana a la realidad y con ello una mejora sustancial de la calidad de imagen en los juegos sin que esto derive en volver a hacer los juegos de nuevo de manera profunda, es decir… Estos cambios a nivel de lo que es el renderizado de juegos se pueden aplicar en los juegos actuales de PS4 sin problemas  pero dudo que lo hagan. Supongo que el tema de la iluminación global será un elemento diferencial entre la versión de PS4 y la versión de PS4 Neo, en todo caso no creo que hayan versiones distintas, simplemente los juegos detectarán en que consola se están ejecutando y renderizarán la escena bajo una directrices concretas dependiendo del modelo.

No me veo un aumento de la resolución desde el momento en que el número de ROPS del sistema no aumenta, de ahí a que yo piense que la iluminación va a ser el elemento que más va a mejorar. En fin, esto es todo y supongo que con la información de la entrada es suficiente.

 

 

 

Anuncios