Gráficos en Consolas Antiguas Temp 2. (I): PlayStation 2

Es el turno de la clásica consola de Sony.

SONY DSC

De esta he hablado varias veces en el pasado pero esta vez hablare de como se generan los gráficos en la consola y cual es su potencial real respecto a este tema. Esta entrada la tenía pensada como complemento a la de Dreamcast pero debido al galimatías que es el hardware de PS2 y lo confuso que resultaba todo de cara a explicarlo de forma llana, es decir, el objetivo de este tipo de entradas no es llegar  a un lenguaje incomprensible de como funcionan las cosas sino que todo el mundo pueda entender el funcionamiento del sistema, es decir:

keepitsimple

Estamos ante un hardware sumamente complejo y la clave a la hora de explicarlo esta en el hecho de no irse por las ramas. ¿Como es que digo esto? Tuve que parar la serie de entradas por culpa de esta compleja máquina infernal, tan compleja que incluso leyendo documentación de todo tipo para sacar una conclusión me encontraba con proposiciones y axiomas completamente contradictorios entre si dentro de la explicación del sistema, al final tuve que desistir porque…

headache2

Si escribía sobre PS2 significaba tener que escribir sobre GameCube y Xbox, por lo que las tres últimas consolas de la serie por un lado y Game Boy Advance por otro quedaron completamente en el borrador olvidadas y cerré por completo dichas entradas hasta que recientemente en pleno aburrimiento navideño decidí retomar estas entradas para que no se vuelvan en algo para siempre pendiente y más ahora que tenemos la generación de PS4 y Xbox One funcionando ya a pleno pulmón.

El problema para entender PlayStation 2 realmente no es solo su complejidad sino saber cual es la función de cada una de las piezas que la componen a la hora de renderizar la escena y como interactúan entre si estos elementos. ¿Pero tiene algo de especial respecto a otros sistemas? Si, que tiene una mitificación que no se merece por el hecho de que su hardware ha sido mal explicado con exageraciones tanto para bien como para mal.

#1 Esquema general.

PlayStation 2 tiene la siguiente configuración:

arch overview

En el esquema de las cosas solo me interesa lo que es esencial para renderizar los juegos de PS2 por lo que el procesador de E/S y el sistema de sonido los voy a dejar fuera siendo únicamente importantes la RAM principal de 32MB, el Emotion Engine y el Graphics Synthesizer.

¿La relación y comunicación entre estos tres elementos? La siguiente:

PS2DMAC

¿Confundidos por los nuevos elementos que aparecen en el diagrama? Solo tenéis que saber que los que aparecen con el siguiente símbolo:

FlujoSon mecanismos de envió y recepción de datos a y desde le memoria principal, es decir, los elementos que tienen acceso a la memoria principal del sistema son:

  • El EE Core/CPU como es natural.
  • La VU0 y la VU1 con sus respectivos VIF (Vector Unit Interface).
  • El GIF (Graphics Interface)

El procesador encargado de manejar los accesos a la memoria principal es el DMAC, Controlador de Acceso Directo a Memoria. La CPU siempre tiene preferencia de acceso y puede acceder a la RAM en todo su esplendor, en cambio el resto de componentes lo hacen  a través del DMAC con un ancho de banda de 2.4 GB/seg en vez de los 3.2 GB/seg que permite la RAM del sistema.

El tema de los accesos a la memoria es lo que convierte la arquitectura de PlayStation 2 en algo sumamente complejo por lo que antes de explicar los detalles es importante hablar de los participantes.

CPU

El enorme error de mucha gente es pensar que el Emotion Engine es la CPU del sistema, el Emotion Engine incluye la CPU del sistema pero no es la CPU del sistema en si misma sino el EE Core y sus dos co-procesadores que son su FPU (unidad de coma flotante) y el VU0. Como curiosidad Toshiba que fue la socia de Sony intento vender la CPU de PS2 bajo el nombre de ArTile TMPR7901B, pero dicha CPU no incluía el VU1 que en PS2 se encarga de generar la geometría de la escena.

En comparación con el Hitachi SH4 de Dreamcast es un poco más potente en enteros al poder realizar unos 450 MIPS bajo el Dhrystone, no obstante por ciclo de reloj la CPU de Dreamcast es más potente por lo que un hipotético SH4 a la velocidad del EE lo superaría en ese aspecto. En cuanto a la potencia de coma flotante hay que tener en cuenta que la FPU de PS2 tiene una potencia de 0.6 GFLOPS mientras que la VU0 tiene una potencia de 2.4 GFLOPS debido a que una unidad SIMD de cuatro operandos con capacidad FMAC.

Mientras que el SH4 tenía que utilizar la potencia de su unidad de coma flotante para realizar los cálculos no solo de la geometría sino del resto. En el caso de PS2 los desarrolladores pueden utilizar al VU0 en modo macro. co-procesador de la CPU, para realizar dicho trabajo. El VU0 tiene una gran versatilidad ya que puede funcionar también en modo micro y por tanto como procesador independiente que ejecute su propio código en paralelo al de la CPU principal.

El rendering en 3D a tiempo real en PlayStation 2

¿Que tiene de especial PlayStation 2? En realidad nada, su forma de renderizar una escena es exactamente la misma que otros sistemas contemporáneos a su lanzamiento. Ya utiliza el clásico pipeline al estilo OpenGL.

Esto es importante tenerlo en cuenta porque parece que cuando se habla de PlayStation 2 se este hablando de una tecnología exótica o cuasi alienígena por lo que creo que es necesario eliminar todo el velo místico que tiene la consola que muchos le han puesto a su alrededor:

El pipeline clásico de OpenGL de manera muy simplificada es el siguiente:

Pipeline3D simple

¿De que se encarga cada uno de los elementos de PS2? Pues el renderizado depende de si el VU0 esta en modo micro y realizando sus tareas en lo que a la geometría de la escena se refiere o en su defecto se encuentra como co-procesador de la CPU y por tanto no ayudando a la generación de la geometría de la escena.

En el primer caso la configuración es la siguiente:

Es en esta configuración que PlayStation 2 puede transformar unos 66 millones de poligonos por segundo, transformar no es lo mismo que mostrar en pantalla ni tampoco es todo el pipeline de la geometría, es solo una operación del pipeline geométrico de la escena.

¿Pero es muy utilizada? Ejem… La mayoría de juegos utilizan el VU0 en modo co-procesador de la CPU, lo que hace que la configuración sea la siguiente:

El motor geométrico: El VU1

El VU1 es el encargado de realizar toda la étapa geométrica del pipeline 3D y su composición interna al contrario de lo que cree mucha gente es diferente a la del VU0 dado que el VU0 tiene la siguiente configuración:

VU0

Mientras que el VU1:

VU12

VU1

El VU1 tiene dos unidades de ejecución, la primera de ellas es la misma que la del VU0, la segunda es la EFU que funciona en paralelo con la primera. Pero lo que nos interesa es el rendimiento a la hora de generar la geometría que luego ira al rasterizador, Sony nos da cifras grandilocuentes de cara al marketing pero no es la información que nos interesa para saber el rendimiento geométrico.

Hay que tener en cuenta que el VU1 no es un motor geométrico como el de las primeras GPUs de PC que eran sucesión de máquinas de estado que se encargaban de la geometría de la escena. Es decir, no estamos hablando de que el proceso esta programado en el hardware sino que este ha de ser programado por los desarrolladores al  igual que en Dreamcast aunque su funcionamiento es más bien parecido al del RSP dentro del RCP de Nintendo64.

¿Las consecuencias de ello? Una disparidad enorme en los resultados, aunque Sony comenta en el FAQ para los desarrolladores que la etapa geométrica (y es importante resaltar que esto no es todo el pipeline gráfico) requiere entre 15 y 20 ciclos de reloj por lo que en el peor de los escenarios las VU pueden enviar al Graphics Synthesizer unos 14.7 Millones de poligonos por segundo teoricamente hablando, aunque esto dependerá de la calidad del código del juego.

Cuando Sony realizo la presentación del hardware de PS2 por primera vez una de las demostraciones era la de la cara de la anciano que mostraba uno 76,857 poligonos por fotograma haciendo uso solo del 32% de la potencia del Emotion Engine:

square_2_3

Veamos:

1oo*(76857/32)=240178.125 poligonos por fotograma.

240178.125*60 fotogramas por segundo=14.410.687.5

La cifra es muy cercana a la del FAQ oficial. Ahora bien, como he dicho antes el pipeline gráfico no termina aquí sino que una vez la geometría es procesada esta es enviada a través del bus GIF hacia el Graphics Synthesizer para el proceso de rasterizado, texturizado y posterior dibujado en el búfer de imagen.

¿El bus GIF y su funcionamiento al detalle? Lo voy a detallar más adelante pero de momento demos el salto al GS.

Graphics Synthetizer

El procesador gráfico de PlayStation 2 es considerado erróneamente por muchos como el patito feo del hardware de la consola pero al igual que en el cuento de Andersen a medida que se conoce se convierte en el cisne del hardware de PlayStation 2 en lo que a rendimiento se refiere, no obstante tiene una serie de handicaps importantes.

CXD2949GB_01

¿Qué tiene de particular? Lo primero que llama la atención son sus 16 pipelines, esto significa que puede dibujar un pixel por ciclo de reloj. Esto le da una capacidad máxima en la tasa de relleno de 2.4 Gpixeles por segundo… ¿Pero como puedes mantener dicha tasa de relleno con las memorias que habían en la época? Pues utilizando memoria embebida en su interior.

graphics%20synth

Y aquí tenemos la madre del cordero, cuando la PS2 salio el mercado la GPU más potente para PC era la NV10 incluida en las primeras GeFoce. El chip de Nvidia solo tenía cuatro pipelines pero tenía un motor geométrico en su interior y unos 17 millones de transistores. En el caso del chip de Sony y Toshiba para PS2 ocupa unos 42.7 millones de transistores pero dado que tiene en su interior unos 32MB de DRAM en el chip y cada bit de DRAM ocupa un transistor en realidad los 16 pipelines del GS tienen unos 10.7 millones de transistores. ¿Y en que se traduce esto? Cada uno de los pipelines del GS es sumamente simple en comparación con otros sistemas de la época incluido Dreamcast, carece de ciertas máquinas de estado para realizar efectos que ya habían sido incluidos en procesadores gráficos de la época y por tanto muchos de los efectos gráficos que hacen muchos sistemas contemporáneos a PS2 no los ejecuta por el hecho que no tiene las máquinas de estado que los realizan en otros sistemas en su interior ya que fue el precio a pagar para poder colocar 16 pipelines.

El otro tema es la memoria embebida, tenemos unos 4MB que están divididos de la siguiente manera:

VRAMPS2

El Búfer 1 es el encargado de almacenar el Búfer frontal y por tanto almacena el fotograma ya generado, el Búfer 2 es el búfer el trasero que es donde dibuja el fotograma el GS en esos momentos. Se ha de tener en cuenta que en el caso de PS2 el rendering funciona en dos pasos ya que mientras el VU1 se encarga de la geometría del fotograma N, el GS esta renderizando los datos del fotograma N-1 y en el búfer delantero se encuentra el fotograma N-1.

Esto significa que el GS soporta doble búfering, hagamos un poco de memoria sobre lo que se trata:

Es común tener dos bloques completos (o “búfers”) de memoria de búfer de imagen en un sistema de pantalla. En cualquier tiempo dado, una de estas copias esta siendo leída por el hardware de pantalla para actualizar la pantalla por si mismo, mientras que el otro esta siendo escrito por el sistema de gráficos en 3D. En el instante entre el final de la lectura de datos un fotograma hacía el dispositivo de pantalla hasta el comienzo del siguiente, los dos búfers pueden ser “intercambiados”. Este intercambio permite que el búfer que acaba de ser escrito(dibujado) por el sistema 3D sea leído por el dispositivo de pantalla, mientras hace que el búfer de imagen previo este disponible para preparar el siguiente fotograma. La imagen 8.3 muestra este proceso esquemáticamente.

Este sistema se conoce como doble búfering porque implica dos imágenes de tamaño de pantalla completas. En cualquier momento, un búfer (el “front buffer”) es leído pixel por pixel en el dispositivo de pantalla por el sistema de pantalla 2D, mientras que el otro (el “back buffer”) esta siendo escrito por el sistema de gráficos 3D con el siguiente fotograma. Una vez que el fotograma ha sido dibujado en el “back buffer”, la siguiente vez que el front buffer ha terminado de ser leído por la pantalla (generalmente durante el momento en que la pantalla se esta “reseteando” para el siguiente paso) los dos búfers se intercambían. El “back buffer” se convierte en el nuevo “front buffer” y el “front buffer” que acaba de ser leído por la pantalla se convierte en el nuevo “back buffer”, listo para ser re-dibujado con el siguiente fotograma.

Una de las cosas que soporta PS2 es el llamado “Render to Texture”, es decir, puedes utilizar el búfer de imagen y convertirlo en la memoria de texturas del siguiente fotograma ya que en los 4MB de memoria embebida no hay una separación física en dicha memoria. ¿Para que es util esto? En realidad el GS no esta pensado para el multitexturizado, es decir para texturas compuestas por varias muestras distintas en vez de una sola, es por ello que que es posible calcular la escena primero con una muestra y luego rescatar el búfer frontal para convertirlo en la memoria de texturas del GS para el siguiente fotograma y terminar cuando todo el proceso haya terminado después de utilizar múltiples pasos de cara al texturizado.

¿El handicap de ello? Cada vez que esto se realiza la tasa de relleno se divide por completo a la mitad.

El otro tema importante que es búfer Z/Profundidad, PS2 es el primer sistema que utiliza la fuera bruta para solventar este problema. N64 podía realizarlo pero su falta de ancho de banda obligaba a utilizar arboles binarios de posición, PSX/PSone utilizaba directamente dichos arboles al no tener soporte para el búfer de profundidad por hardware y Dreamcast tenía un Tile Renderer que subdividía por completo la imagen en pequeños trozos que eran operados internamente.

Ahora bien, lo que hace complejo de entender el GS es que no tiene ni ROPS ni unidades de texturas.

oh-noes-everybody-panic

Es decir, cada uno de los 16 pipelines realizan ambas funciones pero al mismo tiempo tienen el problema de que no pueden realizar ambas a la vez por el hecho que no pueden leer y escribir en memoria al mismo. Este es el motivo por el cual la tasa de relleno con el texturizado pasa de 2400 millones de pixeles a 1200 millones de pixeles, teniendo en cuenta que la consola soporta filtro trilineal y que el ancho de banda del texturizado es de 9.6 GB/seg esto es suficiente para que pueda realizar dicho filtro sin problemas de ancho de banda con la memoria.

Ahora bien, PS2 tiene la mala fama de tener por lo general una calidad en las texturas inferior al resto, esto es debido a que su sistema de texturizado es muy primitivo y funciona con texturas de 4 y 8 bits de color. Claro esta que a algunos les vendrá a la mente la siguiente escena para intentar decirme que eso es directamente mentira:

Da6hI

O por ejemplo la siguiente:

Shadow-of-The-Colossus-SOTC-Wallpaper-Barba-Goliath-07

Los ejemplos son válidos desde el momento en que vienen de una PlayStation 2, pero la forma de conseguirlos a a través del multitexturizado que he comentado antes y las texturas que utilizan son de 4 y 8 bits de color. ¿El motivo detrás de ello? Ya he dicho antes que los pixel pipelines de PS2 para estar en la cantidad que están tuvieron que estar simplificados por lo que carecen del hardware para operar con texturas de más de 256 colores.

Por otro lado respecto al tema del multitexturizado no podemos olvidar que existe una relación directa entre el número de polígonos que se pueden representar en pantalla y la tasa de relleno final se irá reduciendo con cada nuevo paso. Cuando Sony presento la consola por primera vez hablo de que el GS podía mostrar 75 millones de polígonos,, esto fue una regla de tres tomando como referencia los números de Dreamcast con los 100 Millones de pixeles/3 millones y utilizando como base los 2400 Millones de pixeles, pero sabemos que el texturizado reduce la tasa a 1200 millones y si a esto le sumamos que ya habían efectos como el mapeado de entorno que necesitan dos muestras entonces nos encontramos con que la consola en un entorno normal funciona con unos 600 Mpixeles/seg, por lo que estaríamos hablando de unos 18.750.000 polígonos por segundo y por tanto sería el Emotion Engine que sería el cuello de botella del sistema.

No obstante la mayoría de juegos de la consola hacen uso de un mayor número de pasos de multitexturizado que solamente 2. Un juego que utilice unos cuatro pasos por ejemplo tendrá su tasa de polígonos en 9.375.000 poligonos por segundo, en ese caso el GS sería el ancho de banda y el VU1 no necesitaría enviar tanta geometría de la escena para generarla.

La memoria de texturas y el envió de la geometría.

Una de las particularidades del hardware PS2 y por tanto una de sus limitaciones que el GS solo dispone de 4MB de memoria local, la eDRAM y de esta solo 1MB se puede asignar para texturas. ¿Que significa esto? Significa que se tiene que ir enviado la información de las texturas en cada fotograma generado en el búfer de imagen. Recordad que una cosa son los fotogramas que vemos en el televisor y otra distinta son los fotogramas que son renderizados internamente. Esto lo digo porque tenéis que tener en cuenta el tema del multitexturizado que he comentado antes.

El GS se encuentra conectado al GIF y el GIF dispone de tres caminos distintos con la memoria:

PATH1

Lo ideal sería que se pudiesen acceder a las texturas y a la geometría al mismo tiempo, pero no se puede por lo que se tiene que ir intercalando el envio de texturas y el de la geometría ya que cuando uno de los caminos del GIF esta en activo el otro esta parado y el problema es que el control se ha de llevar de manera manual.

Hay dos formas de realizar el envio, el primero es a través del Path1 y el Path 2, ambos pasan por el VIF1 por lo que los desarrolladores no se tienen que romper mucho los cuernos pero supone el problema de que no se puede procesar la geometría y al mismo tiempo enviar las texturas. En el caso del Path 1+Path 3 la geometría se puede procesar al mismo tiempo que se accede a la memoria principal para tomar las texturas de la misma, lo que no se puede hacer en ninguno de los dos casos es enviar las texturas y la geometría a través del GIF al mismo tiempo lo que supone una importante limitación del sistema en ese aspecto.

Creo que con esto es suficiente para explicar como funciona el sistema, por otro lado perdonad la falta de entradas de estos días y feliz año.

Anuncios