Gráficos en Consolas Antiguas (Addendum): Sega Dreamcast

Esta entrada la hago por petición popular.

dreamcast

La Dreamcast de Sega fue un salto cualitativo que dejo a mucha gente con la boca abierta por aquella época pero que desgraciadamente llego en el momento equivocado.

Arquitectura General

dcblockdiagram

CPU

Empezando por su CPU nos encontramos con un Hitachi SH4 funcionando a 200Mhz de velocidad de reloj, su potencia es equivalente  a un Pentium a 200Mhz a excepción por una pequeña particularidad, su unidad de coma flotante es mucho más potente que la de un Pentium de cara a generar la geometría de la escena e incluso que los Pentium II que se encontraban en el mercado en aquel momento, el truco estaba en la instrucción FTRV, ahora si me permitís voy a rescatar algunas de las cosas que escribí en la entrada sobre el Model 3 ya que inicialmente eso derivaba de un borrador provisional para esta entrada.

Lo que en gráficos 3D llamamos la fase de geométrica se compone de los siguientes pasos:

  1. Transferir los datos de los vertices no transformados al motor geométrico.
  2. Transformar las coordenadas de las vertices.
  3. Transformar las normales de los vertices.
  4. Iluminar los vertices, en sistemas más avanzados aquí se aplica el Vertex Shader.
  5. Comprobar la posición de los vertices y eliminar aquellos que se encuentren por detrás de otros (Clipping).

Esta lista es general para todos los sistemas 3D contemporaneos independientemente de donde se realice la geometría. El Clipping lo tacho por el hecho que forma parte del Rasterization/Binning Stage, y el primer punto también lo tacho por el hecho que es la propia CPU la que hace de motor geométrico en este caso por lo que no hace falta una transferencia.

En la entrada del Model 3 os comente la existencia de una instrucción llamada FTRV que consistía en poder multiplicar un vector de 4 componentes por una matriz de 4×4. En concreto el paso número dos. Una transformación afín de forma gráfica puede ser una rotación, un desplazamiento, un reflejo sobre otro eje, un escalado… al ser cada una de estas operaciones la multiplicación de un vector de 4 componentes por una matriz de 4×4 resulta en 16 multiplicaciones y 12 sumas, un total de 28 operaciones en total. En el caso de la instrucción FTRV de Dreamcast y sin contar la latencia la FPU de Dreamcast puede realizar una transformación de coordenadas en solo cuatro ciclos de reloj utilizando dicha instrucción, esto da unas 7 operaciones por ciclo, de ahí a que en las especificaciones técnicas del Hitachi SH4 ponga que la potencia es de 1.4 GFLOPS. Hay que tener en cuenta que la instrucción FTRV no es una instrucción específica de la transformación de coordenadas sino que simplemente se encarga de multiplicar un vector de 4 componentes por una matriz de 4×4 componentes. Los componentes de dicha matriz son cargados en 16 registros concretos, por lo que puede ser utilizados para realizar todo tipo de tranformaciones de coordenadas, ya sean rotaciones, desplazamientos… incluso concatenar varios de ellos.

Hay que tener en cuenta que la transformación de coordenadas no es la única etapa existente en lo que a la geometría de escena se refiere, y he aquí que tengo que  pedir perdón respecto a la entrada comparativa entre el Model 3 y Dreamcast ya qe dije que Dreamcast no tenía instrucciones especiales para el resto de etapas de la geometría, pues no es cierto y fue un fallo mio por no leerme bien la documentación.

Aparte de la instrucción FTRV, el SH4 dispone de otras instrucciones:

  • FIPR: Se encarga de realizar el “Dot Product” entre dos vertices (x1*x2 + y1*y2 + z1*z2 + w1*w2), dicho cálculo es utilizado durante la sub-etapa de iluminación.
  • FMAC: Este tipo de instrucción es altamente utilizada en gráficos 3D, permite calcular a*b+c en una sola instrucción, Dreamcast fue la primera consola comercial en implementar esta instrucción.

Todo esto hace que el SH4 sea capaz de realizar la transformación entera de un vértice en un proceso que va entre los 40 y los 64 ciclos.

Captura de pantalla 2015-02-17 a las 11.27.56

En principio esta cifra pude parecer mala, pero el hecho que el SH4 pudiese generar entre 3.1 y 5 millones de polígonos para enviarlos al chip gráfico era en aquella época una burrado incluso en PC y el hecho que Dreamcast fuese una consola hacía más espectacular el salto. En el gráfico de arriba el par de columnas de la izquierda es el rendimiento sin utilizar las instrucciones vectoriales, es decir, lo que podría hacer un Pentium a 200Mhz utilizando su FPU:

Ahora bien, las cifras en los juegos eran mucho más bajas que las especificadas arriba:

nulldc_1 nulldcdclem

Para empezar hay que tener en cuenta que esa cifra de 3.1 y 5 millones es con la CPU generando geometría el 100% del tiempo de la misma, tened en cuenta que esto ocurría en PC también y no hay que olvidar que cuando salió Dreamcast al mercado el juego más avanzado tecnológicamente que había para PC era el Unreal con una tasa de polígonos de 5000 por fotograma y que pedía una máquina bastante potente.

DMA y System ASIC 

El diagrama de arriba puede llevar a la confusión, ya que parece que el SH4 no tenga ningún tipo de contacto directo con el resto de componentes del sistema y que necesitaba escribir en la RAM y el resto leer de la RAM principal para sacar los datos.

sh4diagram

Al igual que con la PlayStation de Sony y al contrario que N64, la unidad DMA se encontraba en la CPU, dicha unidad DMA le servía tanto al resto de componentes para acceder a la RAM principal si les era necesario pero también servía a la CPU para comunicarse con el resto de componentes del sistema a través del System ASIC sin tener que pasar por la RAM principal, al mismo tiempo el System ASIC le da acceso a la CPU a las memoria dedicadas del resto de componentes.

RAM Principal

Dreamcast tenía unos 16MB de RAM principal del tipo SDRAM, con un velocidad de reloj de 100Mhz (dado que el bus externo del SH4 tiene dicha velocidad) y un ancho de banda de 64 bits (8 bytes), lo que daba un ancho de banda de 800MB/seg. La CPU tenía acceso directo a la misma a través de su controlador de memoria, el resto del sistema accedían a través de la unidad DMA del propio SH4 a ella.

PowerVR CLX2

El PowerVR CLX 2 es un Tile Renderer, esto significa que su funcionamiento es completamente distinto al de otras arquitecturas 3D. Es por ello que he decidido dividir esta sección en partes, cada parte pertenece a una etapa. Cuando el DAC esta leyendo el búfer de imagen lo que hace es enviar el fotograma N, la etapa de texturizado y dibujado se encarga de dibujar en el búfer trasero el fotograma N+1, el Binning Stage trabaja con el fotograma N+2 y la CPU con la geometría del fotograma N+3. Todo este trabajo lo realizan las diferentes partes de la consola de forma paralela.

#1 Geometría.

En el caso de Dreamcast y al contrario que otros sistemas la geometría tiene que ser almacenada en memoria pero… ¿Cuanto ocupa cada vertice? Teniendo en cuenta que cada uno de ellos tiene 3 coordenadas (X,Y,Z) y neecesitamos de entrada la posición y la normal, esto nos da unos 24 bytes por vertice. Pero es que además necesitamos texturizar, para ello es necesario un mapa UV para hacerlo, eso son dos componentes más y por tanto 8 bytes, todo esto hacen un total de 30 bytes por vertice.

UVMapping

Si contamos ya la iluminación del vertice que puede ser diferente en cada punta entonces nos vamos a los 38 bytes por vertice y dado que en un modelado 3D complejo un vertice forma parte de varios polígonos entonces tenemos que el número de vértices y de polígonos se acaba igualando ya que se llega al punto en qu se pueden sumar polígonos sumando vértices.

Ahora bien, dicha memoria se almacena en los 8MB de VRAM por lo que quita espacio que podrian ir para las texturas.

Polígonos por segundo Tasa de fotogramas Poligonos por fotograma VRAM Ocupada 
5.000.000 30 166.667 6 MB
5.000.000 60 83.334 3 MB
3.100.000 30 103.334 4 MB
3.100.000 60 51.667 2 MB

#2 Binning Stage

El Triangle Setup/Rasterización funciona de forma completamente distinta a un renderizador tradicional, ya que lo que hace es partir el espacio cartesiano en pequeños espacios de 32×32 pixeles llamados “Tiles” con su lista de pantalla correspondiente y su búfer de profundidad correspondiente. Estos Tiles son almacenados en la VRAM de tal manera que reserva 64 bytes por cada Tile. Si hacéis calculos veréis que 32×32 son 1024 bits y por tanto son 128 bytes y por tanto no cuadra.

¿Cual es el secreto? Pues el secreto es que Dreamcast renderiza internamente a 640×240 realmente y lo que hace es duplicar las lineas, de ahí a que cada Tile necesite solo 64 bytes. ¿Entonces como no renderizar directamente en 480? pues por el hecho que los televisores de la época no soportaban 480p60 por lo que cuando el DAC en modo televisión (15 Khz) leía la linea solo tenía tiempo para leer una y realizaba a continuación un doble salto de linea. En el caso del modo VGA (31 Khz) tenía la suficiente velocidad como para enviar la misma linea dos veces.

#3 Rendering Stage

Básicamente lo que hace en esta etapa es coger el Tile generado durante el Binning Stage, copiar en la memoria interna la parte de la textura correspondiente al Tile, operar con ella para realizar el mapeado de textura, aplicar los efectos gráficos correspondientes y copiar el resultado en el búfer de dibujado

tiling

La ventaja principal del Tile Rendering es que elimina la necesidad de grandes anchos de banda sobre la VRAM para las diferentes operacions gráficas gracias a que la única operación que se realiza sobre la VRAM es el volcado búfer de dibujado para componer la imagen final, ya que cada Tile de 32×32 pixeles es operado en una memoria interna que da el suficiente ancho de banda como para que no hayan cuellos de botella ya que son unos 3.2 GB/Seg  (1.6GB/Seg para lectura y 1.6 GB/seg para escritura) esto da por un lado para renderizar a 32 bits de color con filtro bilineal sin perdida de la tasa de relleno o a 16 bits con trilineal también sin perdida en dicha tasa de relleno que era de 100 Megapixeles, no obstante si se quería renderizar con trilineal a 32 bits la tasa de relleno se reducía a la mitad, lo cual no es malo en un sistema de 1998 porque eso pasaba también en PC.

¿La parte negativa? En primer lugar el hecho que Dreamcast no soporta múltiples muestras para texturas, esto hace que efectos que utilizarán dos muestras para ejecutarse o que necesitaran dos pasos lo que hacían era recortar enormemente la tasa de relleno, este es el gran cuello de botella que tiene la consola y el motivo por el cual la tasa de polígonos que puede dibujar sobre el búfer de imagen, que no es la misma que puede transformar, sea mucho más baja que lo que el Hitachi SH4 puede llegar a otorgarle.

¿Particularidades? La primera de ellas es la capacidad de eliminar la geometría de escena que no se encontraba visible para el jugador, aunque solo lo hace si la escena se renderiza de delante hacía atrás y la ventaja se perdía por completo si tenemos un objeto detrás de otro semitransparente ya que entonces no renderizaba el objeto que se encontraba detrás del semitransparente. Esto al contrario de otras arquitecturas que se realiza en etapas anteriores en Dreamcast se realiza en la etapa de texturizado por el hecho que es la única etapa donde se tiene acceso al búfer de profundidad que es esencial para poder realizar esta operación.

La segunda es la compresión VQ para las texturas, si queréis ver como funciona en Gamasutra tienen un excelente artículo que data de 2001. En general daba una compresión de 5:1, esto significaba que si por ejemplo nos quedaban libres contando todos los búfers unos 2MB por ejemplo entonces se convertían en unos 10MB de texturas. Pero la mayor ventaja de la compresión VQ era la de poder volcar los trozos de textura a la memoria interna a una mayor velocidad al no necesitar tanto ancho de banda

VRAM y Resolución.

La VRAM de Dreamcast es memoria SGRAM, una variación de la SDRAM que permite doble canal y por tanto que el DAC leer al mismo tiempo que el CLX2 escribe en pantalla. Su ancho de banda es de 64 bits a una velocidad de 100Mhz, por lo que es el mismo que la RAM principal. ¿Curiosidades? Pues que en el mapa de memoria de la consola hay una sección de 8MB correspondientes a una VRAM que en Dreamcast no esta pero si en Naomi y en la Atomiswave, por lo que se sabe que Sega recorto en lo que a densidad de la memoria se refiere.

Hay que tener en cuenta que la VRAM de Dreamcast almacenaba tal y como os he comentado antes:

  • Geometria. (variable)
  • Los Tiles generados durante el Binning Stage (150KB)
  • Texturas (variable)
  • Búfer de imagen (Doble).

El búfer de imagen de Dreamcast puede ser de 16 o de 32 bits y es doble. Esto significa que si un juego funciona a 640×480 y a 32 bits de color esto eran 2.4MB de la VRAM que se iban a los búfers de imagen. dejando para el resto unos 5.6MB, luego sumadle geometría y los Tiles generados durante el Binning Stage y lo que queda de todo eso es lo que quedaba para las texturas.

En fin, eso es todo.

PD: Estas entradas agotan lo suyo mentalmente.

Anuncios