#1 El desarrollo del sistema

Curiosamente de PlayStation 2 no tenemos un culebrón entre bambalinas como ocurre en otros sistemas, este fue desarrollado de manera interna por Sony con la colaboración de Toshiba entre 1995 y 1997 sin problema ni percance alguno. La particularidad de PlayStation 2 es que es la última consola donde todos sus componentes de hardware fueron hechos internamente por el fabricante en vez de pedir colaboraciones a terceros, es por esto quizas que apenás se filtraron rumores y estos aparecieron por primera vez como respuesta a la Dreamcast de Sega pero con el proyecto ya bastante avanzado.

El concepto de Sony con las primeras PlayStation es el de conseguir el tiempo real a través del paralelismo de los diferentes componentes, es decir, tener todos los componentes trabajando como si fuese una cadena de montaje donde ninguna parte del pipeline no se veía parada por completo esperando a que la anteriot terminase que era lo que solía ocurrir en el paradigma venido de Silicon Graphics, que Sony heredo pero no de la misma forma que Nintendo con Nintendo64, esto en la primera PlayStation era muy limitado pero el concepto de SGI que se había visto en N64 era el derivado del Reality Engine y por tanto secuencial.

En 1996 Silicon Graphics cambio el paradigma con el Infinite Reality, fue un salto de gigante respecto al Reality Engine y se consiguió paralelizando por completo el pipeline, camino que siguió la PlayStation 2 en su diseño.

La idea de Sony con PlayStation 2 era conseguir la potencia del Infinite Reality en una consola de videojuegos doméstica, se puede decir que cuasi lo consiguieron y esto era una apuesta arriesgada pero segura ya que el Infinity Reality estaba muy por encima de lo que había en sistemas domésticos en la época, incluso el Reality Engine. Pensad que no llegamos en PC al rendimiento real del Reality Engine hasta las primeras GeForce y el Infinite Reality estaba muy por encima. En realidad el avance en el 3D a nivel de PC fue tal en esos años que se consiguió llegar al nivel del IR muy rapidamente y sobrepasarlo incluso por lo que la apuesta de Sony no fue equivocada y aunque PlayStation 2 tiene defectos notables es un hardware del que merece la pena hablar.

Dicho esto vamos a analizar el hardware o más bien la forma en la que el hardware realiza los gráficos de esta particular consola.

#2 Emotion Engine

El Emotion Engine es uno de los dos chips principales que hay dentro del hardware de la PlayStation 2 y podría considerse sin problemas un SoC desde el momento en que engloba varios componentes en su interior y no solamente la CPU del sistema, pero no es un SoC convencional y su arquitectura es completamente única, tan única que merece un análisis pormenorizado y sin irnos por las ramas para entenderla.

El diagrama general del Emotion Engine es el siguiente:

#2.1 TX5900/MIPS R5900/EE Core CPU

La CPU principal llamada «EE Core» es un TX5900 que no deja de ser una versión licenciada a Toshiba del MIPS R5000 con la particularidad que tanto Sony como Toshiba han añadido una serie de cambios a dicha CPU que lo voy a relatar más adelante, si el MIPS R5000 no os suena os dire que es una CPU de bajo coste de la famllia MIPS que originalmente SGI (propietaria de MIPS por aquel tiempo) utilizo en las estaciones de trabajo de bajo coste O2.

El objetivo de Sony con el Emotion Engine no era solo lanzar un sistema de videojuegos sino competir y desplazar a las estaciones de trabajo de Silicon Graphics de cara al futuro, es por ello que la consola con el tiempo acabo teniendo la capacidad de ejecutar un SO complejo como Linux aunque los juegos nunca se ejecutaron bajo el entorno de funcionamiento habitual de la consola.

Teniendo en cuenta que el proyecto empezó en 1995 realmente tiene sentido pero cuando Sony termino su sistema fue cuando el mundo de la creación del contenido se había pasado al PC con el boom de las tarjetas 3D que apareció durante esa época. ¿El único cambio remarcable en el núcleo MIPS? En realidad el añadido de una Scratchpad RAM de 16KB y poco más, curiosamente el MIPS R5900 soporta cache L2 en su interior para Sony prefirio esta medida. ¿La diferencia entre una Scratchpad RAM y una Cache? Las caches funcionan de forma automática y no son controlables por el desarrollador del software, en cambio un Scratchpad no deja de ser un trozo de código muy rápido. ¿Para que sirve? Pues dado que como veremos más adelante el controlador DMA tiene varios clientes sirve para que el R5900 no se pare, también sirve para comunicar al VU0 directamente con el R5900 sin tener que tirar del controlador DMA. 

#2.2 Vector Unit 0 y Vector Unit 1

La Vector Unit 0 esta colocada como Co-Procesador 2 (COP2) del Emotion Engine, puede funcionar de dos manera distintas:

  • Modo Macro: En el que la VU0 actua como co-procesador del R5900 y es este el que le envia las instrucciones a realizar y los datos. En dicho modo el VU0 no ejecuta el programa en la micro-memoria. El VU0 tiene una conexión directa con el R5900 que le permite funcionar de esta manera y una serie de instrucciones especiales para ello.
  • Modo Micro: En el que el VU0 ejecuta de manera recursiva y en bucle el código que esta almacenado en su micromemoria, es decir, un microcódigo que dicta su funcionamiento. En este caso no actua como co-procesador del R5900 sino que la comunicación se hace a través del DMAC y de ahí a la interfaz VIF0

Curiosamente Sony no recomienda utilizar el VU0 en modo micro, el motivo de ello es que para el calculo de la detección de colisiones,física del juego y animación la FPU es un cuello de botella en cierto tipo de enternos, por lo que la mayoría de veces funciona en modo macro. ¿Que equivalencia tiene el modo macro? Pues es lo mismo que una unidad SIMD en una CPU, es más, tanto la VU0 como la VU1 pueden acceder tanto a su memoria interna para datos como a lo 32 registros de 128 bit cada uno que tiene en su interior el VU0. Pues bien, en modo macro el R5900 escribe directamente en los registros del VU0.

El siguiente diagrama que veis a continuación es el mapa general de ambas VU, en algunas cosas son similares y en otras diferentes:

Cada una de las dos VU tiene unas dos ALUs distintas, una es es una ALU que incluye una 4 unidades FMAC que pueden realizar cada una una multiplicación+suma en un solo ciclo en paralelo, pueden realizar transformaciones muy rapidamente y le dan a a la VU una capacidad muy grande en ese aspecto. La segunda ALU son un cumulo de ALUs distintas entre las que tenemos:

  • La unidad de división en coma flotante.
  • La unidad de generación de números aleatorios.
  • La unidad Load/Store, que es utilizada por la propia VU para acceder a su memoria interna.
  • Una ALU de enteros.
  • Una BRU que sirve para controlar los saltos en el código.

No puede ser una unidad SIMD porque sus ALUs no son simetrica. ¿Entonces? Las VU son unidades VLIW.

Del inglés Very Long Instruction Word. Esta arquitectura de CPU implementa una forma de paralelismo a nivel de instrucción. Es similar a las arquitecturas superescalares, ambas usan varias unidades funcionales (por ejemplo varias ALUs, varios multiplicadores, etc) para lograr ese paralelismo.
Los procesadores con arquitecturas VLIW se caracterizan, como su nombre indica, por tener juegos de instrucciones muy simples en cuanto a número de instrucciones diferentes, pero muy grandes en cuanto al tamaño de cada instrucción. Esto es así porque en cada instrucción se especifica el estado de todas y cada una de las unidades funcionales del sistema, con el objetivo de simplificar el diseño del hardware al dejar todo el trabajo de planificar el código en manos del programador/compilador, en oposición a un procesador superescalar, en el que es el hardware en tiempo de ejecución el que planifica las instrucciones.


https://es.wikipedia.org/wiki/VLIW

La VU1 por otro lado es algo distinta, no puede funcionar en modo macro de la CPU y funciona siempre en modo micro. El modo micro como he comentado antes se basa en que la VU funcione como un microcontrolador repitiendo en bucle todo el rato el mismo programa que es un microcódigo. Esto no es una novedad y ya la vistéis en el RSP del RCP de N64, un MIPS R4000 modificado que ejecutaba siempre un microcódigo y aquí viene una de la partes complejas de PlayStation 2, aunque Sony y otros licenciaban su propio microcódigo, es posible colocar tu propio microcódigo, en el caso de la VU1 al ser el motor geométrico se esta más limitado pero hay algunos juegos que aprovechan el VU0 para cosas en particular curiosas ya que las VU no son procesadores de función fija sino de proposito general, por ejemplo si se quiere la VU0 se puede convertir en un chip de sonido sustituyendo a la SPU2 pero por lo general en todos los juegos es utilizado para las fisicas de los juegos, la detección de colisiones y la animación de los personajes dado que a cierta cuotas de geometria el R5900 se queda excesivamente corto para ello.

El VU0 solo tiene unos 4KB de memoria para datos, esto es debido a que originalmente se penso para dos motivos, uno de ellos en modo macro era que escriba los datos resultantes en la Scratchpad RAM del R5900/EE Core, en el modo micro orginalmente se penso para que las primeras etapas del pipeline geométrico se ejecutasen en el VU0 mientras que las posteriores en el VU1, es por ello que el VU0 puede escribir directamente en los registros del VU1.

Este modo no es utilizado en los juegos pero es como Sony alcanza los 66 millones de poligonos/seg transformados, obviamente este modo no se utiliza y era un simple benchmark calculando todo el rato un mismo triangulo sin Clipping y sin nada, cuando Sony presento la consola las cifras eran tan bestias que la mayoría de desarrolladores profesionales al verlas se pusieron en modo…

Pero a esa parte ya llegaremos en la siguiente sección, antes hemos de tratar la VU1, cuyo diagrama general es el siguiente:

El VU1 tiene una serie de diferencia con el VU0:

  • La unidad EFU compueta por un FMAC+FDIV que es utilizado para el calculo trigonométrico (seno, coseno) y que es necesario para algunas etapa del pipeline geometrico.
  • 16KB de memoria para datos, dado que al contrario del VU0 el VU1 no puede enviar sus resultados a otro sitio.
  • Conexión con el bus GIF que comunica la VU1 con el Graphics Synthesizer

Los desarrolladores acabaron tomado la VU1 como unidad geometrica del sistema en exclusiva y hay que tener una cosa en cuenta, su alto rendimiento respecto a Dremcast que era la otra consola disponible se debe a los siguientes factores:

  • 300Mhz de velocidad en vez de 200Mhz, esto es un 50% más de capacidad de calculo.
  • En las VU tanto la Upper Execution Unit como la Lower Execution Unit funcionan en paralelo, en el SH4 la FPU y la VFPU funcionan conmutadas y esta ultima no tiene unidad FDIV
  • En el SH4 el tiempo de ejecución se reparte en diferentes tareas mientras que con el VU1 todo el tiempo va a parar al calculo de la geometría de la escena.

Como he comentado antes el tema del rendimiento gráfico lo comentare en un apartado aparte, dejad por el momento que os vaya describiendo el Emotion Engine.

#2.3 Unidad DMAC

El DMA Controller (Controlador DMA) es una de las piezas fundamentales para entender el funcionamiento de PlayStation 2. Mientras que las VU y el EE Core son un trabajo de Toshiba, la unidad DMAC es una creación de Sony y es una pieza sumamente importante. En realidad podríamos llamarlo DMA Inteligente dado que es programable y este elemento es importante y en la mayoría de análisis del hardware de PlayStation 2 esto se omite por completo cuando omitirlo resulta un error colosal.

En primer lugar hemos de tener en cuenta que todas las operaciones a memoria del EE Core/R5900/TX5900 son llevadas a cabo por la unidad DMAC en vez de la propia CPU con tal de que los accesos a memoria puedan funcionar en paralelo. El DMAC es por tanto lo que llamariamos a terminos de hoy en día el uncore del SoC que es el Emotion Engine. En segundo lugar, hemos de tener en cuenta que es programable por lo que son los propios desarrolladores los que la tendran que gestionar.

La unidad DMAC comunica los 32MB de memoria RAM de la consola a varias interfaces que son las siguientes:

  1. EE Core/R5900/TX5900 Front Side Bus: Comunica la CPU principal con la unidad DMAC. 
    Funciona a 147 Mhz.
  2. VIF0: Comunica los diferentes componentes con la VU0, es decir, como procesador independiente, curiosamente Sony no recomiento hacer esto con la VU0 por lo que en los juegos es utilizada como co-procesador de la CPU, por lo que este bus casi no se utiliza. Funciona a 147 Mhz.
  3. VIF1: Comunica lo diferentes elementos con la VU1, curiosamente el VIF1 esta comunicado de manera directa con el bus GIF. 
    Funciona a 147 Mhz.
  4. GIF: el GIF es la interfaz externa que comunica con el Graphics Synthesizer.
  5. SIF: Comunica la unidad DMA con el IOP (E/S) y con la SPU2 que es el chip encargado del sonido. 
    Funciona a 34 Mhz.
  6. IPU: Descodificador MPEG y MPEG-2, Funciona a 147 Mhz.
  7. Controlador de Memoria: El DMAC tiene conexión directa con el controlador de memoria RDRAM por lo que también tiene un camino de datos a este como es obvio.

Todos los caminos de comunicación tienen un ancho de banda de 128 bits por ciclo de reloj, por lo que tenemo uno 2.4 GB/s de ancho de banda de comunicación interna entre los diferentes componentes a excepción de la comunicación con el bus SIF que funciona a 1/8 de la velocidad de reloj. 

El concepto con PlayStation 2 no es que los envios de datos se hagan secuencialmente de tal manera que cuando una unidad recibe datos la otra esta completamente parada, la idea es que todas esten activas trabajando en paralelo y para ello las diferentes interfaces tienen bufers que dependiendo del caso pueden ser de 128 bytes o 256 bytes. El DMAC envia los datos en forma de bufers de ese tamaño (paquetes de datos) para que las diferentes unidades reciban datos y esten en pleno funcionamiento. ¿El problema? Se ha de hacer a mano por lo que es un trabajo de chinos que para muchos desarrolladores era un tedio enorme, por suerte en PlayStation 3 este problema fue solventado, pero en PlayStation 2 es uno de lo elementos más odiados de los desarrolladores por el hecho de forzarles a llevar a cabo manualmente algo que debería estar automatizado provocando rendimientos completamente dispares entre lo juegos debido a ello.

Con tal de solventar el problema del acceso en paralelo hay una situación en el que el DMAC puede realizar dos transferencias en paralelo.

  • Scratchpad→RAM
  • RAM→ Perifericos (VIF0, VIF1,GIF…)

Si os fijais uno es un camino en una dirección y el otro en la dirección contraria. Normalmente las interfaces VIF y GIF no escriben de vuelta pero si la interfaz SIF por ejemplo. El problema es que la unidad DMAC solo permite el acceso directo a la RAM o con otro elemento del SoC con un solo dispositivo en origen, es por ello que existe la Scratchpad RAM de 16KB en el EE Core para que en momentos donde la unidad DMAC esta ocupada y le corte el acceso a la RAM a este no se pare en seco al no tener memoria con la que trabajar. El buen uso de la unidad DMAC es crucial para el rendimiento de la máquina y es lo que realmente la hace tan alienigena respecto a otros sistemas de la época pero también lo es el buen uso de la Scratchpad RAM y esta tiene el problema de ser demasiado corta, de unos 16BKB solamente, lo que provoca muchas veces paradas en el EE Core/R5900 afectando negativamente al rendimiento.

No obstante la unidad DMAC es el cuello de botella más grande existente en el sistema. Incluso en juegos muy avanzados y altamente optimizados el ancho de banda es de 1.2 GB/s como mucho y en contadas ocasiones y el rendimiento de acceso a la RAM no llega al 40%. Esto no se comenta mucho porque el DMAC y las interfaces son el trabajo de Sony en todo el Emotion Engine y es mejor correr un tupido velo sobre el tema y más en la consola de la propia Sony.

#2.4 GIF

La interfaz GIF es la que comunica el Emotion Engine con el Graphics Synthesizer, es un bus algo complejo que tiene unos 3 caminos de datos distintos y no uno solo que sería lo habitual.

Los caminos (PATH) son los siguientes:

  • PATH1: Es el camino más utilizado, permite enviar la geometria calculada por el VU1 al GS a través del GIF, este cableado directamente a la memori del VU1 por lo que no entra en conflicto con el DMAC en lo que a envios y recepciones de memoria. A la hora de acceder al GIF es el que tiene la mayor prioridad.
  • PATH2: Se utiliza el VIF1 par enviar datos, puede funcionar en paralelo al PATH1 y funciona de manera conmutada al PATH3, se utiliza para enviar texturas sin que la unidad DMAC se vea afectada, pero el VIF1 solo tiene un bufer de 256 bytes de limite, bien utilizado ese bufer permite transmitir texturas a través del GIF permitiendo que la unidad DMAC no se vea afectada por ello en rendimiento. 

  • PATH3: Es el camino directo al GIF a través del DMAC, no tiene más secreto y es el que habitualmente se utiliza para enviar las texturas (no en todos los juego), el utilizado para los juegos en 2D y que comunica la unidad IPU con el GIF y por tanto con el GS. 
     A la hora de acceder al GIF es el que tiene la menor prioridad.

La comunicación externa entre el Graphics Synthesizer y el GIF es con un bus de 64 bits, esto son unos 1.2 GB/s de ancho de banda por lo que son 20MB por fotograma  a 60 fps o 40MB por fotograma a 30fps como tasas máximas en lo que a texturas y geometria se refiere. No obstante aqui tenemos que aclarar un punto muy importante en lo que es el envio de la geometria y que en el caso de las medidas dadas por los emuladores es importante. De cara al multitexturizado una de la cosas que se hace es enviar varias veces la geometria a través del bus, como no nos interesa tenerla que re-calcular por ese motivo tenemo una memoria post-geometria en la que almacenar la geometria ya calculada que tendremos que enviar varias veces por fotograma. 

De la misma que el resto de los renderizadores que no renderizan por tiles, como la cantidad de polgonos/fragmentos depende de la tasa de relleno si esta la recortamos por utilizar efectos haciendo combinaciones de color, Entonces la tasa de fragmentos/poligonos se recorta de igual manera. Tanto PS2, como Gamecube como Xbox tienen memorias  de post-procesado que le permiten enviar varias veces la geometria ya procesada en ese momento para los efectos de multitextura que son con los que utilizamos varias texturas y las combinamos entre si. Esto es importante de cara a las cifras de los emuladores porque lo que miden realmante es la geometria en teoría enviada a través del bus GIF y en muchos casos la geometria se manda muchas veces, no se calcula varias veces sino que se encuentra en cache de post-transformación y se envia varias veces. ¿La diferencia con Dreamcast? Pues que en Dreamcast tenemos toda la geometria de la escena ordenada según su posición de pantalla en la VRAM ya que el PowerVR 2 DC es un Tile Renderer y estos son Middle Sorts porque ordenan la geometria antes del rasterizado.

Pero en el caso de PlayStation 2 es un Last Sort, los fragmentos se van procesando uno por uno con todos sus efectos y texturas asociados pero no por orden de pantalla ni de aparición sino a medida que están disponibles. Es decir, no almacenamos un bufer de la geometria de la escena sino solo de la geometria rasterizada en ese momento porque va a ser el rasterizador al final el que los ordene.

Es decir, el truco esta siempre en utilizar la memoria interna de la VU1 para almacenar la geometria resultante para poder calcular todas las operaciones de textura relacionadas con ese grupo de primitivas.  ¿Por qué es importante esto? Pues por el hecho que la mayoría de emuladores no dan las cifras de la geometria calculada por la(s) VU del Emotion Engine sino la geometria recursiva que se envia a través del bus GIF y por tanto no representa la geometria real por escena sino la geometria enviada al bus GIF.

Es por ello que los números de la geometria en los emuladores son cuanto menos un poco… falsos porque miden la geometria que se envia recursivamente a través del GIF y dado que hay juegos que utilizan multitextura un triangulo va a ser enviado varias. Eso si, hay que tener en cuenta que hay varios mecanismos en PlayStation 2 y no solo el VU1 que permiten el calculo de la geometria y el envio de datos, pero por lo general (y es lo más recomendable) la geometría recae en el VU1.

#2.5 IPU

La IPU es la Image Processing Unit, es utilizada para descodificar los bloques MPEG-2 de las peliculas DVD. En Modo PlayStation reemplaza el descodificador MPEG de la primera PlayStation por lo que tiene una conexión directa al IOP para ello. la IPU esta conectada a través del DMAC con el resto de componentes del sistema, pero al contrario que con su equivalente en la primera PlayStation no e un co-procesador cuyo uso supone que la CPU se pare en seco sino que puede funcionar en paralelo al resto de elementos del sistema. 

No tiene memoria asignada porque va descodificando los bloques que le van llegando y lo envia via PATH3 al GIF y de ahí al Graphics Synthesizer para que los muestre en pantalla. La gente piensa que gracias a la IPU el sistema puede soportar compresión de texturas y superar el limite de 4MB del Graphics Synthesizer… Quien sinceramente dice eso…

Veamos, dado que la IPU se encuentra en el Emotion Engine cuando  la textura descomprimida viaja a la memoria del GS a través del GIF entonces ya esta descomprimida y por tanto pierde todo el sentido, el otro motivo lo vais a ver cuando lleguemos a la sección de texturizado del Graphics Synthesizer.

#3 No todos los caminos llevan a Roma

Uno de los argumentos a favor de PlayStation 2 es la versatilidad, algo que es repetido por lo fanboys de la consola y que simplemente es una memez sin argumentos. Es tan poco sin argumentos que en PSP que hereda la arquitectura de PlayStation 2 decidieron colocar una unidad T&L porque incluso la versatilidad de la PlayStation 2 era algo que incluso en Sony era un problema enorme,desgraciadamente repitieron el error y maxificado en PlayStation 3 porque el ego de los ingenieros de hardware de Sony era desmesurado. Bueno, en PSP no colocaron toda la parafernialia de las dos VU y reducieron la complejidad por espacio en el chip, no por otra cosa, pero la PSP es un tema aparte que ya volvere a tratar llegado el momento.

Como habréis visto a través del EE tenemos varias formas de calcular la geometría de la escena, si utilizamos solo la FPU del R5900 entonces el rendimiento no es superior al de la primera PlayStation de cara al calculo de la geometria de la escena.

Si utilizamos lo que el complejo del R5900 (recordemo que el VU0 es un co-procesador) entonces el rendimiento es similar al que alcanzo Dreamcast en su tiempo de vida.

Basicamente en este modo toda la geometria es calculada por el VU0 y la Scratchpad RAM interna del EE es utilizada para almacenar la geometría. Desde el momento en que en este modo el VU0 funciona en modo macro es lo más parecido en funcionamiento al SH4 de Dreamcast. Y si os preguntáis lo de los 1.5 millones de Dreamcast, no es algo que yo me haya sacado de la manga. 

El tercer intento es utilizado el VU1, pero en este caso para escenas no-interactivas pero si renderizadas a tiempo real. En este modo no hay calculo dinámico de las animaciones ni las físicas del juego porque no hay juego, en este modo es donde el Emotion Engine da mayor rendimiento de todos.

Pero cuando entramo en entorno de juego entonces el rendimiento se reduce porque la combo R5900+VU0 no es lo suficientemente rapida como para animar y pre-calcular la geometria de todos esos vertices en pantalla por lo que el rendimiento se reduce.

Se dice mucho que el cuello de botella de PlayStation 2 es el Graphics Synthesizer, en realidad es el Emotion Engine y la demostración se puede ver en el emulador PCSX2 cuando se le pone a emular un supuesto Emotion Engine a mayor velocidad.

Tened en cuenta que la geometria calculada en esta etapa no son los poligonos que se van a mostrar y dependerá de la tasa de relleno de la etapa posterior, que en este caso es llevado a cabo por el Graphics Synthesizer. ¿Pero como se compara con el hardware de la época en este aspecto? Pues favorablemente muy bien.

Este es el motivo por el cual Microsoft tuvo que esperar al lanzamiento de la NV20 incluso tener que colocarle un segundo Vertex Shader para poder combatir porque en el calculo de la geometria la PS2 tenia mucha ventaja realmente. No obstante la mayoría de desarrolladores incluso en modo macro llegaron a no-utilizar bien el VU0 para el calculo de la animación y las físicas de las escenas por el hecho que suponia un trabajo adicional para muchos que decidieron prescindir de hacer, limitando la tasa de fotogramas porque el R5900 era en si mismo un enorme cuello de botella en cuanto a rendimiento. 

#4 Graphics Synthesizer

El rasterizador de PlayStation 2 es único en su especie en comparación con el resto de elementos de elementos contemporaneos, si miramos sus especificaciones técnicas veremos que a nivel de efectos especiales no es mejor en teoría queuna Voodoo a primera vista sus solo 4MB de memoria hacen pensar que son el motivo de que la calidad visual va a ser mucho más baja cuando realmente no es así. Por lo que realmente hay que entender como funciona pero al mismo tiempo no rompe las reglas de la rasterización, simplemente toma otro camino para solventar los problemas.

#4.1 Modos de Dibujado y unidad DDA (Rasterizado)

El Graphics Synthesizer tiene en realidad 3 modos de dibujado (5 si contamos los 2 sub-modos) y estos se activan cuando los registros se activan de una determinada manera y no a nivel de pantalla sino a nivel de primitiva.

  • Si se envian 3 vertices (x,y,z) sin color asociado entonces la primitiva es enviada a la unidad DDA (unidad de rasterizado) para que este la rasterice sin sombreado Gouraud.
  • Si se envian 3 vertices (x,y,z) con su color de vertice entonces la primitiva es enviada a la unidad DDA (unidad de rasterizado) para que este la rasterice utilizando el sombreado Gouraud.
  • Si la primitiva es un patrón/sprite entonces es tratada como tal.

Es decir, al contrario que otras consolas de la época tenemos que el Graphics Synthesizer si que tiene un pipeline 2D asociado al 2D ya que al contrario de otras consolas de la época cuando dibuja un patrón/sprite no lo hace pasar por el rasterizador o no utiliza triangulos para simular las escenas en 2D como ocurre con la primera PlayStation. Aparte que en modo 2D la capacidad de relleno es sumamente alta y diría que es la más alta de toda la generación con unos 2.4 Gpixeles/seg, no obstante se pueden utilizar varios trucos como es el Alpha Blending, el Bilineal, el uso del Z-Buffer para ir ordenando los patrones/sprites en diferentes capas, incluso podemos utilizar el Color Combiner para hacer blending entre patrones y sprites para ello, en realidad esto es debido al uso de los Pixel Engines y sus capacidades que veremos en la siguiente sección.

La unidad DDA es en teoría sumamente rápida como unidad de rasterizado con una supuesta tasa máxima de 75 millones de poligonos de 32 pixeles cada uno aproximadamente. ¿Cierto? Pues no y esto es una de las cosas que más me ha costado a la hora de escribir esto porque el Graphics Synthesizer por lo general es un rasterizador que bien tiene más potencia bruta que el PowerVR 2 de DC y quedaos con el termino de potencia bruta porque es importante. En realidad todo lo que rodea esta pieza de hardware es puro marketing que dura hasta nuestros días y con números que directamente son mentira y lo vais a ver en la sección siguiente que es donde explicare los Pixel Engines, por el momento quedaros con un concepto muy simple, da igual que rasterices una enorme cantidad de poligonos en la fase de rasterizado cuando en la fase de texturizado y dibujado en el buffer lo que se consigue es realmente una fraccion de eso.

En todo caso, no se me olvida que me quedan lo otros dos tipos de funcionamiento, que en realidad son dos modo para la compatibilidad hacía atrás que son rasterizar sin Z-Buffer, sin corrección de perspectiva y sin filtraje de texturas. Tenemos por un lado un modo con Gouraud y otro sin Gouraud pero estos modos solo son es solo para la compatibilidad hacía atrás.  Es decir, en modo «PlayStation» la CPU principal que es el IOP de PS2 interactua con el Graphics Synthesizer de PS2 como si fuese la «GPU» de la primera PlayStation lo que no permite la aplicación de texturizado con corrección de perspectiva, es decir, se presentan los juegos tal y como son.

#4.2 Pixel Engines

Lo primero que nos llama poderosamente la atención es que con una tasa de geometria tan bestia, la mejor idea será utilizar una gran cantidad de poligono pero de menor densidad en pixeles al ser rasterizados con tal de tener modelados más detallados.

Pero la información oficial disponible para los desarrolladores, la que encontramos en el SDK de la consola es un bofetón tras otro a un montón de mitos que se siguen sosteniendo incluso hoy en día.

Pero antes de nada tenemos que entender que son los Pixel Engines, habitualmente lo que es la unidad de texturizado y la unidad encargada de dibujar el color final de cada pixel en el bufer de imagen (o en los bufers de imagen dependiendo del caso) eran dos unidades separadas pero en PlayStation 2 tenemos uno 16 Pixel Engines que hacen ambas cosas pero con una diferencia, tardan 2 ciclos en texturizar por lo que sacan 8 pixeles texturizados de media. ¿De 8 texturas distintas? No, de una sola textura y no podemos ir más abajo y es aquí donde empiezan los problemas de rendimiento.

En primer lugar nos encontramo que el tamaño de los poligonos en pixeles afecta al rendimiento de la tasa de relleno.

Y aquí nos encontramos que dependiendo del tamaño de lo triangulos si son demasiado pequeños entonces no de aprovechan todos los Pixel Engines, lo que lleva a que la tasa de texturizado y por tanto la de relleno no sea la esperada.

Lo que significa que la tasa de los 75 millones es falsa, y no lo digo yo, lo dijo la propia Sony en su día.

El siguiente punto es como esta organizada la eDRAM de cara al texturizado, realmente los Pixel Engines no acceden a la memoria embebida sino a una cache de 8KB para el texturizado y otra de 8KB cuando se trata de generar el búfer de imagen. 

Ahora bien, dado que lo Pixel Engines solo acceden a una página de texturas tanto una textura como sus Mip Maps han de caber en esos 8KB, si acaban ocupando aunque sea un pixel por ancho o por alto otra página de texturas entonces la tasa de texturizado y con ello la de relleno se va a 1/2 y si encima los Mip Maps acaban en otra página por falta de espacio en una página de 8KB entonces la tasa de texturizado/relleno se va a 1/8 de la que tendría que ser en ese momento. Claro esta que no todo son mala noticias.

Por lo que los artistas han de subdividir las texturas grandes en otras más pequeñas e irlas enviando por fragmento.

Otro tema a tratar e que el GS soporta multitexturizado que es una forma de decir que se pueden ir combinando diferentes texturas sucesivas a base de sumar, restar o multiplicar los valores de color para crear otras texturas más complejas, hemos de tener en cuenta que el GS solo trabaja con una textura por ciclo por lo que cada combinación en el Color Combiner reducirá la tasa de relleno, pero el punto fuerte de PS2 es la enorme cantidad de tasa de relleno que en teoría tiene y aunque hemos roto lo de los poligonos pequeños para el modelado no se puede negar que tiene una gran capacidad para el multitexturizado con resultados más que sorprendentes en algunos casos. ¿Y como lo hace? Pues el GS tiene otra memoria de 8KB donde la textura anteriormente trabajada es almacenada en esa memoria temporalmente por si se combina con la siguiente textura o no para generar la nueva. Si os suena a extraterreste esto de los Color Combiners os recomiendo la entrada que hice en su día.

Los Color Combiners de PS2 tienen dos particularidades muy curiosas que los hacen únicos. La primera de ellas es que puedes rescatar como texturas lo que es el bufer de imagen previamente acumulado para efectos de post-procesado como Motion Blur, Lens Flare, esto es porque la eDRAM al contrario de Gamecube (la cual tardare en tratar) no esta divida entre eDRAM para texturas y eDRAM para bufer de imagen sino que esta todo en un bloque de memoria comun a nivel físico. ¿La otra ventaja? Peude combinar el canal Alpha Blending con el de color para el Alpha Blending (transparencias) sin tener que recortar la tasa de relleno. 

El otro punto es el filtraje de texturas, tenemos un bus de 512 bits, esto son unos 9.6 GB/s de ancho de banda, lo que significa que si el sistema soporta filtro bilineal esto on unos 2.4 Gpixeles/s pero sabemos que con el texturizado esto serían 1.2 Gpixeles/s porque la tasa es de 1/2 pixel texturizado por ciclo. ¿Cierto? Pues ese es otro bulo del marketing porque el ancho de banda de cada Pixel Engine va a depender de la información por pixel de la textura por lo que si la textura utiliza 16 bits de color entonces el ancho de banda se va a 1/2, si la textura es de 8 bits de color a 1/4. Por lo que si tuviesemo una textura con 8 bits de color el ancho de banda sería de 2.4 Gbytes/s que son 0.6 Gttexeles/s de tasa de texturizado. Es decir, cada pixel engine va a leer de la cache de texturas el pixel al que este apuntando en ese momento. 

¿Como se puede solventar esto? Pues cargando varias texturas de una misma página,s podemos cargar por ejemplo 4 texturas de 8 bits cada una asociadas a un fragmento/poligono en una misma página en vez de una de 32 y realizar la operaciones correspondientes de los Color Combiners sin tener que tirar de otra página de texturas, esto es sumamente importante para el rendimiento en cuanto a la tasa de relleno. Ahora bien el sistema esta pensado para funcionar con 32 bits de color al máximo rendimiento y se recomendaba a los desarolladores tomar ese camino por el hecho que era donde la consola marcaba realmente una diferencia enorme a nivel visual y si tenemos en cuenta que la segunda consola más potente cuando salio PS2 era Dreamcast con una tasa de relleno de 0.1 GPixeles/s entonces incluso con el rendimiento real la consola esta en este aspecto por encima de Dreamcast y puede con esa enorme tasa de relleno y los color combiners paliar las faltas en cuanto a cierto efectos por hardware respecto a otras máquinas de la época.

Trabajar con texturas de 8 bits en principio puede parecer contraproducente, pero el concepto no es trabajar con ellas sino utilizarlas como base de una textura más grande, el uso de los Color Combiners ha de superar el rango de color y de valores de las diferentes texturas y la consola esta pensada para un output de 32 bits de color, solo que en vez de conseguirse con una textura con esos datos y un tamaño enorme se consigue con una textura descompuesta en varias más pequeñas y de menos datos pero cuya composición final ha de dar el mismo resultado. Lo paradojico es que al igual que ocurre con el Emotion Engine, nos encontramos con una supuesta versatilidad de cara a los desarrolladores que se traduce en muy poco rendimiento si no se utiliza de una manera concreta por lo que la versatilidad se va a la mierda.

Gracias al hecho de ir transmitiendo las texturas al vuelo el problema de lo 4MB de memoria no es tanto pero si que lo es de cara a los bufers de imagen, Gamecube utiliza memoria embebida pero copia el bufer final (frontbuffer) en la RAM principal que bien le impide sacar efectos de post-procesado de imagen a través de un búfer de acumulación acaba el sistema por no necesitar más memoria embebida. En el caso de PlayStation 2 tanto el bufer frontal como el trasero se encuentra en la eDRAM.

¿La diferencia entre ambos? El bufer trasero es donde el GS dibuja en ese momento y almacena tanto el bufer de color como el z-buffer, el primero en formato RGBA. Como la eDRAM esta dividida en bloques de 8KB la organización es de 4KB para el Color Buffer y 4KB para el Z-Buffer. ¿Pero que ocurre con el Front Buffer? Para empezar no hay Z-Buffer por lo que ya desperdiciamos el 50% y segundo que el formato es RGB porque la A ya ha sido calculada.

Supongamos que tenemos un supuesto bufer a 640×480 (VGA) y de 32 bits, entonces esto sería:

640*480*10 (4 bytes RGBA. 3 Bytes Z,  3 Bytes RGB)= 3MB

Esto nos deja 1MB para las texturas, es posible ir transmitiendo las texturas por streaming pero esto es una sobrecomplicación a la que muchos desarrolladores no quieren llegar y prefieren que toda las texturas necesarias estén en la eDRAM, aunque el procedimiento de hacer esto no es el más adecuado realmente de cara a la calidad de imagen, pero los juegos de la primera generación de la consola hacían esto. ¿El problema?

640*480*4= 1.2 MB

La cantidad de texturas disponibles en un fotograma ha de ser las necesarias en dicho fotograma, dentro de una misma escena de un fotograma a otro apenás estas varian por lo general. Pero claro el mecanismo de streaming continuo para muchos desarrolladores era un tedio enorme. Para que la gente lo entienda, es preferible transmitir las texturas necesarias en la escena via VIF1 (PATH2) mientras se transmite la geometria y reemplazar por completo el contenido de la cache de texturas o al menos algunas páginas. El otro método era que en vez de enviar la textura se envia el puntero con la dirección de memoria a la RAM principal y el dato es pedido via PATH2 o via PATH3 al vuelo, esto permite superar el limite de memoria que tiene la consola.

Esta última técnica fue sumamente util en Gran Turismo 4 y su modo de alta resolución aunque a cambio de recibir un impacto en el rendimiento.

#4.3 Calidad de Imagen en PS2

Una de las percepciones comunes entre el público es que PlayStation 2 es menos potente que Dreamcast por su peor calidad de imagen. Este detalle me lo había olvidado y gracias a Charlietwo por recordarmelo en un comentario de esta misma entrada.

Muy buen articulo solo que no mencionaste en que consistía el bug del GS que mencionaste en el discord, lo otro es que esperaba que lanzaras alguna teoría sobre la razón de la inexplicable carencia de compresión de texturas aunque supongo que se debió a lo primitivo que era el GS en algunos aspectos.

El Graphics Synthesizer tiene dos mecanismos rotos via hardware, pero no rotos en el sentido que no funcionan sino rotos en el sentido de que no funcionan bien. El primero de ellos es el mecanismo del Edge Antialiasing, se trata de un mecanismo de AA muy primitivo que no es más que el uso de «Alpha Blending» en la aristas de los poligono para reducir levemente el dentado producido a bajas resoluciones. pues bien, Sony recomendaba no utilizar siquiera este tipo de AA aunque estaba soportado por hardware y era «gratis» Sony no recomendaba utilizarlo por el hecho que empeoraba la calidad de imagen.

Pero el problema más grande de PS2 era el llamado «Texture Shimmering» producido por el hecho que el mecanismo de Mip Mapping no funcionaba como debía funcionar y provocaba que las texturas con dicho efecto acaben emboronandose. Precisamente por este problema y el problema del recorte de la tasa de relleno a 1/8 si los Mip Maps se encuentran en otra página muchos juegos llegan a prescindir por completo del Mip Mapping, no solo por temas de rendimiento sino porque el mecanismo del mismo en PS2 esta completamente roto.

El otro tema son las texturas, el GS puede utilizar texturas paletizadas como la primera PlayStation, el truco de las texturas paletizadas es que en vez de hacer referencia directa al color en global lo que hacemos es referencia a la paleta y la posición del color de la misma. Esto nos permite definir el color de cada pixel sin utilizar tantos bits de manera directa pero requiere que la paleta de referencia este disponible en memoria. ¿Cual es el problema de PS2? Pues que la paleta no se almacena en la misma página que la textura actual porque si fuese así la tendriamos que duplicar por cada página. ¿En que se traduce esto? Pues como mínimo que la tasa de relleno con ello se reduce a la mitad, ahora bien, hay que aclarar un tema respecto a Dreamcast y es que todo el mundo dice que Dreamcast tiene ventaja por tener compresión de texturas, no, la ventaja visual de Dreamcast es porque el Mip Mapping no esta roto como en el Graphics Synthesizer de PS2 y la gente suele obviar que la compresión VQ del PowerVR2 DC son texturas paletizadas con la diferencia de que en Dreamcast el uso de estas no supone un recorte en la tasa de relleno como en el GS de PS2, pero la gente suele obviar que precisamente la enorme ventaja que tiene PS2 es precisamente su tasa de relleno mientras que Dreamcast se queda corta en ese aspecto.

Y con esto terminamos la parte del Graphics Synthesizer y con ello la entrada, ya sabéis que tenéis el Discord del blog para comentar y también tenéis los comentarios de esta entrada.