Las GPUs de PS4 y PS3

Voy a hacerlo en orden cronológico inverso, el post es meramente informativo.

GPU PS4

La GPU de PS4 al contrario de lo que mucha gente piensa no es una Radeon HD 7870 ni una 7850 por varios motivos que voy a enumerar.

ps4-reverse-engineered-apu

En primer lugar pese a que la litografía del chip marca unas 20 CUs solo tiene 18 CUs activas, la 7870 tiene activas 20 CUs y su versión recortada tiene activas unas 16 CUs por lo que la configuración no es la misma. La otra diferencia es que las HD 78×0 son GPUs GCN 1.0 que no son compatibles con el uncore del AMD Kaveri, el motivo por el cual sabemos que PS4 y Kaveri utilizan el mismo uncore es por el Onion+, algo que requiere que la GPU tenga el set de instrucciones GCN 1.1 y no 1.0.

Visio-Kaveri_Trinity Architecture”äŠr_š.vsd

Captura de pantalla 2016-05-04 a las 11.30.33

No obstante en consolas que sea GCN 1.1 o no es algo que es relativo, porque hay instrucciones que en Xbox One están y en PS4 no y viceversa. Esto lo digo porque curiosamente la GPU de Xbox One también es GCN 1.1 según los arquitectos de la consola pero el IOMMU es de primera generación y no de segunda generación,  esto se ve en el siguiente diagrama de la Xbox One:

Captura de pantalla 2016-05-04 a las 11.31.16

Lo que tenemos un bus llamado Chive que comunica de forma coherente no con el Crossbar sino con el front-end, es decir, sirve para comunicar CPU y GPU en Xbox One de forma coherente haciendo bypass al Crossbar de coherente donde esta conectada la CPU. Es decir, la funcionalidad del Onion+ esta integrada en Xbox One pero de una manera distinta y esto tiene que afectar al conjunto de instrucciones de la Xbox One y no hacerla completamente igual a la GCN 1.1 y tener algunos cambios. Pero es que PS4 tampoco es 100% GCN 1.1 y tiene alguna que otra modificación.

Para dar apoyo en los casos en que quieras utilizar la cache L2 de la GPU para gráficos y computación sincronizada, hemos añadido un bit en los tags de la cache, lo llamamos el bit volátil. Puedes marcar de forma selectiva todos los accesos por la computación como “volátiles”, y cuando sea el momento en que sea el momento de que lea desde la memoria del sistema este puede invalidar de manera selectiva las lineas que lo utilizan en la L2. Cuando se trata de escribir de vuelta los resultados, puede escribir de manera selectiva en las lineas que esta utiliza. Esta innovación permite a la computación utilizar la cache L2 de la GPU y realizar las operaciones requeridas sin impactar las operaciones gráficas que ocurren al mismo tiempo. en otras palabras, reduce radicalmente la sobrecarga de correr computación y gráficos juntos en la GPU.

Dicho de manera simple, el bit volátil para utilizarse tiene que tener una serie de instrucciones asignadas… ¿Cual es su funcionalidad? Pues simplemente puedes reservar parte de la cache L2 para realizar computación sobre ella, en realidad esto en el caso de Sony tiene sentido porque en PS3 lo SPE del CBEA se encargaban de la computación y tenían una memoria local de 256KB, lo más lógico es pensar que para facilitarle las cosas y el traslado de PS3 a PS4 a los desarrolladores de Sony podemos pensar que esto permite a la cache L2 tener la misma funcionalidad que ls memoria local de los SPE del CBEA de PS3.

PS4_SDK_2_34

En tareas de computación los Shaders/Compute Units no utilizan las máquinas de función fija del pipeline gráfico (unidades de texturas, ROPS, rasterizador) por lo que su camino de datos es distinto, si miramos cada CU veremos que tiene unos 64KB de memoria local:

Compute Unit

La LDS es algo que también se encuentra en las CUs de Xbox One por lo que la explicación es válida en ambos casos, los shaders se cargan en esta memoria y en bloques de 64KB… ¿Os acordáis de las texturas parcialmente residentes? Pues son una tarea realizada por los shaders y por eso se manejan con datos de 64KB.

prt1crd1w

La propia Sony recomiendo utilizar los bloques PRT no solo para texturas sino también para otras tareas de computación.

PRT APP

SVCT

La idea es pre-cargar la textura en la LDS para luego copiarla hacía la cache L1 y procesarla desde allí (modo gráfico) o simplemente procesarla directamente sobre la propia LDS (modo computación). Pensad que esto es aplicable también a Xbox One desde el momento en que utilizan el mismo tipo de Compute Unit. En todo caso hay que tener en cuenta que la LDS es una memoria con un ancho de banda mucho mayor incluso que la cache L1.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-48-638

Pero en el caso del bit volatil se refiere a la cache L2, la cual se encuentra fuera de la Compute Unit.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-34-638

¿A que es debido esto? Bien, antes he comentado que esto es una reminiscencia de PS3. En PS3 los únicos momentos en que el CBEA podía ayudar no era durante el pipeline gráfico sino durante el per-procesado y post-procesado. Es decir, los SPE le hacían ganar tiempo a la GPU a base realizar los efectos de post-procesado, en algunos casos se copiaban ciertos Render Targets por bloques pequeños a la memoria local de los SPE para aplicarles un “shader” desde los SPE y devolver los datos de nuevo, esto se le llamo Tile Based Deferred Shading.

spubased-deferred-shading-in-battlefield-3-for-playstation-3-15-728

Captura de pantalla 2016-05-04 a las 13.35.28

¿Que es lo que ocurre en PS4? ¿Podemos hacer algo similar con la LDS no? El problema es que la LDS es solo de 64KB como hemos visto antes y la memoria local de los SPE era de 256KB… ¿La mejor solución? Buscar una memoria intermedia que pueda hacer caber los datos para procesar el bloque y que mejor que la cache L2. En todo caso perdón por la explicación pero he pensado que esto es importante, recordemos que PS4 tiene una serie de remasters de juegos de PS3 que aprovechan las capacidades del CBEA al haber sido juegos exclusivos de la propia Sony y este cambio en la GPU es para facilitar el traslado del código además que otros motores de editores independientes desarrollados para PS3 también utilizaban este mismo planteamiento como el Frostbite 2 de DICE.

GPU PS3

 

La configuración general de PS3 es la siguiente:

Captura de pantalla 2016-05-04 a las 13.38.33

Pero lo que interesa es el RSX y curiosamente este en potencia bruta debería algo más potente que el Xenos de Xbox 360 pero no lo es, pero antes de adentrarnos en los problemas del RSX tengamos en cuenta la comparación con la GPU de 360, aunque para ello primero hemos de tener en cuenta como Microsoft define a la GPU de Xbox 360:

Captura de pantalla 2016-05-04 a las 13.43.58

Tenemos unas 48 ALUs que combinan escalar+vector y cada una de estas ALUs puede procesar unas 96 instrucciones por ciclo, 1 para escalar y 1 para vector… ¿Pero cual es la longitud del vector?

Cada una de las 48 ALUs pueden trabajar conjuntamente con una instrucción de vector (Vec4) y una escalar al mismo tiempo.

Dado que todos los shaders del Xenos son iguales podemos deducir que hay unas 240 unidades FP32 en total, 48*(4+1), lo que significa una tasa de 240 GFLOPS a 500 Mhz utilizando instrucciones FMADD (un tipo de instrucción muy común en el código para las GPUs que realiza 2 operaciones por ciclo), pero la potencia en coma flotante de la GPU de Xbox 360 no acaba ahí, aún hay más pero esta no se encuentra relacionada con los shaders, pero antes irnos por el RSX se ha de tener en cuenta una diferencia fundamental y es que no hay correlación directa entre el número de unidades de texturas y de shaders en el caso del Xenos, al contrario de lo que ocurre con las series HD 2000 a HD 5000 y sus derivados (Wii U).

arch-big

Captura de pantalla 2016-05-04 a las 15.09.02

Es decir, las TMUs no forman parte de una Compute Unit sino que son elementos separados aunque conectados a los shaders, esto entra en contradicción con el RSX donde las unidades de texturas se encuentran directamente conectadas a los Pixel Shaders y existe una correlación directa.

Captura de pantalla 2016-05-04 a las 15.05.27

El pipeline es el mismo que el del  G71…

7900_blockdiagram

… pero con un cambio sustancial, lo ROPS que en el diagrama se encuentran entre el Fragment Crossbar y las Memory Partition son 8 en el RSX en vez de 16 haciendo que el ancho de banda externo con la GPU este recortado a la mitad. Es decir, 8 ROPS y un bus de 128 bits. El resto de la configuración es igual con 8 Vertex Shaders y 24 Pixel Shaders y en multitud de Wikis se pueden leer las siguientes especificaciones:

Captura de pantalla 2016-05-04 a las 14.48.46

Esto a simple vista es suficiente para enviar a la porra al Xenos ya que estamos comparando 400 GFLOPS con 240 GFLOPS, el problema es que dicha comparación es tramposa y contradice lo que dice Sony en su documentación.

 

3dps309

La diapositiva hace referencias solo al Pixel Shader… ¿Pero como es que se pasa de los 648 FLOPS/ciclo a los 384 FLOPS/ciclo? ¿Es que acaso estamos hablando de dos GPUs distintas? Ni mucho menos, solo que quienes hacen esos números son bastante trileros…

pixelshader

El RSX tiene dos ALUs (FP32 Shader Unit n en el diagrama) que pueden realizar 8 operaciones por ciclo que en FMADD serían 16 y por tanto 24*16=384 y es de ahí donde viene la cifra de los 384 que sumados a los 80 de los VS dan un total de 464 operaciones por ciclo en FMADD frente a las 480 del Xenos. Aunque en todo caso la configuración de shaders del RSX deja de tener importancia ante lo que os voy a contar ahora, que es cuanto menos de…

picard-facepalm

Lo comente hace bastante tiempo pero digamos que la GPU de PS3 es mucho peor que la de Xbox 360 y que el motivo por el cual PS3 da mejores gráficos en ciertos juegos respecto a 360 es por el apoyo del CBEA. ¿El motivo? Hay una cosa en todas las GPUs que son los Vertex Inputs, como habréis adivinado por su nombre son los parámetros que se colocan en los vértices, pues bien… El RSX tiene un problema enorme sobre eso:

“Tengo un shader que requiere unos 8 vertex inputs, Posición, Normal, color, y Texcoord1 a Texcoord5. Asumiendo que todos los inputs están empaquetados (por lo que x,y,z, y w son utilizados). Además, necesito que ese shader se aplique en una masa de cien enemigos que está cerca de la cámara (y por tanto utilizar el mejor lod) y cada uno de ellos tiene 5000 vertices. O si preferís, imaginad una escena 3D con 500K vértices. Estos escenarios son comunes y matan el rendimiento del RSX.”

“Asumo que también sabéis que las unidades de procesamiento de los vértices en PS3 son terribles, cada uno de los vertex shader inputs añaden un ciclo de retardo. De la misma manera, sabréis que la única manera de saltarse esta limitación en PS3 es utilizar los SPU para per-procesador toda la geometría y realizar un backface curling en el Cell primero antes de enviarlos a la GPU.”

“El vertex pipeline no importa cuando tienes que gastar un ciclo para el vertex input. En otras palabras, la GPU se para hasta que esta puede captar todos los datos antes de que pueda incluso empezar a ejecutar el vertex shader. ¿Por qué estoy s importante= Pues por el hecho que los juegos de siguiente generación necesitan un montón de “lookup maps” para verse bien, esto significan montones de coordenadas u/v (cartesianas) y otros datos que necesitan ser pasados al Vertex Shader, y por lo tanto un montón de inputs/entradas. En el caso del RSX, esto significa que la GPU se para. Este es el conocido talón de aquiles de PS3 y esta bien documentado. La única manera de trabajar alrededor de este es utilizar los SPU del Cell como otra “GPU”, en este caso como una “Culling GPU”, y limitar el número de vértices enviado al RSX”.

¿Que importancia tiene esto? El proceso gráfico son una serie de etapas donde los datos se van transformando.

gl-pipeline

Dado que las GPUs son procesadores de caudal y todo el pipeline empieza en el Vertex Input si este esta limitado en el caudal de datos que reciben el resto de etapas del pipeline queda afectado. Es decir, el número de vértices de entrada se acabaran convirtiendo en fragmentos que procesar y si limitas los primeros acabas limitando los datos de entrada de los segundos.

captura-de-pantalla-2012-10-04-a-las-10-24-53

Es decir, es completamente igual que la configuración en cuanto a shaders del RSX fuera el de la GF7900 cuando realmente no operaba como esta en rendimiento. El otro problema son los Pixel/Fragment Shaders, estos dependen enormemente de los ROPS para ejecutar ciertas operaciones y recortarlos de 16 en la GF7900 a 8 en el RSX afecta al rendimiento pero esto no  es un problema desde que el Vertex Input que es una etapa muy anterior es un problema aún mayor, otro problema que tiene que ver con tener un bus de 128 bits en vez de uno de 256 bits son las unidades de texturas. Ya he comentado más de una vez que el rendimiento de las TMUs dependen del ancho de banda de estas con la RAM donde se encuentran las texturas, el hecho de que el caudal de datos pase a ser de 128 bits afecta al rendimiento. ¿El motivo por el cual es de 128 bits? Pues simplemente el colocar un bus de 256 bits hubiese aumentado los ya más que hinchados costes de PS3.

Por culpa de estas limitaciones el RSX no opera con el rendimiento con el que debería operar, personalmente no se si esto es un handicap para forzar el CBEA a los desarrolladores pero con esto la GPU de PS3 esta más que explicada.

Anuncios