En realidad, no teniamos pensado volver a escribir esta entrada hasta de aquí bastante tiempo, al menos hasta que los artículos de Hardware Clásico de PlayStation 2 y PlayStation 3 fueran escritos. Sin embargo, una de las historias más fascinantes es la del chip gráfico que iba a tener originalmente la PS3 y que fue reemplazado en la última hora por el NVIDIA RSX. Estamos hablando del llamado «Visualizer». Si queréis saber al detalle cómo iba a ser dicho chip gráfico, entonces, seguid leyendo.
La patente Suzuoki: el origen del nombre Visualizer
Allá por el año 2003, en internet apareció una patente a la que se la llamó coloquialmente como la «patente Suzuoki» y donde explicaba el concepto del Cell Broadband Engine para la futura PlayStation 3, mostrando con ello varias configuraciones distintas, para diferentes tipos de dispositivos. La idea por aquel entonces por parte de Ken Kutaragi y el resto de ingenieros en Sony Computer Entertainment era la de crear una arquitectura que la empresa nipona pudiese utilizar no solo en una consola de nueva generación, sino también en todo tipo de dispositivos. Ya de entrada, lo que llama poderosamente la atención es un diagrama que nos recuerda mucho a la arquitectura final de la CPU de PS3.
No obstante, lo que es interesante de dicha patente no es el chip que Sony al final usó como CPU de su PS3, sino más bien aquel que no llegó a fabricarse jamás, pero que se encontraba relatado en la misma con su diagrama y todo como chip gráfico, pero utilizando las APU/SPU/SPE junto a unidades de función fija típicas de una GPU.
La misma patente nos dice:
La FIG. 5 es un diagrama ilustrativo de la estructura de un «Processor Element», el Visualizer (VS) y una interfaz óptica de acuerdo con la presente invención».
…
Por el otro lado, un procesador puede tener la estructura de un Visualizer (VS) 505. Tal y como se muestra en la FIG. 5, el VS 505 esta compuesto por PU 512, DMAC
514 y cuatro APU llamadas APU 516, APU 518, APU
520 y APU 522. El espacio ocupado por las otras cuatro APU esta ocupado en este caso por el pixel engine 508, image cache 510 y un controladorCRTC 504.
El trabajo de las APU/SPE según la patente
Uno de los puntos clave del Cell Broadband Engine son los SPE/APU, los cuales desde cierto punto de vista son una evolución de las unidades VU0 y VU1 de la cPU PlayStation 2. Dichas unidades le dieron a la consola de Sony una enorme potencia en coma flotante a la hora de manejar vectores, lo cual era ideal para unas altas tasas de geometría. El nombre de Emotion Engine vino por el hecho de que empezó a ser posible modelar personajes con facciones complejas a través del modelado poligonal en comparación con la generación anterior.
Sin embargo, Sony decidió reemplazar en PlayStation 3 las VU por un tipo nuevo de unidades, los llamados SPE. Al igual que los VU seguían siendo DSP con una memoria local extremadamente rápida, pero funcionando a una frecuencia 10 veces superior, siendo 8 en vez de dos y teniendo un set de registros e instrucciones que lo hizo mucho más versátil. En la tercera consola de sobremesa de Sony, se convirtieron en un navaja suiza y la patente Suzuoki nos dan dos ejemplos de su uso para el formato doméstico. Uno de ellos revela el motivo por el cual el chip se llamó bajo el nombre de Broadband Engine.
El concepto detrás de los SPE es que estos solo pueden acceder a su propia memoria local, y ha de ser otro procesador externo el que los nutra, por lo que los programas que ejecuta cada SPE están aislados, pero se puede dividir un problema en varias partes y hacer que cada SPE se encargue de una fracción del mismo. También se puede crear un pipeline donde cada SPE trabaja en una parte del problema o hacer que cada uno de ellos realice una tarea distinta. Precisamente, en la patente Suzuoki dan dos aplicaciones totalmente domésticas para los SPE en el Visualizer o en el CBEA.
Cálculo de la geometría de la escena
Dado que en HARDVERSO todavía no hemos tratado cómo funcionan los gráficos en 3D vamos a realizar un pequeño inciso, al menos de lo que es el World Space Pipeline, el cual hace referencia a las distintas etapas del mismo.
| Etapa del Pipeline | ¿Se Genera una Lista? | ¿Qué Se Genera? |
|---|---|---|
| 1. Model Transformation | ❌ No | Se crean vértices transformados (el objeto cambia de tamaño, posición o rotación). |
| 2. World Transformation | ❌ No | Los vértices se colocan en la escena global (posición en el mundo 3D). |
| 3. View (Camera) Transformation | ✅ Sí | Se genera una lista de vértices desde la perspectiva de la cámara (cómo «ve» la cámara la escena). |
| 4. Projection Transformation | ✅ Sí | Se crea una lista de coordenadas en 2D tras aplicar la proyección en perspectiva u ortográfica. |
| 5. Clipping y Culling | ✅ Sí | Se filtra la escena, generando una lista de primitivas visibles (triángulos que se van a dibujar). |
| 6. Viewport Transformation | ✅ Sí | Se ajustan los vértices al tamaño de la pantalla (lista final de vértices en coordenadas de pantalla). |
| 7. Rasterization (Rasterizado) | ❌ No | Aquí ya no hay listas, los datos se convierten en píxeles en la pantalla (imagen final). |
Tenemos 4 listas de pantalla referentes al World Space Pipeline que se generan para las etapas posteriores, siendo la última la del Viewport Transformation. Esto nos ayudará a entender mejor la FIG. 27 de la propia patente Suzuoki. Donde cada SPE se encarga de realizar internamente las etapas de transformación geométrica hasta un punto, para luego pasarle las listas de pantalla al SPE final.
Si bien no nos los especifica la patente, tenemos sospechas para pensar que inicialmente tanto Sony como Toshiba querían implementar un Tile Renderer en los SPE, aunque no hubiese funcionado por función fija, sino a través de un programa ejecutado por los propios SPE, dando la versatilidad de usarlo o no. La diferencia es que en un Tile Renderer tras el Viewport Transform no se genera una lista de pantalla única para ser rasterizada en un bloque, sino que se divide la escena en tiles y se transforma por bloque, luego cada tile se procesa y rasteriza individualmente.
El Blu-ray no estuvo inicialmente en los planes
Otra de las funcionalidades que PlayStation 3 iba a heredar de su antecesora era la capacidad de ver películas y series, sin embargo, el boom de internet y la inminencia de la banda ancha ya apuntaban a lo que hoy en día es común con los servicios de streaming. Pues bien, en la misma patente Suzuoki podemos ver referencias a una época en la que el Blu-Ray no era todavía un objetivo de Sony y tenían muy claro que el futuro de la distribución del contenido audiovisual sería a través de internet. En concreto en la FIG. 26B donde se nos relata como los SPE podrían usarse para decodificar y reproducir vídeo.
La clave aquí es que la información no se recibe a través de una unidad de disco, sino como paquetes TCP/IP, lo que nos indica que estos llegan desde una red, la cual puede ser local o directamente desde internet. Esto es típico en aplicaciones como servicios de streaming, videollamadas o cualquier sistema que necesite enviar video en tiempo real. Por si muchos no lo sabíais, el motivo por el cual el Cell se llama Cell Broadband Engine era por el hecho de que Sony tenía muy claro que el futuro de la distribución de música, vídeo y videojuegos iba a ser por internet ya por el año 2001, año en que se escribió la patente Suzuoki, uno antes de la presentación oficial del Blu-Ray.
El Visualizer más allá de la patente Suzuoki
Hace unos años, quien escribió esto que estáis leyendo le dio por hacer una pequeña investigación mirando una serie de patentes relacionadas entre sí. Todas ellas relacionadas con Toshiba, quien fue socio de Sony para el desarrollo y fabricación de los chips de PlayStation 2 y el tercer participante en el consorcio STI que dio a la luz al Cell Broadband Engine. Dicho de otra forma, mientras que Sony e IBM andaban realizando lo que era la parte de la CPU correspondiente al nuevo sistema, a Toshiba le tocó realizar lo que inicialmente iba a ser la GPU de la consola.
De todo ello, tenemos varias patentes relacionadas entre sí, las cuales son las siguientes:
- Image rendering method and image rendering apparatus using anisotropic texture mapping
- One-chip image processing apparatus
- Graphic rendering apparatus which parallel-processes pixels at a time
Las tres patentes tienen varias cosas en común: fueron asignadas a Toshiba, si no que además comparten inventores y diagramas, entre ellas. La forma de encontrar la información fue cruzando nombres relacionados con el desarrollo del Graphics Synthesizer, el chip gráfico de PS2. No obstante, las patentes no describen una GPU completa, sino solo para las etapas propias del Screen Space Pipeline, desde el rasterizado hasta el dibujado de los píxeles en el búfer de imagen.
Por lo que, de entrada, existían dos formas distintas de enfocar el problema. Por parte de Toshiba, los SPE/APU encargados de la geometría eran los mismos en la CPU. En cambio, por parte de Sony, el Visualizer tenía que llevar consigo sus SPE/APU para calcular la geometría, dejando libre a los de la CPU para sus trabajos. Por lo que las partes del Visualizer de las que se habla en las patentes de Toshiba son el Pixel Engine, la Image Cache y el CRTC Controller, es decir, la salida de vídeo.
¿Una evolución desde PS2?
El primer error es suponer cosas sin comprobarlas. Para muchos se supone que el Visualizer iba a funcionar de la misma manera que el Graphics Synthesizer, es decir, usar una memoria embebida a lo bestia para los búfers de imagen y las texturas de la escena. Sin embargo, el diseño guarda una serie de avances de la época respecto al chip gráfico de la segunda consola de Sony que son interesantes de ver. Por lo que empezaremos por la memoria embebida y su organización.
Para empezar hemos de hablar de la organización del búfer de imagen (color y profundidad) es por lo que la patente llama stamps, donde cada uno de ellos es de 4 x 4 píxeles y se asigna a uno de los 32 núcleos de la GPU o Pixel Engines. Esto ya es una pista de que estamos ante un Tile Renderer, al mismo tiempo no se asigna todo el búfer de imagen de golpe a las unidades, sino que esta es generada en orden por bloques de hasta 32 bloques, una forma muy común del renderizado por tiles que evita además tener que trabajar con todo el búfer de imagen y el atlas de texturas en la memoria embebida. Claro, está que mirando la patente; desconocemos la configuración de memoria que hubiese tenido.
En cuanto al atlas de texturas, este, al igual que en el de PlayStation 2, contiene las texturas de la escena actual, es por ello que su tamaño equivale a la resolución de pantalla. Por cierto, aclarar que no sabemos cuál hubiese sido la resolución de pantalla, pero no podemos descartar que internamente tanto Sony como Toshiba ya se plantearan alcanzar resoluciones por encima de lo que podían mostrar los clásicos televisores CRT.
Un inciso, el GSCube
Para hacernos una idea de lo que podría haber sido el Visualizer a nivel de rendimiento, haremos un viaje al año 2000. Justo antes de que IBM se sumará a la fiesta y con Sony y Toshiba como el tándem de cara a las futuras generaciones de lo que eran el Emotion Engine y el Graphics Synthesizer, se presentó una hoja de ruta, la cual al final no se cumplió por ser demasiado ambiciosa e irreal. Pensad que no habla de consolas, sino de estaciones de trabajo para la creación de contenido audiovisual, no solo en videojuegos, sino también en el cine.
Sin embargo, una de las quejas más importantes de los desarrolladores respecto a PlayStation 2 es que la arquitectura era demasiado exótica para el desarrollador de PC medio, por lo que Sony, se le ocurrió la idea del GSCube, un superordenador de la época compuesto por 16 placas con un Emotion Engine y un Graphics Synthesizer cada una, pero con cambios en la memoria, dado que cada EE tenía 128 MB de memoria y el GS 32 MB de memoria embebida, en vez de los 4 MB de la consola.
La idea era poder hacer prototipos de lo que iban a ser los futuros videojuegos para una generación posterior a PS2, sin embargo, el diseño es, previó a la implementación de los Shaders programables por parte de NVIDIA, por lo que la idea cayó en el olvido y forzó a Sony a evolucionar al menos el hardware gráfico de su diseño para ponerse al día en ese aspecto.
La presentación del SIGGRAPH 2000
En el SIGGRAPH del año 2000, Criterion Games, cuyo motor gráfico, Renderware, era el más popular de la época, realizó una demostración técnica de las capacidades del GSCube en el SIGGRAPH 2000. No fue la única demostración, ya que también se vieron escenas de la película de Final Fantasy renderizadas por el GSCube y una demo en 3D de The Matrix. Básicamente como adelanto a lo que iba a ser la siguiente generación por aquel entonces, la cual veinte años después nos sigue pareciendo tan lejana.
Sin embargo, lo que nos llama poderosamente la atención es la demostración técnica basada en la película Antz/Hormigaz que hizo Criterion Games, la cual mostraba 14 hormigas compuesta cada una de ellas por 7000 polígonos en un mundo complejo de más de 1 millón de polígonos por frame a una tasa de 60 FPS y siendo renderizados a 1920 x 1080. Pensad que hablamos de una demostración técnica del año 2000. Por lo que la idea de ir a lo que hoy en día llamamos Full HD ya estaba ahí, en los planes de Sony y Toshiba.
¿El Visualizer iba a utilizar eDRAM o se trata de un mito?
Una entrevista realizada por Hiroshige Goto en el año 2005 a Ken Kutaragi nos da un contexto claro sobre lo que iba a ser el Visualizer para PlayStation 3 y el uso de eDRAM o memoria embebida en el sistema, en palabras del propio padre de la PlayStation:
En ese caso, la eDRAM no es viable. Usar eDRAM estuvo bien en PS2, pero esta vez, incluso con solo dos pantallas, no es suficiente. Si se tratara de incorporar suficiente eDRAM para soportar HDTV, en un chip de 200 mm² o 300 mm², el área de eDRAM reduciría drásticamente la lógica que podríamos integrar, lo que disminuiría el número de shaders. Es mejor usar toda esa área para la lógica y montar más shaders.
Y Kutaragi sigue teniendo razón, es por ello que creemos que Toshiba y Sony se dieron cuenta y plantearon al Visualizer como un Tile Renderer, para no tener que almacenar toda la información del búfer de imagen. Es decir, el Visualizer hubiese tenido la capacidad de tener su propio pozo de memoria o tener una comunicación directa con la RAM principal como ocurre en PS2. Es más, en la misma entrevista, Kutaragi habló de que se planteó dicha posibilidad.
Originalmente, aunque la GPU no tuviera memoria gráfica, se podría haber manejado con Redwood (la interfaz de alta velocidad que conecta Cell y RSX) y YDRAM (código de nombre XDR DRAM). YDRAM está configurada como memoria unificada.
Sin embargo, aún así, cuando se realizan procesos gráficos convencionales o cálculos de shaders, hay un problema al acceder a la memoria en ubicaciones distantes (gastando innecesariamente ancho de banda y ciclos de tiempo). No queremos desperdiciar el ancho de banda de la memoria de Cell en tareas convencionales. Los shaders, por su parte, realizan una enorme cantidad de cálculos, por lo que también necesitan memoria. Especialmente cuando tratamos con Full HDTV y queremos manejar más de dos pantallas 2k×1k (1,920×1,080 píxeles) progresivas, se necesita una gran cantidad de VRAM.
De ahí a que pensemos que, llegado a un punto, la idea evolucionó a la de un Tile Renderer, ya que no vieron viable empezar a sacrificar rendimiento por memoria embebida.
Volviendo al Visualizer: el Pixel Engine
Una vez hemos creado el contexto, hemos de entender que el objetivo inicial por parte de Toshiba con el Visualizer era crear una máquina capaz de tener las tasas de relleno y texturizado del GSCube, pero en un chip doméstico. El salto en resolución ya supone un aumento en la tasa de relleno considerable, pero la base ya era un x16 si no había cambios en la frecuencia de reloj a la que funcionaría el Visualizer respecto al Graphics Synthesizer. Si bien las patentes del VS afirman que estaba compuesto por hasta 32 núcleos de GPU desde nuestro punto de vista, eso era una cifra máxima y en el hardware final hubiese sido bastante más baja.
Tenemos una sola unidad de rasterizado, pero hasta 32 núcleos de GPU, donde cada uno de ellos se encuentra compuesto por las siguientes unidades:
- Una unidad de texturas capaz de realizar filtro bilineal en un solo ciclo, para ello trabaja con 4 téxeles simultáneos, esto una tasa de texturizado 16 veces superior y que coincide con la del GSCube.
- El RC es la unidad que se encarga de leer el contenido de la Local Memory (LM) la cual almacena la información de los búferes de imagen y las texturas correspondientes al fotograma actual, incluyendo los Mip Maps. Cuando se trata de pasar una porción de una textura de la memoria local (LM) a la unidad de texturas, esto se hace con un bus paralelo de solo lectura llamado TBUS. Cada LM almacena la información correspondiente a su grupo de píxeles asignado.
- El RPC (Realize Pipe Cluster) se encuentra compuesto por 4 Realize Pipes, siendo cada una de ellas una unidad SIMD de 32 bits compuesta por 4 unidades de enteros de 8 bits con capacidad MAC (Suma y multiplicación en un ciclo) asignada cada una de ellas a uno de los téxeles.
Por lo que, a nivel de complejidad de los Pixel/Vertex Shaders, esto equivaldría más o menos a lo que tenía la primera Xbox gracias al NV2A de NVIDIA, pero con una cantidad ingente de unidades por el hecho de estar pensada originalmente para una resolución Full HD. Ahora bien, aunque es totalmente especulatorio por nuestra parte, creemos que la cantidad de unidades en el chip final hubiese dependido de la frecuencia que hubiese alcanzado el chip. Por desgracia nunca sabremos ese detalle.
El final del Visualizer para PlayStation 3
¿Qué llevó a Sony a cancelar el Visualizer y optar por un camino distinto? Pues hay varios factores, uno de ellos es que en la primera mitad de la década de los 2000 el avance de las GPU fue tan rápido que muy pronto el diseño del Visualizer quedó desfasado en comparación con otras opciones. No obstante, el dia D para el Visualizer fue el 27 de abril de 2004, fecha en que se filtraron las especificaciones de lo que terminó siendo Xbox 360, lo que le dejó claro a Sony lo atrasada que se encontraba en ese momento respecto a la GPU de su rival. Por otro lado, IBM había pujado en fechas cercanas para ser el fabricante de las NV40/GeForce 6×00, pero al final se lo terminó llevando dicho contrato TSMC.
Al final, Toshiba fue la gran derrotada en la historia del nunca lanzado Visualizer, no solo por el hecho de que su diseño no fue el escogido, sino porque su propuesta como formato óptico para la alta definición, el HD-DVD se vio derrotada en el proceso por el Blu-ray.
