Polaris en PS “Neo” y Xbox “Scorpio” (Resumen General)

Llevaba días intentando realizar esta entrada pero me faltaba información completa acerca de Polaris 10/RX 480, la GPU de AMD que Sony ha utilizado para la PS “Neo” y la arquitectura que tiene muchos números de entrar en Xbox Scorpio y quien sabe si NX.

AMD-Polaris-17

Hay que tener en cuenta que tanto la GPU de PS4 como la de Xbox One son GCN 1.1 o mejor dicho de segunda generación (la primera fue la 1.0) y por tanto a la arquitectura se han añadido una serie de elementos adicionales que hasta hace unos dos días eran completamente desconocidos y que con la revelación de la RX 480 y la RX 460 se han podido conocer. Es decir, había dejado dejado la entrada en stand-by por si había algún cambio importante respecto a las antiguas GPUs de arquitectura GCN porque hacer la entrada sin toda la información hubiese sido una pérdida de tiempo enorme tanto por mi parte como por la vuestra y es mejor disponer de la información completa.

AMD-Radeon-RX-480-Polaris-10_GCN-4.0-Block-DiagramEl primer cambio lo tenemos en el planificador, hemos de entender que todo microprocesador independientemente de su arquitectura esta formado principalmente por dos partes: La unidad de control y la unidad aritmético-lógica.

machine-cycle

Uno de los motivos por los cuales los FLOPS en una arquitectura no son los FLOPS en otra arquitectura y no se puede realizar una comparación 1:1 es la unidad de control que es la encargada de leer las instrucciones en memoria y convertirla en comandos para que la ALU los ejecute, precisamente dos arquitecturas con la misma potencia en computación teórica pueden ser dispares por tener unidades de control de diferente eficiencia que hacen que el tiempo de ejecución de las instrucciones sea más corto o más largo.. ¿Y cual es la unidad de control en el caso que nos ocupa? En el diagrama se encuentra en la parte superior y es el primer punto donde la arquitectura GCN ha sufrido una evolución y bastante importante por cierto.

GCNHWS

Tenemos una nueva unidad llamada Hardware Scheduler (Planificador por Hardware) 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. El HWS se puede programar a través de programar su microcódigo para hacer la gestión más eficiente pero esto a muy bajo nivel y dudo que muchos desarrolladores pierdan el tiempo aunque es posible que alguno se atreva. Lo realmente importante es lo que esto implica y es el hecho que nos encontramos ante una ejecución “fuera de orden” a nivel general en lo que a la GPU se refiere por el hecho de que gracias al HWS la ejecución de los comandos en la GPU no es planificada por un planificador estático sino uno dinámico y esto aumenta enormemente al rendimiento. En una ejecución dentro-del-orden si la tarea que esta en primer lugar de la lista tarda mucho en realizarse entonces acaba quitando tiempo a las demás con esto se aseguran que todas las tareas tienen recursos disponibles en cada momento, incluso las más triviales para poderse ejecutar y mantiene las Compute Units de la GPU siempre activas.

Si nos adentramos a las Shader Engines veremos que a simple vista no han recibido cambios sustanciales. Una GPU puede tener de uno a cuatro Shader Engines y cada una puede tener una variable cantidad de Compute Units y RBs pero también tienen en su interior una serie de unidades que son importantes en el renderizado de la escena, estas son el Procesador de Geometria y el Rasterizador.

RX480ShaderEngine

El procesador de geometría es el encargado de la subdivisión de los vértices, lo que vulgarmente llamamos teselación pero en Polaris esto ha ido un punto más allá y ahora se le ha dado la capacidad de eliminar las primitivas que se envían al rasterizador que están fuera de la vista de la escena reduciendo la carga de trabajo al eliminar todo cálculo superfluo de la escena. Es decir, ahora hay una unidad encargada de descartar las primitivas de manera inteligente y sin necesidad de que el motor gráfico este dedicado o de utilizar otros mecanismos complejos. Este añadido es tan importante como el del planificador fuera de orden ya que esto ahorra trabajo a los desarrolladores en tener que crear programas de descarte de primitivas gráficas que para colmo acaban necesitando de la potencia de la propia GPU y/o incluso de la CPU afectando al tiempo de renderizado.

PolarisGeometry

En cuanto al rasterizador es la unidad encargada de convertir la geometría 3D de la escena en una puntos dentro del espacio cartesiano para que los puntos sean procesador en la etapa del Pixel/Fragment Shader:

c2_pipelinePor eso es importante la supresión de primitivas que están fuera de la vista para el renderizado de la escena porque aunque no las veas son procesadas y hay que tener en cuenta que en toda GPU la parte que más recursos consume es la del Pixel/Fragment Shader, es decir, la parte del texturizado.

CargaDeTrabajoGPU

El siguiente punto son las Compute Units, pero no voy a perder el tiempo con ellas porque estás no han sufrido ningún cambio respecto a anteriores versiones de la arquitectura GCN.

Polaris_shader_detail-617x408

Compute Unit

Lo que interesa es la organización de las CUs en si mismas dentro de la GPU, pero para entenderlo mejor quiero que os fijéis en el siguiente diagrama:

GCN-CU

Hasta cuatro CUs comparten una cache L1 de datos a la que están conectados, dichas unidades están representadas como la barra vertical violeta y en el caso de la RX 480 tenemos unas 3 CUs conectadas a dicha Cache L1 por lo que hay margen para una versión con 4 CUs que nos daría una potencial GPU de 48 CUs en total, es decir, pasar de esto…

3CU2

… a esto:

4CU2

¿Y por qué la configuración de 48 CUs es importante? Pues bien… Sabemos que hay una consola futura que ha sido anunciada bajo el argumento de 4K nativo a tiempo real y esa es Xbox Scorpio. Pues bien, el hecho de aumentar la resolución supone además el hecho que se han de trabajar con una mayor cantidad de pixeles y en lo que a las Compute Units se refiere significa aumentar la cantidad de estas de la misma manera al tener en su interior las unidades de texturas (cuatro por Compute Unit) por lo que si cogemos una GPU con 12 CUs pensada para 1080P (Xbox One) y necesitamos evolucionar la arquitectura a 4K donde la resolución es cuatro veces superior…

compress-4k-to-1080p

Entonces acabamos necesitando unas 48 CUs y si miramos la RX 480/Polaris 10 y añadimos la cuarta CU a cada uno de los 12 grupos de CUs entonces obtenemos una configuración de 48 CUs que podría ser la de Xbox Scorpio, aunque Xbox Scorpio merece una entrada aparte dejad esto como un acercamiento. ¿Y que hay de PS “Neo? En el caso concreto de Sony han preferido una configuración más modesta de unos 36 CUs. y por tanto la misma que la RX 480 ¿El motivo de ello? Sony tiene el interés de vender el PlayStation VR y aunque Sony niegue que PS “Neo” es para la VR el hecho de aumentar la tasa de fotogramas supone un aumento de los recursos del mismo tipo pero en otra dirección aparte de la resolución. Es muy posible que juegos pensados para ir a 60fps en PS4 tengán su versión VR para PS “Neo” al poderse reproducir a 90hz o 120hz en el hardware de PS Neo.

El siguiente punto es el de los RBs, este es peliagudo porque hay una gran cantidad de procesos gráfico que están prescindiendo del uso de los ROPS que se encuentran en la unidad RB. Las Compute Units procesan los datos en el pipeline gráfico a través de los RB y tiene que haber una correlación de cuantas unidades de procesamiento corresponden a cada ROP, es decir… La cantidad de operaciones por pixel de media que se pueden realizar entre que el ROP escribe un pixel en el búfer de imagen y el siguiente. No todos los procesamientos acaban resultando en un pixel del búfer de imagen y se acaban realizando una serie de operaciones intermedias… ¿Que ocurre cuando los ROPS no son lo suficientemente rápidos a la hora de escribir en memoria? Por eso para el pipeline de computación el acceso a memoria no se hace a través de los ROPS para evitar el conflicto de acceso a la memoria y porque los ROPS aplican una serie de procesos que no son necesarios en el tratamiento puro de datos como ocurre en computación.

Desconocemos la configuración de Xbox Scorpio pero si que conocemos la de PS “Neo” y lo normal sería hablar de la duplicidad de pixeles o al menos un pequeño aumento en la tasa de relleno. En realidad PS4 es un caso curioso porque tiene 32 ROPS pero no tiene el suficiente ancho de banda pese a la potente memoria que tiene para 32 ROPS.

PS4ROPSBandwidth

Los ROPS de la arquitectura GCN no han cambiado y están pensados para poder escribir o leer 8 bytes por pixel en un solo ciclo, por lo que el ancho de banda que necesitan 32 ROPS es de 256 bytes por ciclo… ¿Cual es el ideal para PS4? Los 204 GB/seg solo de lectura por lo que la consola tiene un cuello de botella al tener su tasa de relleno limitada.

La solución a este problema viene con un elemento llamado Delta Color Compression que permite comprimir sin perdidas los datos escritos en memoria tanto por los RBs como por el pipeline de computación gracias al hecho que el controlador de memoria de la GPU tiene el mecanismo de compresión/descompresión de datos al vuelo.

 

Todos sabemos que en un futuro se hablara de los 4K VR, pero por el momento tenemos dos apuestas separadas que por un lado donde Microsoft parece apostar por los 4K mientras que Sony por el momento va a por la VR. En todo caso nos falta una unidad dedicada en lo que a la GPU se refiere y que debería aumentar con la resolución y/o la tasa de fotogramas como son los RBs o Render Back-Ends, dicha unidad no es utilizada en tareas de computación pero es la encargada de crear los búfers de imagen y a simple vista no parece tener ningún cambió a simple vista aunque si que hay uno bastante importante en lo que a la relación con la cache L2 se refiere que es el punto en común entre gráficos y computación aunque el cambió no esta ni en los RBs ni tampoco en la propia cache L2 sino en el controlador de memoria.

Uno de los cambios en la arquitectura GCN 1.2 era el hecho de que el sistema puede trabajar ahora con datos comprimidos (obviamente los descomprime al vuelo para procesarlos con una unidad dedicada para ello).

PolarisRBE

Pero lo realmente importante aquí es el hecho de poder almacenar los datos comprimidos en la cache L2 para evitar la contención con el acceso a la memoria principal, el hecho de que se encuentren los datos comprimidos en la Cache L2 supone que hay más números de que estos se encuentren en dicha cache y por tanto no haga falta acceder a la memoria externa para ciertas operaciones. No podemos olvidar que el proceso de búsqueda de datos en todo procesador empieza en las caches de mas bajo nivel y acaba en las memorias más externas y cuanto más alejado estan los datos del procesador pues peor para el rendimiento porque el tiempo de ejecución depende entra otras cosas de donde están los datos en cada momento.

hierarchymem

Uno de los elementos más importantes de cara al procesamiento de imagen es el uso de estructuras de datos espaciales, Sony en PS4 recomienda el uso del Sparse Voxel Cone Tracing que utiliza las texturas parcialmente residentes en cache.

Axxtgrx

PRT 2 PRT APP

El uso de datos comprimidos permite que el tamaño de las estructuras de datos pueda ser sea mayor y solventa en parte el problema debido a ello. Hay que tener en cuenta que los procesos de iluminación de tres rebotes se basan en que el cálculo de la iluminación se hace por computación a través de estructuras de datos espaciales.

VolumeRayCastingWithRay2

Es más, el hecho de que lo datos se calculen desde la Cache L2 hace que estos se calculen mucho más rápido si que los datos se encuentren en la RAM principal… ¿Pero como metes un Octree con el tamaño que tienen en la Cache L2 de una GPU? Una de las principales novedades que traen las nuevas APIs son las llamadas Volume Tiled Resources que son ideales de cara al uso de estructuras de datos espaciales complejas. Mientras que el Tile Rendering se basa en poder procesar partes pequeñas de la escena el Volume Tiling nos permite procesar partes pequeñas de la estructura de datos utilizada para la iluminación global en vez de todo el conjunto de golpe, es decir, podemos trasladar nodos del Octree o de otra estructura de datos utilizada a la cache L2 y procesar estos desde allí.

volume-tiled-resources-645x351

Obviamente el uso de sistemas de iluminación avanzados supondrá que estos se utilicen bajo 1080P estándar, nada de VR en este caso. Aunque sinceramente creo que serán pocos los juegos que lo utilicen en PS “Neo” y Xbox Scorpop inicialmente poco a poco iremos viendo como con la adopción de los nuevos modelos estas técnica se irán adoptando más y más. Por otro lado existe un margen de crecimiento muy alto entre la VR, los 4K y el uso de estructuras de datos espaciales de manera combinada. Pensad que una escena con luz de tres rebotes a 4K VR requiere de mucha pero que mucha potencia por lo que aún tenemos un largo camino en lo que a potencia se refiere.

Anuncios