Si creías que Cell, con todas sus peculiaridades, podía encargarse de cada tarea de esta consola, permíteme contarte algo hilarante: Sony incorporó un chip separado para los gráficos 3D.
Uncharted 3: Drake's Deception (2011).
The Elder Scrolls V: Skyrim (2011).
Killzone 3 (2011).
One Piece: Pirate Warriors (2012).
Parece que, incluso con un chip de superordenador, Sony tuvo que recurrir a una GPU para completar la PlayStation 3. Esto te hace preguntarte si IBM/Sony/Toshiba toparon con un muro al intentar escalar Cell más allá, y Sony no tuvo más opción que pedir ayuda a una empresa de gráficos.
Habíamos creado el equipo ICE [Initiative For A Common Engine] con la intención de desarrollar una tecnología base que pudiera compartirse entre todos los estudios propios (...) Durante un tiempo, el [PS3] no tenía GPU; se pretendía que todo corriera sobre los SPU. El equipo ICE demostró a Japón que era simplemente imposible. Habría sido ridículo. En términos de rendimiento, habría sido un desastre. Por eso finalmente añadieron la GPU, ya hacia el final .
- Fuentes anónimas de Naughty Dog
Lo que sí sé con certeza es que la PS3 incluye un chip GPU fabricado por Nvidia, diseñado para aliviar parte del pipeline de gráficos. El chip se llama Reality Synthesizer o 'RSX' y funciona a 500 MHz . Su frecuencia de reloj resulta llamativa comparada con la de Cell (3,2 GHz), aunque enseguida verás que la GPU está mejor equipada para calcular grandes cantidades de operaciones en paralelo. Se trata, pues, de encontrar el equilibrio entre Cell y RSX a la hora de construir el pipeline de gráficos (aunque debo admitir que esto suena más sencillo en teoría que en la práctica).
A continuación realizaré el mismo nivel de análisis que hice con Cell, esta vez centrado en RSX y sus capacidades gráficas.
Visión general
Han pasado cinco años desde que Nvidia presentó la gama GeForce3/NV30 en 2001, época en la que el mercado lo disputaban actores como 3dfx, S3 y ArtX/ATI. Sin embargo, en los años siguientes, el número de empresas fue reduciéndose paulatinamente hasta que, en 2006, solo ATI y Nvidia seguían siendo los principales proveedores de tarjetas gráficas en el mercado de PC.
El chip RSX junto a Cell.
El RSX hereda tecnología Nvidia preexistente; se dice que está basado en el modelo 7800 GTX para PC, que implementa la arquitectura GeForce7 (o NV47) , también denominada 'Curie'.
En mi anterior análisis del Xbox hablé de la GeForce3 y sus pixel shaders debutantes, ¿qué ha cambiado desde entonces? Ha habido altibajos, pero sobre todo cambios incrementales, sin nada demasiado revolucionario comparado con los pixel shaders de la GeForce3.
Por otro lado, mientras que el 7800 GTX usa el protocolo PCI Express para comunicarse con la CPU, el RSX ha sido rediseñado para funcionar con un protocolo propietario llamado Flex I/O , una interfaz específica dentro de Cell diseñada para conectar chips vecinos. Flex I/O opera en dos modos:
- Modo BIC para conectar otros procesadores Cell (pensado para entornos multiprocesador).
- El modo más lento IOIF para conectar hasta dos periféricos, uno 'rápido' y otro 'lento'.
Por desgracia, el RSX no es Cell, así que usa el protocolo IOIF, por la ranura más rápida.
A modo de comparación, el IOIF se comporta como un bus paralelo de 32 bits con un ancho de banda teórico de hasta 20 GB/s, mientras que el PCI Express usado en el 7800 GTX (x16 1.0) es un bus serie de 16 bits con un ancho de banda teórico de hasta 4 GB/s.
Organización del contenido
El RSX tiene a su disposición 256 MB de GDDR3 SDRAM dedicada. Sorprendentemente, es el mismo tipo de memoria que se encuentra en la Wii. El bus de memoria opera a 650 MHz con un ancho de banda teórico de hasta 20,8 GB/s.
Ejemplo de cómo se organizan los datos en la memoria disponible. Fíjate en cómo el RSX puede acceder a su contenido desde distintos chips de memoria.
En esos 256 MB, Cell puede colocar todo lo que RSX necesitará para renderizar un frame: datos de vértices, shaders, texturas y comandos. Además, gracias al bus Flex I/O de Cell, RSX también puede utilizar los ya mencionados 256 MB de XDR DRAM (la RAM principal de la CPU) como espacio de trabajo, aunque con ciertas penalizaciones de rendimiento. Esto resulta práctico cuando, por ejemplo, el frame renderizado vaya a ser postprocesado por un SPU.
Como puedes ver, aunque esta consola no implementó una arquitectura UMA, sigue siendo posible distribuir los datos gráficos entre distintos chips de memoria si los programadores así lo deciden. Lo menciono porque ojalá muchos de los 'explicadores técnicos' se informaran más sobre esta característica antes de soltar afirmaciones demasiado simplistas como «la PS3 era limitada porque no tenía UMA». Puede que eso sea cierto en ciertos casos, pero si no se mencionan estas particularidades, esa afirmación genérica es, en mi opinión, engañosa.
Por último, RSX admite muchas formas de optimización de datos para ahorrar ancho de banda; entre ellas, la compresión de color 4:1, la z-compression y el modo 'tiled' (lo explicaré con más detalle más adelante).
Construyendo un frame
Veamos ahora cómo procesa y renderiza escenas 3D el RSX.
Visión general del pipeline del RSX.
Su modelo de pipeline es muy similar al de la GeForce3, pero potenciado con cinco años de progreso tecnológico. Por eso recomiendo leer ese artículo primero, ya que este se centrará en las novedades; también es recomendable leer sobre la GPU de la PlayStation Portable, porque muchos de los nuevos desarrollos y necesidades coinciden con ese chip. Dicho esto, veamos qué tenemos aquí...
Comandos
Diagrama de la etapa de comandos.
Como en cualquier otra GPU, debe haber un bloque de circuito encargado de recibir las órdenes del exterior. En el RSX, esto lo gestionan dos bloques: Host y Graphics Front End.
El Host es el responsable de leer los comandos de la memoria (local o principal) y traducirlos en señales internas que comprenden los demás componentes del RSX; esto se realiza mediante cuatro subcomponentes:
- Pusher: lee los comandos gráficos de la memoria e interpreta las instrucciones de ramificación. También contiene 1 KB de prefetch buffer. Los comandos procesados se envían al FIFO Cache.
- FIFO Cache: almacena hasta 512 comandos decodificados por el Pusher de forma FIFO para proporcionar acceso rápido.
- Puller: como su nombre indica, extrae comandos del FIFO Cache cuando el RSX está listo para renderizar y los envía a la siguiente unidad.
- Graphics FIFO: almacena hasta ocho comandos que serán leídos por el Graphics Front End.
El Graphics Front End lee del Graphics FIFO y señaliza a las unidades necesarias dentro del RSX para que ejecuten las operaciones. Como recordarás, esto es equivalente al 'pfifo' de la GeForce3.
Como puedes ver, los comandos y datos pasan por múltiples buffers y cachés antes de llegar a su destino final. Esto es intencionado, ya que evita que el pipeline se detenga cuando distintas unidades y buses operan a diferentes velocidades. Así, la memoria en caché aprovecha el ancho de banda rápido siempre que es posible.
Vertex Shader
Diagrama del proceso de la etapa de vértices. Fíjate en que los Vertex Processing Engines (VPE) se omiten si los vértices no necesitan procesamiento adicional por parte del vertex shader.
La siguiente unidad es el bloque de Geometry Processing, una evolución del 'Vertex Block' de la GeForce3 que realiza la transformación de vértices. Sigue siendo programable mediante vertex shaders, una función ya ampliamente adoptada en la industria gráfica. Además, el límite de instrucciones se ha elevado a un mínimo de 512 (¡originalmente el límite era de 136!).
El bloque que ejecuta los shaders se llama Vertex Processing Engine (VPE) y puede procesar un vértice por ciclo de reloj. Por si fuera poco, hay ocho VPE trabajando en paralelo. Desde la serie GeForce6, Nvidia ha alineado su interfaz de programación de shaders con un modelo llamado 'Vertex Shader Model 3' o 'vs_3_0', un estándar desarrollado por Microsoft para sus librerías DirectX 9.0c . Los VPE también son compatibles con el modelo no propietario OpenGL 2.1 y la variante propia de Nvidia (Cg) .
Respecto a la GeForce3, disponemos de nuevas instrucciones para ramificaciones y llamadas a subrutinas. Además, el VPE incorpora cuatro samplers de textura que extraen colores de textura en esta etapa, por si los programadores quieren realizar operaciones sobre ellas en este bloque.
El bloque de Geometry Processing funciona de la siguiente manera:
- El Index Vertex Processor (IDX) lee y cachea datos de vértices y texturas de la VRAM; después, envía los datos al VAB.
- El Vertex Attribute Buffer (VAB) extrae datos de la caché del IDX y los redirige a cada VPE.
- Cada VPE procesa los datos según el shader cargado. Este calcula una instrucción de shader por ciclo de reloj.
- El resultado de cada VPE se envía al Post Transform Cache, que cachea los resultados para omitir cálculos idénticos sobre el mismo vértice. Esto solo aplica si se usan índices de vértice en lugar de datos de vértice.
- El resultado final se almacena en el Viewport Cull Unit (VPC), que aplica recorte para descartar vértices fuera del viewport, y en la Attribute RAM (ATR), que cachea los atributos de vértice (textura, color, niebla, etc.) para ser leídos en las etapas siguientes.
Rasterización
Diagrama simplificado de la etapa de rasterización. El RSX integra distintas unidades para calcular los valores usados en la interpolación de píxeles y colores.
A continuación, toca convertir (rasterizar) los vértices en píxeles. El rasterizador del RSX es bastante rápido: puede rasterizar hasta 8×8 píxeles (64) por ciclo y trabaja con frame buffers de hasta 4096×4096 píxeles (aunque los desarrolladores suelen necesitar bastante menos).
El rasterizador acepta puntos, líneas (incluyendo strips y tipos cerrados), triángulos (incluyendo strips y fans), cuadriláteros y polígonos regulares. Como es habitual en esta generación de consolas, el rasterizador trabaja con coordenadas de subpíxel, donde los puntos de muestreo son semipuntos (0,5) de los píxeles. Esto permite a la unidad aplicar posteriormente métodos de antialiasing como el Multisampling. El Multisampling consiste en rasterizar la misma geometría varias veces pero desplazando unos pocos subpíxeles en cada pasada (el RSX admite cuatro modos de desplazamiento distintos) y luego calcula la media, lo que produce una imagen más suavizada.
Además, esta unidad también realiza z-culling mediante RAM dedicada dentro del RSX (con capacidad para unos tres millones de píxeles). Esto evita procesar píxeles y stencils ya renderizados y permite realizar el early z-test sobre la geometría entrante.
Para rasterizar objetos 2D (sprites) se usa una unidad separada, aislada del pipeline 3D. En consecuencia, el RSX opera en dos modos, 2D y 3D, pero alternar entre ellos con frecuencia tiene un coste notable en cuanto al rendimiento.
Pixel Shader
Diagrama de la etapa de píxeles/fragmentos.
A continuación tenemos el bloque Fragment Shader & Texture, una unidad programable (mediante 'fragment programs' o 'shaders') que aplica el mapeado de texturas y otros efectos.
Como sucesor avanzado de las unidades de textura de la GeForce3, el nuevo bloque contiene seis fragment units (también llamadas 'pipes'), cada una de las cuales procesa texels de 2×2 (denominados 'quads'). Para organizar el trabajo concurrente de varias unidades, se incluye otro subcomponente llamado Shader Quad Distributor (SQD) que distribuye los quads a cada fragment unit. Después, cada fragment unit carga el fragment program.
Para ejecutar operaciones, cada pipe contiene la enorme cantidad de 1536 registros de 128 bits. Además, cada pipe puede procesar varios quads en paralelo (multi-threading), aunque el número de quads procesados en paralelo depende del número de registros asignados al fragment program (n.º de threads = 1536 ÷ n.º de registros reservados por el shader). En conjunto, pueden procesarse hasta 460 quads en paralelo. Además, hasta tres fragment pipes pueden procesar dos instrucciones al mismo tiempo (dual-issuing, como el PPU), siempre que las instrucciones no dependan entre sí.
Las fragment units ofrecen instrucciones aritméticas similares a las de la vertex unit, con la incorporación de opcodes relacionados con texturas, como múltiples tipos de lectura de texturas (ya que pueden codificarse con muchas estructuras y luego comprimirse) y desempaquetado. Al igual que el bloque de vértices, el fragment shader sigue el modelo Pixel Shader 3.0 de DirectX , el perfil NV_fragment_program2 de OpenGL y el perfil 'fp40' de Cg . Todo ello para facilitar la programación y evitar tener que aprender APIs de bajo nivel desde cero.
Por último, dado que las unidades estarán constantemente leyendo fragmentos de texturas desde la VRAM o la RAM principal, este bloque incluye tres cachés de texturas: 4 KB de caché L1 por pipe, 48 KB de caché L2 para lecturas de VRAM; y 96 KB de caché L2 para la RAM principal. Ten en cuenta que la caché de RAM principal es considerablemente mayor: fue una decisión deliberada para compensar la mayor latencia.
Operaciones de píxel
Etapa de postprocesado.
Antes de escribir los resultados en el frame buffer (almacenado en VRAM o en RAM principal), un bloque final llamado Raster Operation Block (ROP) realiza las comprobaciones definitivas sobre los píxeles resultantes.
Hay dos conjuntos de ROP compuestos por cuatro bloques cada uno (ocho en total). Cada grupo realiza z-testing, alpha blending y la escritura final en memoria. En conjunto, este circuito puede procesar hasta 16 valores Z y 8 colores de píxel por ciclo. Curiosamente, la variante para PC Nvidia 7800 GTX tiene 16 ROP en lugar de 8; ¿quizás ese recorte se hizo para priorizar el ancho de banda de memoria consumido por los SPU?
Para ahorrar aún más ancho de banda, los ROP también ofrecen compresión de color y z-compression. Además, existe un modo Tiling para optimizar el acceso a memoria del codificador de vídeo. En este modo, el frame buffer se almacena en bloques continuos de 128 B ordenados de la misma manera en que se emitirían/escanearían. Esto evita que la GPU realice intercambios de páginas (usados para el direccionamiento de memoria) mientras transmite el frame buffer para su visualización, mejorando así el ancho de banda. Estos 'tiles' se almacenan en ubicaciones marcadas de la memoria, exclusivas para este tipo de direccionamiento.
Una salida de vídeo unificada
Se acabaron los días de los conectores de vídeo propietarios de cada consola y las docenas de señales analógicas comprimidas en un único conector para adaptarse a cada región del planeta. El PlayStation 3 incorporó por fin una señal de vídeo unificada que pronto sería adoptada en todo el mundo: la High Definition Media Interface (HDMI), utilizada para transferir audio y vídeo al mismo tiempo.
Parte trasera de la PS3: la salida HDMI a la izquierda y, en el otro extremo, el antiguo Multi A/V para la salida de vídeo analógico.
El conector HDMI consta de 19 pines , todos en un único conector. Transmite una señal digital, lo que significa que la imagen y el audio se emiten mediante ceros y unos discretos (y no mediante un rango de valores continuos como en las señales analógicas). Por tanto, no sufre las interferencias ni la degradación de imagen que padecían los equipos anteriores, como los artefactos en pantalla provocados por cables SCART de mala calidad.
Aún hoy, el protocolo HDMI se revisa continuamente , con nuevas versiones de la especificación que ofrecen más funciones (mayor resolución de imagen, tasa de refresco, espacios de color alternativos, etc.) manteniendo el mismo soporte físico para garantizar la retrocompatibilidad.
A lo largo del ciclo de vida de la PS3, Sony añadió mediante actualizaciones de software ciertas funciones HDMI de nuevas revisiones . El último protocolo compatible con la PS3 es la versión 1.4, que incorporó de forma destacada el soporte para la 'televisión 3D'. Sin embargo, otras capacidades, como resoluciones de vídeo superiores, quedaron limitadas a 1920×1080 píxeles, con la mayoría de los juegos renderizando sus frame buffers a tan solo 1280×720 píxeles.
Visión 3D 'real'
¿Y qué era esa 'televisión 3D' que mencioné antes? Resulta que la vida útil de esta consola coincidió con una breve fiebre de televisores 3D (los llamados 3DTV) . Para soportarlos, Sony actualizó su SDK para asistir el renderizado de frames estereoscópicos en RSX e implementó la 'especificación 3D' en su codificador HDMI. Lo que ocurre entre bastidores es que el codificador emite dos frames al mismo tiempo, y el televisor los alterna de forma similar a lo que hacían las gafas 3D del Master System treinta años antes.