#1 Arquitectura General

Como se puede ver en el diagrama, Xbox esta compuesta por los siguientes componentes:

  • XCPU: Un Pentium III a 733Mhz con la mitad de su cache (128KB).
  • NV2A: Un procesador que engloba el DMA/NB del sistema y la GPU del mismo.
  • MCPX: El chip encargado del control de los periféricos, así como la generación del sonido. No es utilizado para generar gráficos por lo que lo voy a tener en cuenta.
  • 64MB DDR a 200Mhz con un ancho de banda de 6.4 GB/seg.

Como veis la organización general del sistema es la misma que en cualquier configuración UMA en una consola donde donde el Northbridge se encuentra en el mismo chip que la GPU. La conexión del bus frontal de la GPU se realiza a través de un bus del tipo Hypertransport siendo los dos únicos cambios de la GPU respecto a la serie NV2X de PC el añadido del Northbridge, del bus Hypertransport y la eliminación del por aquel entonces ampliamente utilizado en PC bus AGP.C

La CPU no tiene acceso directo a la RAM si no es a través del Northbridge que se encuentra en el mismo chip que la GPU por lo que existe una conexión directa entre el bus de la CPU y el NB/DMA en vez de la CPU con la memoria. El ancho de banda externo de la CPU es es de 1.3 GB/seg y el de la memoria de 6.4 GB/seg, esto significa que el NB/DMA puede funcionar de dos maneras distintas:

  • Dado que la GPU tiene preferencia esta se puede quedar con todo el ancho de banda en momentos puntuales.
  • 1.3 GB/seg para la CPU, 0.4 GB/seg para el MCPX y el resto para el NV2A, unos 4.7 GB/seg.

Dado que la consola tiene unos 64MB de memoria como pozo único de memoria es sumamente importante que la GPU pueda acceder a toda la memoria posible por fotograma para encontrar los datos que tiene que utilizar. Los anchos de banda de la memoria dan un enorme margen para ello. Es decir, Xbox tiene ancho de banda en exceso para la densidad de memoria que tiene y no resulta en ningún problema.

Por otro lado, hay un ventaja adicional en lo que al uso de una mayor densidad de memoria respecta en lo que a la calidad gráfica de los juegos respecta, pero esto ya entrare cuando hablemos del texturizado.

#2 XCPU

La XCPU es un Pentium III a 733Mhz con una cache L2 de 128KB. Debido a ello es comparado falsamente con un Intel Celeron basado también en un Pentium III, la diferencia es que el Celeron tiene la mitad de ancho de banda respecto al Pentium III y el XCPU pese a tener la mitad de cache L2 en densidad mantiene todo su ancho de banda.

Comparativamente con otras consolas su capacidad en cuanto a enteros según el el benchmark Dhrystone es 1980 MIPS o lo que es lo mismo, unos 2.1 MIPS por ciclo de reloj. Esto significa que es más potente que el PowerPC 750/Gekko en GameCube por su velocidad de reloj pero no es más potente que el PowerPC 750/Broadway de Wii. No obstante no podemo olvidar que respecto a Dreamcast y PlayStation 2 tiene una ventaja enorme a nivel de CPU y recordemos que en el caso de la consola de Sony la CPU no son los VU sino el R5900 que tiene una potencia de 450 DMIPS aproximadamente por lo que la CPU de Xbox en enteros es 4 veces más rapida y si hablamos de Dreamcast supera las 5 veces.

Un tema particularmente molesto y repetitivo cuando se habla de Xbox dado que su CPU es un x86, por si no lo habías notado al ser un Pentium III, es la estúpida comparación CISC vs RISC. La gente piensa erroneamente que un procesador RISC es más potente que uno CISC cuando no es así, los procesadores RISC tienen un conjunto de instrucciones reducidas, esto significa que para realizar instrucciones más complejas hacen uso de combinación de otras más simples. Lo procesadores CISC en cambio tienen un set de instrucciones más complejo.

Claro esta que la comparación es estúpida en este caso porque el Pentium III de Xbox es un procesador cuya arquitectura deriva del P6 (Pentium Pro) y es Post-RISC. ¿Que significa esto? Pues que lo que hace es descodificar las instrucciones complejas en simples para operar con ellas por lo que internamente es RISC. ¿Que es mejor, una instrucción compleja que tarde varios ciclos o una serie de instrucciones simples que tardan pocos ciclos cada una? Esto realmente no nos importa en el caso del que estamos hablando que como funciona la consola y el hecho constatado es que de la generación PS2-GCN-Xbox la consola de Microsoft es la más potente de todas.

El otro tema es la unidad de coma flotante, tenemos por un lado la unidad x87 y por otro la unidad SSE, esta funciona exactamente igual que los Paired-Singles del IBM Gekko. Por lo que en comparativa y dada la velocidad de reloj Xbox tiene una CPU con unas capacidades casi iguales a las de la CPU de GCN pero con la diferencia que la CPU de GCN pierde por la velocidad de reloj. Curiosamente en coma flotante la CPU de Xbox es un poco más potente que la de Wii y dado que en aquella época lo que es el cálculo de la detección de colisiones se hacía a través de la CPU utilizando las unidades SIMD como la unidad SSE podemos decir que Xbox tiene la ventaja de poder calcular de mejor manera la detección de colisiones así como la animación de lo vertices via CPU, pero la consola que tenía ventaja en ese aspecto teoricamente hablando era PlayStation 2 via VU0 pero la realidad es que muy pocos desarrolladores se rompían los cuernos con el VU0 mientras que la unidad SSE de Xbox era mucho más fácil de utilizar.

#3 NV2A

El NV2A es el procesador gráfico de Xbox, diseñado por Nvidia para Microsoft es de lejos el procesador gráfico más potente de su generación y supera por mucho al de cualquier consola de su generación y no solo en potencia bruta sino que además se puede considerar un salto generacional al ser el primer sistema en aplicar los Vertex y los Pixel Shaders, novedad que traen consigo al ser el propio NV2A un derivado de la gama NV2X. Fue a partir de Xbox que los juegos empezaron a utilizar los shaders y se puede considerar una antesala a lo que fue la generación siguiente con Xbox 360 y PlayStation 3.

Dado que la primera etapa en todo pipeline 3D es la geometria, voy a empezar por ella y lo primero a destacar es que con el NV2A tenemos dos pipelines distintos en cuanto a la geometría.

El pipeline de función fija funciona de la misma manera que el de Gamecube, pero con una capacidad de cálculo mucho mayor dado al hecho de disponer de dos unidades para la geometria, ir a una mayor velocidad y no tener el cuello de botella posterior en la unidad de rasterizado. La cifra que nos da Microsoft es de 116 millones de poligonos por segundo, pero esa es la tasa de la unidad de rasterizado, realmente la tasa geometrica teórica es un poco más baja llegando a los 74.56 millones de vertices, aunque no olvidemos que en la mayoría de modelo el vertice de un triangulo es el vertice de otro haciendo que en el 95% de los casos la cantidad de vertices y triangulos/poligonos sea el mismo.

En el caso de los Vertex Shaders, lo que tenemos es un pequeño programa donde los vertices ya transformados son lo parametros de entrada con la diferencia que es el desarrollador el que puede escoger que realiza dicho programa desde el momento en que no es una unidad de función fija la que realiza dicha operación sino una ALU o varias ALus programables. El error principal de concepto es pensar que en el caso de los Vertex Shaders se tiene que programar la geometría al completo, esto es falso tanto en Xbox como en las GPUs actuales. La realidad es que la geometría se procesa a través de una serie de máquinas de estado concatenadas que lo que hacen es recibir unos datos de entrada, realizar una operación ya fijada en el hardware y sacar unos datos de salida tras realizar dicha operación.

Como ya he explicado ya alguna que otra vez, lo que se hace en el caso de la geometria es hacer varias operaciones de vector por matriz donde el resultado es siempre un vector de cuatro componentes (x,y,z,w)

Podemos invocar el Vertex Shader antes de la rasterización en cualquiera de las sub-etapas clásicas de la geometria (ver diagrama),

Pero hay que tener en cuenta que al contrario de las máquinas de función fija donde su potencia es predecible en este caso no sabemos cuanta potencia puede consumir un shader concreto aunque el SDK nos dice que un Vertex Shader puede alargar el calculo de un vertice hasta 64 ciclos como mucho por lo que el ratio más bajo de Xbox en teoria es un poco menos de 1.2 millones de poligonos pero casi ningún juego utiliza tal complejidad en sus Vertex Shaders.

La potencia geometrica de Xbox es por lo tanto un poco más del doble que la de Gamecube y dado que Wii no tiene mejoras en ese aspecto respecto a la velocidad de reloj y no solventa el problema de la unidad de rasterizado es muy pero que muy superior a su contemporanea en ese aspecto. Hemos de tener en cuenta que la geometría es la primera parte del pipeline 3D y no marca el rendimiento si hay un elemento posterior que resulta en un cuello de botella. El caso es que a nivel de la geometria no hay nada en el que Gamecube tenga ventaja respecto a Xbox y no nos podemos olvidar de la existencia de los Vertex Shaders que permiten la ejecución de efectos especiales que son imposibles en Gamecube.

Comparativamente con PlayStation 2 tenemos que al ser la VU1 programable pues en teoría hay una mayor versatilidad que con Gamecube pero las VU no están pensadas para ejecutar shaders y el desarrollador lo tiene que hacer todo manualmente, la ventaja de los Vertex Shaders es que combinan la función fija con la programabilidad de tal manera que el control manual solo es llevado a cabo cuando es necesario. Pero en realidad a nivel físico no tenemo dos pipelines distintos, tenemos un pipeline completamente programable pero es la API la que envia de manera automatizada los programas necesarios para la ejecución del pipeline geométrico.

El caso es que es mucho más fácil pasar de PS2 a Xbox por el hecho de que en los Vertex Shaders podemos realizar las mismas manipulaciones que con el VU1 pero obviamente la implementación es diferente debido a la diferente arquitectura de ambas consolas. El problema lo tiene Gamecube al tener una unidad de función fija donde la CPU es la que tiene que encargarse de manipular la geometria haciendo que el rendimiento en ese aspecto sea pauperrimo y forzando que muchos juegos tuviesen que ser cancelados por el pésimo rendimiento de la consola, especialmente aquellos donde la geometría sufria modificaciones a tiempo real y aún más cuando la geometria de la escena era muy alta.

Es decir, a nivel teórico el NV2A puede a nivel de geometria con el VU1 y el GS de PS2 que recordemos que tienen tasas mucho más altas que Gamecube pero lo que realmente importa es el rendimiento en la etapa de rasterización que es donde realmente el NV2A marca una enorme diferencia respecto al resto.

El NV2A tiene unos cuatro pipelines para el texturizado al igual que GameCube pero trabaja con 2 texturas por TMU en lo que su tasa de texturizado es de 1864 Mtexeles, los cuales al contrario de sus contemporaneas consigue mantener sin perdidas en dicha tasa. ¿Como lo hace para sostener dicha tasa de relleno con una memoria externa de solo 6.4 GB/seg? Renderizando a 32 bits de color, 4 bytes por pixel, y teniendo en cuenta solo el filtro bilineal el ancho de banda necesario pasaría a ser de:

1864 millones de pixeles * 4 bytes por pixel*4 muestras por pixel=29.8 GB/seg.

¿Como lo solventa esto? Pues a través de la inclusión de una cache de texturas conectada a la TMU de tal manera que se realicen las operaciones de filtrado de texturas desde la misma en vez desde la memoria. El NV2A es la primera GPU para consola en implementarlo y desde entonces casi todas las GPUs de consola han implementado dicha cache, sobretodo porque es esencial de cara no solo al filtraje sino también a los Pixel Shaders. La cache de texturas del NV2A tiene suficiente ancho de banda para bilineal en 32 bits y trilineal en 16 bits por lo que para el trilineal en 32 bits la tasa de relleno se va a la mitad.

El otro tema son los Pixel/Fragment Shaders, tenemos uno por cada TMU y cada uno de ellos puede realizar una operación Vec3 (RGB) y una escalar (A) por texel, lo que se traduce en unas 32 operaciones en total, el Pixel/Fragment Shader lo comente por encima en una entrada de esta serie al ser un concepto general. En realidad son la evolución de los Color Combiners que ya hemos visto en N64 y GCN/Wii pero con la diferencia de que son mucho más poderosos en el NV2A.

El funcionamiento es muy parecido al de la unidad TEV de la GX GPU de Gamecube pero tiene una ventaja respecto a la consola de Nintendo al poder operar con dos texturas por TMU y es que esto le permite realizar las 8 etapas máximas del OpenGL (y heredadas por Direct3D 7 y 8) para el multitexturizado a un ratio de dos etapas por ciclo de reloj. Esto es importante porque en Gamecube algo que reduce a 1/4 la tasa de relleno en el NV2A lo reducirá a la mitad y dado que el rendimiento depende de la tasa de texturizado ya que será la tasa de relleno entonces en la mayoría de situaciones el NV2A es muy superior a la GX GPU. El hecho de poder operar con hasta 2 texturas al mismo tiempo y unir sus ALUs es lo que permite realizar el DOT3- Bump Mapping, efecto que fue ampliamente abusado y re-abusado en Xbox y que era tecnicamente imposible de hacer en otras consolas sin recortar enormente la tasa de relleno y lo mismo ocurre con algunos efectos de multitextura.

La otra gran ventaja es la memoria que tiene, no solamente soporta compresión S3TC/DXTC como en Gamecube sino que al contrario de la consola de Nintendo que tiene solo 24MB de memoria aquí tenemos unos 64MB de memoria permitiendo esa potencia adicional y memoria extra que Xbox fuese la primera consola en aplicar mapas de sombras en sus juegos dado que en comparación con otras consolas tenía memoria de sobras. Por otro lado, el hecho de poder funcionar siempre a 32 bits de color le da una calidad de imagen muy superior incluso a Wii que mantenia los problemas de color de la GX GPU incluyendo el Dithering.

Otra capacidad novedosa de Xbox respecto a PlayStation 2 y Gamecube es la capacidad que tienen los ROPS para el Stencil Buffer, haciendo que tenemos 32 bits para color, 24 bits para Z y 8 Bits para Stencil. Esto es único en Xbox dentro de su generación y es lo que permite Zrealizar la iluminación de juegos como Doom 3 y el primer Splinter Cell para la misma consola.

Varios juegos de Xbox utilizan el Stencil Búfer para una técnica llamada Shadow Volumes que consiste en lo siguiente:

  1. Renderiza la escena como si estuviese completamente en sombras.
  2. Por cada fuente de luz: Utilizando la información de profundidad para esa escena, construye una máscara en el stencil búfer que tenga agujeros solo donde en las superficies visibles no haya sombras.
  3. Renderiza de nuevo la escena como si estuviese completamente iluminada, utilizando el búfer stencil para enmascarar las areas sombradas. Utiliza operaciones de mezcla para renderizar esto en la escena.

Sin un Stencil Buffer en el hardware este tipo de iluminación no se puede realizar y por tanto no hablamos solo de un tema de potencia aquí. Tanto PS2 como GameCube (y Wii) carecen de un Stencil Búfer para poder realizar dicho tipo de iluminación más avanzada y pese a que no todos los juegos lo utilizan es importante destacarlo porque los juegos más avanzados de la consola si que hacen uso de ello.

Ahora bien… ¿Con el ancho de banda que tiene como lo hace para renderizar Color+Z y la tasa de relleno que tiene la consola? Xbox tiene 4 ROPS por lo que su tasa de relleno real es de unos 932 Millones de pixeles pero al contrario de PS2 y GameCube carece de memoria embebida para las operaciones sobre el búfer trasero. y la ecuación para el búfer de imagen teniendo en cuenta unos 32 bits para el color y 32 bits para la profundidad entonces tenemos que el ancho de banda necesario para el búfer de imagen trasero es de:

4 ROPS * 233 Mhz * 4 Bytes*2(Color+z)= 7.4 GB/seg

Necesitariamos una RAM con unos 14.9 GB/seg de ancho de banda para poder paliar el problema. ¿Como lo hace entonces? Una de las novedades del NV2XEl otro tema es la compresión sin perdidas de los datos del búfer de profundidad con un ratio de 4:1 por lo que el ancho de banda necesario para gráficos pasa a ser de:

4 ROPS * 233 Mhz*4 Bytes(Color)+1 Byte (Z+Stencil comprimidos)= 4.66 GB/seg,

Esto hace que los 6.4 GB/s de ancho de banda de la DDR no sean en teoría insuficientes incluso en momentos en los que la CPU accede a su espacio en la memoria principal, El problema no obstante llega con los efectos como el Alpha Blending donde la tasa de relleno baja en picado porque no existe suficiente ancho de banda.

4 ROPS * 233 Mhz*4 Bytes*2(Color+Alpha Blending)+1 Byte (Z+Stencil comprimidos)= 8.33 GB/seg,

Esto provoca que en juegos como Metal Gear Solid 2 donde se abusa de particulas con transparencia veamos una menor calidad visual en la versión de Xbox debido a la ventaja que tiene PS2 para este tipo de efectos gracias a a la eDRAM.

En realidad Metal Gear Solid 2 es un caso curioso por el hecho que en realidad es una mala conversión de un juego pensado para aprovechar la arquitectura de la consola de Sony y adaptado al 100% a esta. Aparte de ser un port realizado con prisas siendo un caso muy parecido al del Resident Evil 4 de Gamecube en PS2, a lo que me refiero es que con un poco más de esfuerzo Xbox podría haber ejecutado sin problemas y seguramente con una mayor calidad visual el juego de Kojima dado que tampoco es un juego puntero en PS2.

El gran handicap de Xbox es el hecho que al utilizar DirectX como API general no se aprovecho bien su rendimiento, no obstante una diferencia adicional que tiene el NV2A y que no he comentado es su procesador de comandos y la relación con una versión especial de Direct3D 8 que deriva de la de PC pero no es la misma pero que al ser un superconjunto de la misma puede ejecutar sin problemas los juegos adaptados desde PC haciendo que la optimización desde dicha plataforma en los juegos de primera generación no se produjese al ir suficientemente sobrada. El problema es que dicha extensión dependía enormemente del procesador de comandos de Nvidia que no era controlado por Microsoft, esto le dio muchos problemas a Microsoft de cara al hecho que Nvidia controlaba los costes del NV2A y era un componente excesivamente caro. Microsoft se planteo la realización de una Xbox con una Radeon de AMD que fuese 100% compatible con el modelo estándar pero se encontraron con que el procesador de comandos era propiedad de Nvidia, esto le llevo a acercarse a AMD para desarrollar su propio procesador de comandos para la GPU.

Esto es todo, me faltan las entradas de NintendoDS y PSP… Que serán por cierto las últimas de la serie Gráficos Retro. Como siempre tenéis el Discord y los comentario de la entrada.