Lo que vemos en pantalla lo genera un inmenso chip diseñado por Silicon Graphics llamado Reality Co-Processor (RCP), que funciona a 62,5 MHz . Este paquete encierra muchísima circuitería, así que no te preocupes si en algún momento cuesta seguirlo: el subsistema gráfico tiene una arquitectura enormemente compleja.
Este diseño parte de la filosofía de que la GPU no debe ser una 'simple' rasterizadora como la competencia. Al contrario, debe ser capaz de acelerar los cálculos geométricos (aliviando la carga de la CPU), y para ello se precisa mayor circuitería.
Arquitectura
El Reality Co-Processor se divide en tres módulos principales, dos de los cuales están dedicados al procesamiento gráfico:
Reality Signal Processor
Arquitectura del Reality Signal Processor (RSP).
También conocido como RSP, el Reality Signal Processor es un paquete CPU compuesto por :
- La Scalar Unit: Otra derivada recortada del MIPS R4000. Esta vez sólo implementa un subconjunto del set MIPS III, por lo que carece de muchas funciones de propósito general, como las interrupciones, la extensión de 64 bits, la multiplicación y la división.
- La Vector Unit: Un coprocesador que realiza operaciones vectoriales con 32 registros de 128 bits. Cada registro está dividido en ocho partes para operar ocho vectores de 16 bits a la vez (similar a las instrucciones SIMD en CPUs convencionales). Como se puede ver, este componente hace el trabajo duro de la Scalar Unit (operando además de forma concurrente con ella).
- El System Control: Otro coprocesador que proporciona funcionalidad DMA y controla su módulo adyacente, el RDP (explicado en el siguiente apartado).
Para operar el RSP, la CPU almacena en la RAM una serie de comandos llamados Display list junto con los datos a manipular. El RSP lee dicha lista y aplica las operaciones necesarias. Las funciones disponibles incluyen transformaciones geométricas (como la proyección en perspectiva), clipping e iluminación.
Puede parecer trivial, pero ¿cómo realiza estas operaciones? Aquí está la parte interesante: a diferencia de sus competidoras (PlayStation y Sega Saturn), el motor de geometría no está cableado. En su lugar, el RSP dispone de algo de memoria (4 KB para instrucciones y 4 KB para datos) para almacenar microcode : un pequeño programa de no más de 1000 instrucciones que implementa el pipeline gráfico. En otras palabras, instruye a la Scalar Unit sobre cómo procesar los datos gráficos. El microcode lo carga la CPU principal en tiempo de ejecución.
Nintendo proporcionó varios microcódigos para elegir y, al igual que los modos de fondo de la SNES, cada uno distribuye los recursos del sistema de forma distinta .
Los datos resultantes se transmiten bien a través de un bus dedicado llamado XBUS, bien a través de la RAM principal. A lo largo de la vida de la consola, esta elección fue oscilando en función de las restricciones de memoria: la vía XBUS era más rápida, pero requería búferes adicionales en la memoria interna del RSP para almacenar y transferir los nuevos datos. Sin ir más lejos, los primeros programas de microcode como Fast3D ofrecían ambas opciones. Sin embargo, el posterior y más rápido F3DEX se centró enteramente en la RAM principal. Finalmente, su sucesor, F3DEX2, reintrodujo el soporte XBUS una vez resueltos los problemas de uso de memoria.
Reality Display Processor
Arquitectura del Reality Display Processor (RDP).
Al terminar de procesar los datos, el RSP empieza a enviar comandos de rasterización al siguiente módulo —el Reality Display Processor (RDP)— para dibujar el frame.
El RDP es otro procesador (esta vez con funcionalidad fija) que incluye múltiples motores para rasterizar vectores, mapear texturas sobre polígonos, mezclar colores y componer el nuevo frame.
Puede procesar triángulos o rectángulos como primitivos; los últimos son útiles para dibujar sprites. El pipeline de rasterización del RDP contiene los siguientes bloques :
- Un Rasteriser: Convierte primitivos (formados por vértices) en píxeles.
- Una Texture Unit: Procesa texturas usando 4 KB de memoria dedicada (llamada 'TMEM'), lo que permite usar hasta ocho tiles para el texturizado. Puede realizar las siguientes operaciones sobre ellas:
- Bilinear filtering: Mapea la textura 2D seleccionada sobre la figura 3D y la suaviza para evitar zonas pixeladas (provocadas por el sobremuestreo).
- Un filtro 'completo' requeriría cuatro puntos para la interpolación; sin embargo, esta consola solo usa tres (interpolación triangular), lo que genera algunas anomalías. Por eso ciertas texturas deben 'adaptarse' previamente.
- Mip-Mapping: Selecciona automáticamente una versión reducida de la textura según su nivel de detalle. Esto evita calcular texturas grandes que se ven lejos de la cámara y previene el aliasing (consecuencia del submuestreo).
- Si está activado, el RDP mapea las texturas con trilinear filtering. Este nuevo algoritmo también interpola entre mipmaps para suavizar los cambios bruscos entre niveles de detalle.
- Perspective correction: El algoritmo elegido para mapear texturas sobre triángulos. A diferencia de otros algoritmos de mapeo inverso, este tiene en cuenta el valor de profundidad de cada primitivo, logrando resultados más fieles.
- Bilinear filtering: Mapea la textura 2D seleccionada sobre la figura 3D y la suaviza para evitar zonas pixeladas (provocadas por el sobremuestreo).
- Un Colour Combiner: Mezcla e interpola múltiples capas de colores. Como la nueva generación de la unidad de matemáticas de color, realiza sumas, multiplicaciones y restas de valores de color.
- Un Blender: Mezcla píxeles con el frame buffer actual para aplicar translucidez, antialiasing, niebla y dithering. También gestiona el z-buffering, que explico más adelante.
- Una Memory Interface: Utilizada por los bloques anteriores para leer y escribir en el frame buffer actual de la RAM y/o llenar el TMEM.
El RDP ofrece cuatro modos de operación, cada uno de los cuales combina estos bloques de forma distinta para optimizar tareas concretas.
Como este módulo actualiza constantemente el frame buffer, interactúa con la RAM principal de forma peculiar. ¿Recuerdas el inusual 9.º bit? Ese bit se usa como metadato para los cálculos relacionados con el frame buffer (z-buffering y antialiasing) y solo lo entiende la Memory Interface.
Pasos restantes
El frame resultante debe enviarse al Video Encoder para mostrarse en pantalla. Para ello son esenciales el DMA y el componente Video Interface.
Las capacidades máximas teóricas son una profundidad de color de 24 bits (16,8 millones de colores) y una resolución de 640×480 píxeles (o 720×576 en la región PAL) . Digo 'teóricas' porque aprovechar al máximo estas capacidades es muy costoso en recursos, por lo que los programadores suelen optar por especificaciones más modestas para liberar recursos para otros servicios.
Demostración rápida
Pongamos en perspectiva todo lo anterior. Para ello, tomaré prestado el Super Mario 64 de Nintendo como caso de estudio para mostrar, a grandes rasgos, cómo se compone un frame básico. Eso sí, ten en cuenta que en la práctica los juegos pueden usar búferes adicionales para componer frames más ricos.
Procesamiento de vértices
Vista primitiva de nuestra escena. Para ahorrar polígonos, algunos personajes se modelan con sprites (cuadriláteros)
Para empezar, los modelos 3D y demás recursos gráficos residen en la ROM del cartucho. Sin embargo, para mantener un ancho de banda constante, primero hay que copiarlos a la RAM. En algunos casos los datos vienen precomprimidos en el cartucho, por lo que la CPU tiene que descomprimirlos antes de usarlos.
Una vez hecho esto, toca montar una escena con nuestros modelos. La CPU podría encargarse de todo el pipeline gráfico por sí sola, pero eso llevaría una eternidad, así que muchas tareas se delegan al RCP. La CPU se limitará a enviar órdenes al RCP, lo que se lleva a cabo en los siguientes pasos:
- Componer las Display Lists con las operaciones a ejecutar por el RSP, y almacenarlas en la RAM. La estructura de las Display Lists viene dictada por el microcode elegido .
- Indicar al RSP dónde están las Display Lists.
- Cargar el microcode elegido en el RSP, poniendo en marcha la Scalar Unit.
A continuación, el RSP empieza a trabajar en el primer lote de tareas y transmite su salida al RDP en forma de comandos de rasterización.
Procesamiento de píxeles
Frame renderizado (¡Tachán!).
Hasta aquí hemos procesado nuestros datos y aplicado algunos efectos, pero todavía queda pendiente:
- Rasterizar vectores, aplicar texturas y otros efectos.
- Mostrar el frame buffer en pantalla.
Como cabe esperar, estas tareas las realiza el RDP. Además, para que funcione, las texturas deben transferirse a los 4 KB de Texture Memory mediante DMA.
A diferencia del procesador anterior, el pipeline del RDP es fijo, pero podemos elegir el modo de operación óptimo según la carga de trabajo, el rendimiento y las tareas específicas necesarias. Por ejemplo, ordenar al RDP que renderice una sola textura es más rápido que combinar dos.
Una vez que el RDP termina de procesar los datos, este escribe el bitmap final sobre la zona del frame buffer (en la RAM). Después, la CPU debe transferir el nuevo frame a la Video Interface (VI), preferiblemente usando DMA, que a su vez lo envía al Video Encoder para su visualización .
Diseños
Aquí tienes algunos ejemplos de personajes clásicos en 2D de la Super Nintendo que fueron rediseñados para la era 3D. Fíjate en el detalle de las texturas en comparación con los modelos de otras consolas de la misma generación.
Modelo interactivo disponible en la edición moderna
The Legend of Zelda: Ocarina of Time (1998).
704 triángulos.
Modelo interactivo disponible en la edición moderna
Kirby 64: The Crystal Shards (2000).
516 triángulos.
Una solución moderna para la determinación de superficies visibles
Si has leído sobre las consolas anteriores, habrás encontrado el eterno problema de la visibilidad de superficies y puede que pienses que el ordenamiento de polígonos es la única salida. Pues bien, por primera vez en esta serie, la GPU incorpora una solución por hardware llamada Z-buffering. En pocas palabras, el RDP reserva un búfer adicional (llamado Z-buffer) en memoria. Tiene las mismas dimensiones que un frame buffer, pero en lugar de almacenar valores RGB, cada entrada contiene la profundidad (valor Z) del píxel más cercano relativo a la cámara.
Tras rasterizar los vectores, el valor Z del nuevo píxel se compara con el valor correspondiente en el z-buffer. Si el nuevo píxel tiene un valor Z menor, esto significa que el nuevo píxel se sitúa delante del píxel anterior, por lo que se aplica al frame buffer y se actualiza el z-buffer. En caso contrario, el píxel se descarta.
En general, se trata de una mejora muy bienvenida: los programadores ya no tienen que preocuparse por implementar métodos de ordenamiento de polígonos por software, que consumen una cantidad considerable de recursos de la CPU. Sin embargo, el z-buffer no evita procesar geometría innecesaria (ya sea descartada o sobredibujada, en ambos casos se derrochan recursos). Para ello, los motores de juego pueden optar por incluir un algoritmo de occlusion culling que descarte la geometría invisible lo antes posible.
Secretos y limitaciones
Es evidente que SGI invirtió mucha tecnología en este sistema. Sin embargo, la Nintendo 64 era una consola doméstica y, como tal, debía mantener unos costes bajos. Algunas decisiones difíciles se convirtieron en auténticos quebraderos de cabeza para los programadores:
Atascos en el pipeline
La eliminación de los load delay slots en MIPS II, en favor de paradas automáticas del pipeline, tuvo la ventaja de eliminar la necesidad de instrucciones de relleno. Sin embargo, este alejamiento de la filosofía original de MIPS también abrió la puerta a nuevos cuellos de botella. Debido al gran número de componentes y operaciones en el pipeline gráfico, el RCP resultó ser muy susceptible a atascos excesivos: una situación indeseable en la que los subcomponentes permanecen inactivos durante períodos considerables porque los datos necesarios llegan con retraso al final del pipeline.
Esto se traduce inevitablemente en una degradación del rendimiento, y depende del programador evitarlo. Para ayudar a mitigarlo, las CPUs MIPS llevan tiempo ofreciendo el pipeline bypassing: un mecanismo que permite ejecutar instrucciones similares a mayor velocidad saltándose algunas etapas de ejecución que pueden omitirse .
Por ejemplo, si la CPU tiene que calcular instrucciones ADD secuenciales que dependen unas de otras, no es necesario volcar el resultado a un registro y volver a leerlo tras cada operación. En su lugar, la CPU puede propagar los valores a través del datapath y hacer la escritura definitiva solo cuando se haya completado el último ADD.
Memoria de texturas
El RDP depende de 4 KB de Texture Memory (TMEM) como única fuente para cargar texturas. Por desgracia, en la práctica 4 KB resultaron insuficientes para texturas de alta resolución. Además, cuando se activa el mipmapping, la memoria disponible se reduce a la mitad.
En consecuencia, algunos juegos recurrieron a colores sólidos con sombreado Gouraud (Super Mario 64 es el ejemplo más conocido), mientras que otros apostaron por texturas precalculadas (especialmente cuando había que combinar varias capas).
La salida de vídeo universal
Nintendo continuó usando la salida 'universal' Multi Out de su predecesora, aunque con una mala noticia: ¡ya no transmite la señal RGB! A mi parecer, otra medida de ahorro de costes, dado que el RGB tampoco se aprovechó demasiado en la consola anterior.
La buena noticia es que, en las primeras revisiones de la Nintendo 64, los tres canales RGB pueden recuperarse soldando algunos cables e instalando un amplificador de señal económico. Esto es posible porque el conversor digital-analógico de vídeo (DAC) todavía transmite una señal RGB al codificador de vídeo . Sin embargo, las revisiones posteriores de la placa base fusionaron ambos chips, por lo que la única alternativa viable es puentear por completo el DAC de vídeo y el codificador con circuitería personalizada que exponga las señales RGB.