Desmitificando el Sega Model 3 (Versión Corregida)

Comentario Original:

Nuévamente información que desconocía y bien planteada; gracias de nuevo por tu generosidad Urian.

Sin embargo lejos de desmitificarme el Model 3, me has reafirmado más en mi postura: NAOMI no consiguió superar a la tercera generación de los “Model”, muchísimo menos un sistema con la mitad de RAM y limitado por un soporte óptico sin memoria adicional como era/es DREAMCAST, si bien si limaron muchas de las asperezas

De entrada los M3 tienen un mínimo de 23 MB de V-Ram, 8 en exclusiva para texturas, mientras que Dreamcast tiene 8 PARA TODO, contando con que el Model 3 no gasta RAM en datos de programa que puede leer directamente desde un slot ROM, mientras que Dreamcast tiene que volcar TODO lo que le quepa desde el GD-Rom y a dar el tipo lo mejor que pueda.

No creas que mi entrada de ayer era perfecta sino más bien precipitada y llena de errores, suelo buscar documentación de lo que escribo pero últimamente me pasa que acabo teniendo documentación mucho mejor en la que basarme posteriormente a la escritura del artículo y que lo acaba tirando por la borda, es por ello que he decidido eliminar el artículo anterior pero como habrás visto he mantenido tu comentario.  ¿El motivo? Pues que cuando he empezado a mirar documentación más profunda sobre el Model 3 me he dicho…

doh-homer-simpson-doh

Así que borrón y cuenta nueva, solo diré que esta nueva versión reemplaza la de ayer, disculpad por completo el hecho de haberos hecho perder el tiempo. Es por ello que voy a a intentar enmedar mi error con esta entrada.

Voy a utilizar el siguiente documento como fuente primaria.

Sí me permites con el tema de la memoria entrare más tarde, antes que nada me gustaría comentar la última parte de tu respuesta que es respecto a las CPUs.

Luego está el tema de la C.P.U, ya que el Power Pc a 166 Mhz del último Model me parece un procesador de propósito general bastante mejor que Hitachi SH-4, el cual es un lelo “in-order” que gasta grandes cantidades de ciclos de reloj en la fase de transformación e iluminación para la cual está diseñado. El IBM del Model 3 es un más espabilado “Out of Order” que sólo se preocupa de la fase de aplicación, y que encima no gasta sus ¿escasos? 8 MB en chorradas que no pueda leer directamente de las ROMs.

En mi opinión si bien NAOMI fue un paso adelante en cuanto a logística (más baratas, resultados de calidad similar, roms intercambiables, GD-rom con memoria dedicada), el Model 3 dejó el listón demasiado alto en cuanto a potencia; no siendo superado claramente en ciertos aspectos.

En primer lugar el PowerPC que es “Fuera de orden” de la serie 60x es el 604, siendo el 601 y el 603 completamente in-order. Por otro lado y como bien dices se ha de tener en cuenta que al no utilizar una unidad óptica no es necesario volcar los datos del juego a la RAM.

Lo que tiene de especial el SH4 de Dreamcast es una instrucción llamada FTRV (Floating Point Tranform Vector), lo que llamamos en gráficos 3D 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).

El segundo paso se hace multiplicando de los datos del vector (x,y,z,w) por una matriz de 4×4. Una transformacion puede ser una rotación, un desplazamiento, un reflejo sobre otro eje, un escalado… cada una de estas operaciones es la multiplicación de un vector de 4 componentes por una matriz de 4×4 que resulta en 16 multiplicaciones y 12 sumas, un total de 28 operaciones en total. Sin contar la latencia la FPU de Dreamcast puede relizar dicha operación en cuatro ciclos solamente y esto son  7 operaciones por ciclo, de ahí a que en las especificaciones técnicas ponga 1.4 GFLOPS.

¿Pero que ocurre con el resto del proceso? No tiene instrucciones especiales para el resto del proceso y es en ese momento cuando…

gladiator-thumbsdown

 

Me explico, los siguientes pasos no tienen instrucciones especiales en la CPU de Dreamcast, por lo que su rendimiento es menor. Obviamente con la instrucción FTRV se aceleran mucho las cosas pero hay que tener en cuenta que se procesan las siguientes operaciones antes de enviar los datos al PowerVR CLX2, y esto es general para todos los motores 3D:

  1. Transformación de las Normales (14 operaciones)
  2. Normalización de las Normales  (24 operaciones)
  3. Iluminación del Vertice (28 operaciones)
  4. Clipping (6 Operaciones).

Es por ello que para la transformación de los vertices al SH4 le es suficiente con 4 ciclos de reloj, pero si tenemos en cuenta todo la etapa de la geometría la cosa se va a los 40-64 ciclos tal y como se ve en el siguiente gráfico:

Captura de pantalla 2015-02-17 a las 11.27.56

En el caso concreto del Model 3 es distinto, tenemos que tiene un motor geométrico, esto significa que el proceso de la geometría 3D no se lleva a cabo por la CPU sino de forma paralela por un chip especializado que se encarga de realizar estas operaciones haciendo que la CPU quede completamente libre de realizarlas. ¿pero que potencia tiene dicho motor geométrico? Lockheed Martin tuvo planes de lanzar una versión doméstica de la tecnología que se usaría también en el Model 3 de Sega, no dio sus frutos pero sí lo hubieran dado hubiese sido un salto impresionante. He aquí la fuente de ello:

Real3D100n1

Y he aquí el diagrama general de la arquitectura:

 

Este diagrama de arriba es ni más ni menos que la siguiente placa en el Model 3, el Real3D Pro-1000 del Model 3 tiene una configuración  de 3 chips (Geometry Engine+Real3D-Pro1000x2), tal y como se ve en la siguiente imagen:

model3_cpu1

El siguiente punto es la memoria, esto es importante ya que es la explicación de la diferencia de rendimiento. En el documento que he enlazado antes y donde están desglosadas las entrañas tenemos que aparte de los procesadores encargados de la generación de imagen tenemos las siguientes memorias:

  • Hitachi HM5241605 4M (256k x 16 x 2 banks) SDRAM, tenemos unos dos chips por lo que el total de esta memoria son 16MB. En ellos se almacena la geometría de la escena en forma de una base de datos dinámica. Esta memoria es importante ya que en el multitexturizado impide el tener que recalcular la geometría de la escena en efectos que requieran dos pasos o más.
  • Mitsubishi M5M4V4169TP 4M (256k x 16), hay un total de 12 de estos chips por lo que hay 48MB de este tipo de memoria. Mirando la documentación cada uno de estos chips tiene un ancho de banda de 16 bits, por lo que nos encontramos que en total dan un ancho de banda de 192 bits (96 bits por dirección). Es aquí donde las texturas son volcadas desde la ROM por lo que la idea de que el Model 3 lee las texturas desde la ROM es falsa y erronea. La velocidad de acceso a la memoria es de 15ns (67Mhz) por lo que el ancho de banda es de 1.6 GB/seg y 0.8MB/seg por sentido, esta memoria es utilizada también para almacenar el búfer de imagen.
  • 3x  Mitsubishi M5M410092FP, estos tres chips de 10Mbits cada uno los comentare más adelante..

En Dreamcast en cambio tenemos unos 8MB de memoria SDRAM a 100Mhz que dan un ancho de banda de 800MB/seg, hay que tener en cuenta que Dreamcast gracias a su arquitectura Tile Rendering no necesita de un búfer trasero+búfer de profundidad ya que realiza dicho procesamiento desde la memoria interna, pero la clave esta aquí en el texturizado. En primer lugar hay que tener en cuenta que en esos 8MB se almacena:

  • La geometría de la escena.
  • El búfer delantero.
  • Texturas.

Debido a ello la densidad la cantidad de texturas que puede almacenar Dreamcast es muy inferior. Esto por no contar el hecho que el “swapping” de las texturas desde las VROM de la placa del juego ha de ser posible, algo que no se puede realizar en Dreamcast por el uso de una unidad óptica para el almacenamiento.

Model3_fullboard

En estas placas se almacenaban los datos del juego, tanto los datos de programa como los datos gráficos. Tenemos en su interior unos 64MB de ROM Gráfica, unos 64MB de ROM de programa y 16MB de ROM para el sonido. La cantidad de chips en las placas de juego las hacía completamente inviables a nivel doméstico pero no en los salones arcade. En el caso de Dreamcast existía la compresión de texturas VQ con tal de poder almacenar más información de texturas en la limitada VRAM, pero en ningún momento llegaba a los 48MB de memoria para texturas que tenía a su disposición el Model 3.

Por otro lado, supuestamente Dreamcast puede realizar 100 millones de pixeles por segundo usando filtro trilineal y no dudo de la capacidad del PowerVR CLX2 para hacerlo e incluso con 32 bits de color pero… ¿tiene el ancho de banda suficiente para hacerlo? Recordad que la formula para el bilineal es ancho de banda*4 accesos a memoria*información por pixel y en el caso del trilineal es ancho de banda*8 accesos a memoria*información por pixel. Teniendo solo 800MB/seg (lectura+escritura) esto deja unos solo 400MB/seg para el texturizado por lo que en Dreamcast la cosa quedaría así.

  • 100 Mpixeles/seg utilizando bilineal con 8 bits por textura (3 millones de polígonos).
  • 50 Mpixeles/seg utilizando bilineal y 8 bits por textura (1.5 millones de polígonos).
  • 50 Mpixeles/seg utilizando bilineal y 16 bits por textura (1.5 millones de polígonos).
  • 25 Mpixeles/seg utilizando trilineal y 16 bits por textura (750K polígonos)

Es aquí donde las cifras obtenidas por emuladores como el NullDC acaban cuadrando:

nulldc_1 nulldcdclem

En los tres chips M5M410092FP de unos 10Mbits de capacidad es donde se realiza el texturizado en el caso del Model3, con un ancho de banda de 128 bits cada uno de ellos (384 bits de ancho de banda) esto es más que suficiente para que los 60 Mpixeles/seg de ancho de banda del Model 3 no tengan problema alguno para ser renderizados con filtro trilineal y con 32 bits de color sin perder nada de la tasa de relleno por un cuello de botella generado por la memoria.

El otro tema son los búfers de imagen, en Dreamcast tenenos unos 400MB/seg de ancho de banda para los búfers de imagen, el PowerVR CLX2 es un Tile Renderer por lo que no requiere la VRAM para la creación del búfer de profundidad por lo que el ancho de banda de la memoria de vídeo necesario se reduce a la mitad. En una arquitectura convencional la formula es:

Tasa de relleno*(Color+Z).

En el caso del PowerVR la formula necesaria para el ancho de banda de escritura se reduce a:

Tasa de relleno*Color.

Hay que tener en cuenta que la tasa de relleno en Dreamcast en los juegos era mucho menor por los motivos explicados arriba por lo que el ancho de banda de escritura de la VRAM no es problema. En el caso del Model 3 tenemos que los búfers de imagen se almacenan en los 48MB de VRAM, el ancho de banda de escritura en dicho caso es de 96 bits*67 Mhz (800 MB/seg aprox), el Model 3 puede renderizar a 32 bits de color y 32 bits de Z (Profundidad), 60*8 son 480MB/seg por lo que tiene el ancho de banda suficiente para generar el búfer de imagen.

Anuncios