¿Que sabemos de PS «Neo»? Análisis comparativo con PS4 estándar de sus especificaciones

Hace unos días se filtro un PDF que incluía las diapositivas de la presentación de PS «Neo» para los desarrolladores donde se confirman especificaciones técnicas y se comenta el mapa de ruta con el nuevo modelo de PS4, aparte de otras informaciones que son cuanto menos curiosas pero no por ello menos interesantes.

Lo primero es que no vamos a ver juegos de PS4 por un lado y juegos de PS «Neo» por otro sino que todos se distribuirán en la misma caja y a partir de Octubre de 2016 en adelante todos los juegos que salgan para PS4 tendrán que tener soporte para la PS4 estándar y PS «Neo».

El soporta para pantallas 4K vendrá de la mano de la incorporación de una salida HDMI 2.0 en PS «Neo», pero la diapositiva es engañosa por el hecho que los 4K se refieren solo a la capacidad de reproducir videos al incorporar un descodificador de video mejorado respecto al de PS4. En lo que a videojuegos se refiere será como si el sistema tuviese una GPU de más alta gama, pensad en los niveles de detalle que existen en los juegos de PC para haceros una idea de las mejoras de PS «Neo» sobre PS4.

Aquí ya entramos en temas más espinosos. ¿Por qué se necesita parchear los juegos antiguos de PS4? Aunque la diapositiva no lo dice hay un motivo para ello, la GPU de la PS4 estándar pese a ser GCN al igual que la de PS «Neo» en realidad no comparten el mismo set de instrucciones. ¿El motivo? Una es GCN 1.1 (Segunda Generación) y la otra es GCN 1.3 (Cuarta Generación) pues bien, en cada generación hay una serie de instrucciones que son eliminadas y se añaden de nuevas. En el caso de PS «Neo» las instrucciones antiguas no han sido eliminadas pero se han creado dos entornos en la GPU que hacen que los juegos antiguos puedan ejecutarse pero no pueden hacer uso de las capacidades adicionales de PS «Neo» por el hecho que las APIs del sistema (GNM y GNMX) no tienen acceso a dichas instrucciones. Dicho de otra manera, pese a que los juegos van a funcionar en ambos modelos vamos a tener dos versiones distintas de cada juego. ¿En dos discos? Bueno, no… Hay muchas partes en común entre ambas versiones del código para no crear duplicidades entre ambas versiones y que esos recursos se puedan utilizar entre ambos lados.

Aquí entramos en la parte interesante, Sony no hace en ningún momento mención al Full HSA que es lo que AMD va a integrar en sus SoC a partir del AMD Carrizo en adelante, lo que significa que todos los SoC a 14nm utilizan el nuevo uncore en vez del antiguo. El uncore es la unidad encarga de comunicar los diferentes elementos del SoC entre si y estos con la memoria externa. Pues bien, en PS4 el uncore tenía vias de acceso, una coherente con un ancho de banda de solo 20GB/seg utilizado por la CPU y otro no-coherente solo para la GPU de 176 GB/seg. AMD ha unificado los mecanismos en uno solo y ahora pueden colocar un bus coherente capaz de alcanzar el máximo ancho de banda. Es decir, se ha pasado del siguiente modelo de organización de la memoria que es el que tiene PS4:

 

El motivo de ellos son las remiscencias del PC que existen en PS4, en un ordenador personal el pozo de memoria RAM y el de la memoria de la GPU están fisicamente separados:

Las unidades DMA de la GPU en PC en el caso de la arquitectura GCN se encuentran justo al lado del planificador:

La GPU puede acceder a los dos pozos de memoria, la VRAM que no es coherente con la GPU y la RAM que ha de ser coherente a la fuerza porque también accede la CPU. ¿Y que ocurre en PS4? Pues lo siguiente:

Es decir, esto:

Seguimos teniendo el diferencial entre la memoria coherente y la no-coherente pero ahora ambas se encuentran en el mismo pozo de memoria (la GDDR5 en este caso)… ¿Y que es lo que ha hecho AMD en los últimos SoC? Pues algo que de implementarse al 100% acabaría por romper por completo la compatibilidad hacía atrás con los juegos que utilizarán este sistema ya que el cambio es el siguiente:

Y por tanto el esquema de memoria pasa a ser el siguiente:

 

¿Y en que se traduce? A nivel de GPU hay tres tipos de intrucciones que son:

• Gráficos
• Computación
• Acceso a Memoria.

Si hay dos pozos distintos para pasar datos de uno a otro hay que hacer una serie de intrucciones en el código para pasar los datos, si el sistema es puramente coherente entonces no hacen falta dichas instrucciones y te puedes ahorrar las unidades DMA para copiar datos de una parte de la memoria a la otra pero si la eliminas entonces buena parte del código queda inservible. ¿Y como lo puede hacer Sony para mantener la compatibilidad? Pues manteniendo las unidades DMA de PS4 para el modo PS4 en PS «Neo» y dejando el acceso Full HSA en PS «Neo». Esto significa de entrada que el código gráfico entre ambas versiones no será igual pero solo el código gráfico y no todo el código del juego.

En lo que a la CPU respeta, todo apunta que es una Puma+ que forma parte de la familia «Jaguar» y tiene soporte para Full HSA siendo ese el único cambio a nivel de arquitectura, a nivel de desarrollo los programadores no tienen que preocuparse por esa parte ya que no supone un cambió en el código asociado a la CPU, la propia presentación es clara en ese aspecto:

Hay que recordar que la CPU accede a la RAM en el caso de PS4 bajo un bus de 20GB/seg en total para el Northbridge donde esta conectado la CPU, 

Pero en realidad no es la CPU la que accede a la RAM directamente sino que lo hace el Northbridge al que esta conectado la CPU, no sabemos si Sony ha aumentado ese ancho de banda de los 20GB/seg o lo ha mantenido, no nos han dado ninguna información al respecto. Por lo que en lo que la parte de la CPU se refiere no nos tenemos que preocupar por el momento y lo mejor es ir a mirar el tema de la GPU.

La presentación hace que nos hagamos la siguiente pregunta: ¿Es realmente una RX 480 lo que hay dentro de PS Neo o hay una serie de modificaciones?

Si miramos desde el punto de vista del número de Compute Units, Unidades de Texturas y ROPS(RBs) veremos que si, pero hay una serie de elementos que son exclusivos de PS4 que sugieren unas cuantas modificaciones a la RX 480 de las que nadie esta hablando, siendo el primero de ellos el planificador de la nueva GPU de AMD.

El Hardware Scheduler es una nueva unidad en el planificador que se encarga de planificar las listas de comandos que llegan desde la CPU así como los hilos de ejecución que van a ser ejecutados por las Compute Units. Estas unidades pueden “dividir” los bloques de CUs por tareas de manera dinámica y sin necesidad de que la gestión se haga de manera manual. El HWS realiza la división de manera temporal o de manera espacial (dependiendo del caso) y se encarga de asignar tareas a los mismos de manera inteligente según la carga de trabajo que tiene dicho hilo de ejecución. Esto es MUY IMPORTANTE porque en las APIs de bajo nivel se necesitaba que dicha gestión fuese llevada a cabo por el propio desarrollador tirando de CPU y en las de alto nivel era el propio controlador del SO quien realizaba dicha tarea por lo que en ambos casos esto sumaba tiempo de CPU y por tanto esta unidad acaba afectando positivamente al tiempo de renderizado de la escena.

¿Y como afecta a PS4? La consola utiliza una API de bajo nivel llamada GNM donde los desarrolladores tienen que hacer las tareas que hace el HWS de manera manual por lo que si un juego de PS «Neo» utilizará esta unidad en su código gráfico no podría funcionar en la PS4 estándar, este es otro de los motivos por los cuales el código gráfico entre ambas versiones no sería el mismo y esto afecta también al GNMX que es la API de alto nivel. En GNMX los desarrolladores no tienen que hacer todas la tareas ya que una buena parte de las mismas las hace el controlador de la gráfica llevado por la CPU, esto añade una sobrecarga al añadir más tiempo de CPU para el fotograma pero se va a poder utilizar el HWS para esa tarea para ganar unos milisegundos a través de perder la compatibilidad en el código gráfico con PS4 estándar, por eso los juegos de Neo requieren dos versiones de dicho código.

¿Pero no tienen 8 ACEs PS4? ¿Como es que se ha reducido a 4? En realidad no lo ha hecho, si hacemos caso a lo que dice el siguiente artículo:

Cada HWS puede realizar el trabajo de dos ACE…

Es decir, los 8 ACEs para el modo PS4 estándar sigue existiendo en la nueva GPU. Pero hay un elemento adicional que es exclusivo de PS4 y es el añadido del bit volatil en los tags de la Cache L2 de la GPU, esto significa que cada byte de la cache L2 en el caso de PS4 en realidad es de 9 bits en vez de 8 bits. ¿Y esto para que? Mark Cerny lo explico en su día:

«Para dar apoyo al caso en que quieras utilizar la cache L2 de la GPU de manera simultanea para gráficos y computación asincrona, hemos añadido un bit en los tags de las lineas de cache, lo llamamos el bit «volatil». Puedes marcar selectivamente todos los accesos por computación como «volatiles» y cuando sea el momento por parte de la computación de leer en la memoria del sistema, puede invalidar de manera selectiva, las lineas que utiliza en la cache L2.

Para acelerar el tiempo en el que se encuentra en un dato las caches suelen tener tags que son las direcciones de la memoria principal donde se encuentra un dato en concreto o una serie de datos, pues bien, PS4 permite a través del bit volatil dos cosas:

1. Reservar parte de la Cache L2 para operaciones de computación.
2. Reservar parte de la Memoria del Sistema para operaciones de computación.

El bit volatil no se encuentra en el RX 480 y hace que la densidad de la RAM aumente, tened en cuenta que si Sony ha añádido el bit volatil entonces la cantidad de memoria no es de 16Mb (2MBytes) sino de 18Mb haciendo que esta ocupe un poco más. Aunque con esto ya hemos terminado de hablar de los posibles cambios que ha sufrido la GPU y lo que nos toca hablar es del tema de los 4K, erroneamente yo pensaba que Sony iba a apostar por los 1440P pero parece que me equivocaba aunque esta claro que la consola no tiene potencia para los juegos de PS4 en 4K nativo por lo que Sony ha propuesto el uso de una técnica en concreto:

Un «Checkerboard» es un tablero de ajedrez, el concepto es el hecho de dividir la escena como si se tratara de un tablero de ajedrez… y repartir lo que correspondería a unos cuadrados a un fotograma y lo que correspondería a los otros cuadrados al otro fotograma:

La diferencia con el renderizado esteréo convencional es que en este caso no hablamos de dos posiciones de cámara distintas (una para cada ojo) sino que hablamos de una rasterización conjunta de la escena que luego es dividida en dos y dado que los shaders pueden trabajar paralelamente con ambos estos se resuelven de manera simultanea y no una imagen después de la otra. El hecho que la geometría de la escena sea común hace que la parte de la geometría no se tenga que recalcular para ambos medio-fotogramas. Es decir, las partes de la geometría de la escena que son vulnerables a la resolución se pueden renderizar tranquilamente a 1920×1080 reduciendo la carga gráfica en vez de hacerlo a 3840×2160 de manera nativa. Es decir, no es 4K nativo pero tampoco es un escalado a lo guarro y dado que la GPU tiene el doble de Compute Units respecto a PS4 esta claro que lo que busca Sony es que el trabajo de la GPU se divida en dos… ¿Pero si la resolución es cuatro veces superior no sería mejor la división en cuatro? Bueno, la trampa de esta técnica es que en realidad dividimos la escena en pequeños bloques y cada uno de estos bloques es renderizado de manera simultanea por la GPU, es decir, si tenemos los bloques del 0 al 7 en una a fila entonces se renderizaran de manera paralela el 0 y el 1, luego el 2 y el 3, luego el 4 y el 5… ¿Y que ocurre con cada bloque cuando es renderizado? Pues que al final se le aplica una técnica de AA para «hinchar» el tamaño de cada bloque.

Dicha técnica ha sido ya utilizada, en el caso concreto del Rainbow Six Siege de Ubi Soft:

Si se utilizaran los 4K nativos haría falta cuatro veces la potencia en computación, esta técnica no es un re-escalado a lo bestia de 1080P a 4K ya que acaba duplicando el número de muestras respecto a 1080P pero es un camino entremedio que no pide tantos recursos como los 4K nativos.  En todo caso Sony ha sido muy vaga y hablan del uso de otras técnicas para los 4K «no-nativos» y con esto termina la parte gráfica pero nos os vayáis que aún hay más y eso sin salir de la GPU.

AMD en la RX 480 ha mejorado el sistema de audio, recordemos que PS4 utiliza el sistema TrueAudio de la propia AMD para el sonido:

Pues bien, en las GPUs con arquitectura Polaris el subsistema encargado del audio ha sufrido unos cambios realmente importantes y pese a que Sony tiene que haber mantenido los DSP para el sonido de PS4 para la compatibilidad con los juegos de la PS4 estándar hay una novedad en el tema del audio que solo podrían utilizar los juegos al funcionar sobre Neo.

Recordaréis el AMD True Audio, basicamente un bloque DSP conectado a la GPU con acceso de baja latencia a los datos de la geometría de la escena almacenados. Lo que no va a contar ni Sony ni AMD es que True Audio y el sistema de sonido de PS4 son la misma cosa. Con el HWS AMD ha implementado algo llamado True Audio Next (TAN). No utiliza el bloque DSP, de hecho este no esta en la generación de GPUs Polaris. Sin el hardware dedicado, el audio se convierte en un enorme problema debido al timing y los retardos. El Async lo hace mejor… el HWS puede proveer (la funcionalidad del DSP) dedicando tiempo de la GPU o bloques shader a la tarea.

Hay que tener en cuenta que la unidad True Audio se encuentra conectado a la GPU a través de un anillo, que tiene una serie de coprocesadores conectados al mismo y donde esta conectada también la GPU. En dicho anillo en el caso de la  PS4 estándar se encuentran:

• La Propia GPU.
• Las unidades DMA
• EL UVD (encargado de la descodificación de video)
• El VCE (encargado de la codificación de video)
• Los DSP para el sonido (True Audio)
• Comunicación con la salida de audio y video.

 

En el caso de la RX 480 el DSP de sonido ha desaparecido y con ello la TrueAudio API ha sido abandonada por AMD en PC para darle paso al hecho que sea la API Gráfica la encargada de manejar el audio. Dada la dependencia de la API de sonido de los juegos de PS4 dudo mucho que Sony haya suprimido las unidades DSP para dicha tarea en el caso de PS «Neo». No tendría sentido porque es un engorro para los programadores y sobrecomplicada demasiado las cosas siendo esta otra de las partes en que Sony habría hecho cambios en la GPU respecto a la RX480 estándar.

¿Nos queda algo? Ah si, el tema de la memoria.

En el modo PS «Neo» los desarrolladores tienen acceso a 0.5 GB de RAM adicionales, pero la RAM total no aumenta, haciendo que el total de 8GB no haya variado… Pero aquí tenemos que volver a lo anteriormente explicado con el tema de la memoria coherente y no-coherente, en realidad pese a que la parte coherente en PS4 hace que el código de la CPU y la GPU este en un mismo pozo lo que ocurre es que la memoria realmente se divide en tres pozos distintos:

• La parte de la memoria coherente dedicada a la CPU.
• La parte de la memoria coherente dedicada a CPU y GPU.
• La parte de la memoria no-coherente de la GPU.

En PS4 Sony dejaba unos 0.5GB disponibles como pozo conjunto entre CPU y GPU de manera coherente, es por este motivo que el Infamous Second Son utilizaba solo 4.5 GB de memoria en vez de los 5 GB.

En el caso del Infamous lo que se hace seguramente es trasladar la memoria de un espacio a otro a través del DMA, pero Sony para que no se tuviese que utilizar el DMA acabo por crear un espacio conjunto de hasta 0.5GB que es utilizado en casos como Killzone: Shadow Fall y evita el uso de las unidades DMA para ciertas operaciones.

En el modo PS «Neo» al ser toda la memoria coherente no hace falta ese modo compartido ya que todo es modo compartido, pero sigue existiendo esa división entre la memoria para los juegos y la memoria para el sistema pero extrañamente en Neo ha cambiado y no se el motivo desde el momento en que el SO es el mismo. Los juegos de PS4 podrían hacer uso de esos 0.5GB de memoria adicionales pero Sony no da acceso al mismo. Esto significa que la repartición de 5GB por un lado y 3GB por el otro es una limitación que se encuentra implementada en el hardware y eso explicaría porque coincide con el caso de Xbox One, en todo caso esto no debería afectar para nada el código de los juegos de PS4 pero si a los de PS «Neo» y es otro de los motivos por los cuales hay código dispar pero… ¿Que ocurre si el código de la CPU quiere acceder a un área de la memoria disponible en PS «Neo» pero no en PS4 en una PS4? Pues que el codigo dara error, aquí se rompe la compatibilidad binaria de la CPU, es por ello que pienso que esos 512MB adicionales no están pensados para ser utilizados por el código general de la GPU entre las dos versiones sino que la mayoría de desarrolladores lo van a utilizar para funciones especificas de PS «Neo».

Y ya con esto termino, perdón por la longitud de la entrada pero creo que era necesario tocar todos los puntos uno por uno y en una sola entrada.