
Gráficos, chips y últimos apuntes sobre Wii
La carrera de los bits y los megahercios Tal como dije, con este artículo concluyo la serie de
La carrera de los bits y los megahercios, que empezó como un tímido intento de explicar unos pocos conceptos acerca de dónde proviene la potencia en los sistemas de videojuegos e informáticos en general, y poco a poco ha ido creciencido en complejidad y extensión. No os voy a engañar, aún queda «chicha», pero es cierto que no va a ser tan complejo como los inmediatamente anteriores. ¿Preparados/as?
La fase de aplicación
A lo largo de estos artículos he hablado sobre el proceso de formación de una escena 3D, como la que vemos en la inmensa mayoría de los videojuegos modernos, a un nivel muy básico pero suficiente para que aquellos que desconocían del todo el proceso pudieran tener una idea de lo que significa y lo que sucede dentro del hardware. Sin embargo, mi sensación es de no haber dedicado el debido espacio a dar una visión general y es por ello que me gustaría hacerlo ahora. Tal vez repitiendo algunas cosas, procuraré ser breve, pero sin saltarme pasos fundamentales. Pongámonos en situación. Encendemos la consola y nos disponemos a jugar. El juego casi no importa; puede ser Super Mario Galaxy, Resident Evil 4 o sencillamente Wii Sports. En cualquier caso jugamos en un mundo virtual y la acción se desarrolla en una escena tridimensional, que vemos sobre una superficie plana. En primer lugar, para construir esta escena la consola ha debido leer código ejecutable del soporte de almacenamiento, que en el caso de Wii es un DVD, pero en teoría podría haber sido otro, como un disco duro o memoria flash (la DS usa cartuchos de memoria de semiconductor, por ejemplo). La CPU va buscando y recibiendo las instrucciones máquina (
fetching, en inglés) y las va ejecutando. Un juego moderno está compuesto por una cantidad tremendamente enorme de instrucciones, y su complejidad es suficiente para desbordar a cualquier programador. Todo cuanto sucede, hasta el más mínimo detalle, debe estar especificado en forma de sencillos pasos, que el microprocesador sea capaz de ejecutar. La mayoría de las instrucciones son simples movimientos de un dato numérico, comparaciones u operaciones simples. A base de una jerarquía, y un patrón sólido de diseño, se construye el motor principal del juego, que va a gestionar todo lo que ocurre y es posible que suceda dentro de él. Aunque mucha de esta lógica (mecánica) puede pasar desapercibida a simple vista, no sucede lo mismo con la escena que vemos en el televisor, que salta a primera vista y que, literalmente, nos entra por los ojos. En función del estado del juego y las especificaciones del programa, la CPU decidirá cómo debe mostrarse la escena y desde qué punto de vista. El entorno tridimensional que va a ser representado está definido por un modelo matemático, también almacenado en el soporte de almacenamiento (DVD, cartucho…). Este modelo está compuesto, entre otros, por los vértices que constituyen las figuras geométricas presentes en la escena, incluído el terreno mismo. Cierta información es transferida a la memoria principal de la máquina, para poder ser procesada. Los vértices que componen los polígonos, que a su vez forman los objetos en la pantalla, junto a las texturas necesarias, información de iluminación, propiedades de los materiales, entre otros, van cargándose en la memoria de vídeo de la máquina, que puede estar compartida con la CPU (como en Xbox 360 y Wii), o estar a disposición casi exclusiva de la GPU (como en PlayStation 3 y Dreamcast). A esta primera fase la podemos llamar fase de aplicación, porque es donde se gestiona el motor del juego, controles, colisiones, inteligencia artificial, etc. Para explicar lo que sucede a continuación voy a usar como modelo no la GPU de Wii, sino el de una GPU como la de la primera Xbox, y luego explicaré porqué.

Diagrama básico y general de la estructura de una GPU clásica, como podría ser la de Xbox (NV2X) y que servirá como modelo.
Hay que entender todo el proceso gráfico como un flujo de datos que va pasando de etapa en etapa. Cada etapa se ocupa de una parte concreta del trabajo y al final de la cadena se obtiene el resultado definitivo. Es como una cadena de montaje, cuyo concepto en inglés de denomina
pipelining. Los datos llegan a la GPU a través del bus de sistema, al que también están conectados el procesador y la memoria. El recuadro rojo, el bloque de entrada/salida (E/S, o I/O en inglés), representa la circuitería que permite la comunicación con el bus, y es también la puerta de entrada al chip gráfico. En sistemas modernos es una parte relativamente compleja y vital.
La fase de transformación
Durante esta fase es cuando, en pocas palabras, se va a procesar y colocar en su sitio cada polígono, lo cual exige un intenso cálculo geométrico, y un consumo importante de recursos en operaciones en coma flotante. En este punto, los polígonos aún no existen, y no son más que una lista de vértices que se van enviando, uno a uno, a las unidades de
vertex shader (ver imagen). Un shader es un pequeño programa software que define una serie de operaciones y transformaciones; y como se puede deducir, un vertex shader manipula vértices. Cada una de estas unidades es un pequeño procesador programable, donde son ejecutados. Este hardware está diseñado con esta tarea en mente, siendo por tanto muy eficiente en coma flotante. Así pues, los vertex shaders son el software que corre en las unidades de vertex shader. En el chip gráfico existen varias de estas unidades de vertex, y cada una de ellas es capaz de trabajar sobre un vértice distinto simultáneamente. Cuando hay vértices pendientes de ser procesados, se espera a que alguna unidad de vertex esté libre y se le envía. Cuando alguna de estás unidades termina y queda libre, otro nuevo vértice puede entrar. Por tanto, cuantas más unidades de vertex disponga la GPU, sobre más vértices podrá trabajar en paralelo (otro tema a considerar será con la rapidez con la que lo haga). Para que los vértices se conviertan en polígonos «sólidos» hay que hacer varias cosas: calcular sus posiciones dentro de un espacio tridimensional, aplicarles propiedades materiales como color e iluminación, obtener su proyección desde el punto de vista de la cámara, y por motivos de eficiencia, eliminar todos aquellos que estén fuera del campo de visión (
clipping, en inglés). Finalmente, los vértices se suelen agrupar formando triángulos (
triangle setup), por ser una figura primitiva sencilla. De esta tarea se suele encargar lo que se denomina «
setup engine» (elemento hardware dentro de la GPU).

Modelo matemático, lista de vértices, que son posicionados y luego procesados. Al final, los cuatro vértices forman tres triángulos.
Llegado a este punto, y sin apenas intervención por parte de la CPU, se ha pasado de un modelo tridimensional a un conjunto de triángulos que pueden ser rasterizados, o lo que es lo mismo, convertidos a un mapa de bits; una representación plana de píxeles. Esto es imprescindible, porque el televisor, hoy por hoy, sólo muestra imágenes planas. No obstante, estos futuros píxeles no aparecen por ciencia infusa. En este punto, lo único que tenemos son unos triángulos compuestos por vértices, flotando en la negrura del espacio. Todavía no existen superficies. Entre los vértices hay sólo vacío. Para remediar esto, existe la fase de renderizado.
La fase de renderizado; poniendo los píxeles en su sitio
Pixel pipeline (o tubería de píxeles, si gustas) es como se suele denominar a una serie de etapas dentro del chip gráfico, encargadas de trabajar, como su nombre indica, sobre píxeles. Cuando un píxel entra en el pipeline, va atravesando distintas fases, hasta llegar al final, y mientras va avanzando, van entrando nuevos píxeles, de forma que todas las etapas acaben estando ocupadas. Tanto GameCube, como Xbox, y seguramente Wii, disponen de cuatro de estos pipelines, y cada uno de ellos, una vez tiene ocupadas todas sus etapas, es capaz de generar un píxel por ciclo de reloj. Si bien este es el caso ideal, porque si las operaciones a realizar sobre un determinado píxel son suficientemente complejas, como para exceder la capacidad de trabajo que el pipeline puede hacer en una sola pasada, se necesitarán ciclos adicionales para completarlas. En nuestra GPU clásica de ejemplo, los píxel pipelines están compuestos por unidades de píxel shaders, TMU y ROP (ver la imagen inferior). Es un esquema muy simplificado, pero suficiente. En una GPU real se distinguen multitud de bloques y matices, pero las tareas básicas están reflejadas. De una manera similar a como sucedía con los vértices, las unidades de píxel shaders son circuitos programables que actuan sobre el color y comportamiento de los píxeles, y son un mecanismo muy flexible y eficiente a la hora de aplicar determinados efectos. Aunque no hay una norma que lo exija, por regla general suelen ser aún más potentes en coma flotante que sus hermanas, las unidades de vertex shader. Cada pipeline dispone de una o varias unidades de texturización (TMU, texture mapping unit). Estas TMU aplican las texturas a cada píxel de las superficies, y pueden llegar a colocar hasta un píxel de textura (llamado
téxel) cada ciclo de reloj. GameCube, y probablemente Wii, disponen de una sola TMU por pipeline. Esto significa que si hay que aplicar varias texturas sobre un único píxel, habrá que dedicar ciclos de reloj adicionales. En cambio, la Xbox dispone de dos TMU por pipeline. Si bien esto no le permite generar más píxeles, sí le confiere una mayor capacidad de texturización. Si por ejemplo hubiera que aplicar dos texturas sobre un determinado píxel, no debería haber, en principio, penalización. Cada una de las TMU se encargará de una de las texturas. Aunque en escenas muy simples puede no ser un factor decisivo, sí lo es en escenas donde se emplee multitexturización, algo muy habitual.

Izquierda: píxel pipeline con una única TMU. Derecha: píxel pipeline con dos TMU.
Los ROPs (
Raster OPeration unit) son nuestra última parada. Los píxeles que salen de las unidades de shaders no están todavía listos para mostrarse en pantalla. Todas estas estapas previas han definido las «propiedades», pero no han generado la vista definitiva. Los ROP son algo así como los «generadores de píxeles». Realizan una serie de tareas, entre las que están:
- Prueba de profundidad, que descarta todos aquellos píxeles invisibles a la cámara, ocultos, o demasiado alejados.
- Transparencia, así como el blending, o combinación final del color de elementos superpuestos.
- El antialiasing, o la reducción de los «dientes de sierra» en los bordes de los objetos.
- Estrategias y medidas para ahorrar ancho de banda con los buffers de video.
Las primeras tarjetas gráficas aceleradoras apoyaban a la CPU únicamente en el renderizado. Es decir, es como si sólo tuvieran un ROP. No había shaders, ni nada parecido, y el procesador tenía que realizar el trabajo duro de cálculo y geometría, así como realizar por software todos los efectos visuales, como la iluminación y el sombreado. En una GPU moderna, los ROPs son el final del proceso, y dan la forma final a cada píxel, aunque siguen encargados de efectos tan importantes como el antialiasing (FSAA o MSAA) o el filtrado. De cada ROP, los píxeles ya definitivos van a parar al buffer de vídeo, que una vez contiene el fotograma completo, es volcado en pantalla. Y todo esto llega a ocurrir 50 ó 60 veces por segundo, o más. Es una de esas cosas que te parecen increíbles, o te parecen una chorrada, pero no creo que haya punto medio.

Durante el renderizado, antes y después de aplicar iluminación.
Al margen de la potencia de cáclulo, o informalmente, los polígonos que puede mover por segundo, un atributo importante de un chip gráfico es su tasa de relleno (
fillrate), que se refiere a los píxeles que es capaz de generar y mostrar en pantalla cada segundo. En un sistema desequilibrado, si tienes mucho poder de cálculo pero luego no tienes capacidad de rellenar con píxeles esos polígonos, entonces no servirá de nada. El rendimiento final se ajusta al parámetro más desfavorable. Este valor, el fillrate, depende precisamente del número de ROPs. Un chip con dos ROPs trabajando a 100 MHz es capaz de rellenar 200 millones de píxeles por segundo, uno por ciclo de reloj y ROP. A veces en lugar de en píxeles por segundo, la tasa de relleno se da en téxeles por segundo, lo que hace referencia al número de píxeles de textura colocados por segundo, y este valor, en la práctica, no depende de los ROPs, sino de las TMU, y es igual o mayor a la tasa en píxeles por segundo. Luego aclararé las diferencias, pero no quiero sobrecargar más ahora. Como acabo de decir, los primeros chips gráficos con capacidades de aceleración 3D sólo participaban en la fase de renderizado, y el resto era hecho en software por la CPU. Una de las primeras tarjetas gráficas para uso doméstico fue la Voodoo de 3Dfx, en 1996, que sólo disponía de un píxel pipeline, una TMU y un ROP. Poco a poco estos componentes fueron creciendo en número, y trabajando en paralelo. A las primeras GPUs se las empezó a llamar así porqué eran capaces de ayudar en la fase de geometría, desahogando al procesador, y abarcabando casi todas las etapas del procesamiento gráfico. Aún así no usaban shaders programables, sino funciones fijas, realizadas por el motor T&L (
Transform and Lightining). La primera GPU, el chip NV10, se montó en la tarjeta gráfica de Nvidia, GeForce 256, en el año 1999. La siguiente generación de tarjetas gráficas introdujo mejoras en el motor T&L, y la siguiente, en 2001, ya incorporaba unidades de shaders, que podían ser programadas. Y de esta generación es precisamente la GPU usada por la primera Xbox.
Volvamos a la Wii: los TEV
Ni GameCube, ni Wii usan ningún tipo de shader. Hasta donde mis conocimientos llegan, las GPUs de ambas consolas, «Flipper» y «Hollywood» respectivamente, disponen de un motor de transformación e iluminación, de funciones fijas, en lugar de unidades programables de vertex shaders. Además, tampoco usan píxel shaders, sino una cosa «extraña» y misteriosa (para mi) llamada TEV. Las especificaciones de estos chips no son públicas, están protegidas por acuerdos de confidencialidad muy potentes y no creo que se pueda tener certeza total sobre los detalles, pero al menos estas afirmaciones parecen razonables. Aunque estas GPUs no sean como las del ejemplo que he usado en la explicación, podemos hacer «trampas». Realmente, si se entiende cómo funciona una GPU de shaders, se entiende, grosso modo, cómo funciona la GPU de Wii. El flujo de trabajo es en esencia el mismo. Y como cualquier GPU, la de Wii realiza la transformación y el renderizado, liberando a la CPU de estas tareas. La diferencia radica en los circuitos electrónicos que realizan este procesamiento y cómo lo hacen. Mi propuesta es ver las GPUs de GameCube y Wii como una GPU de primera generación, donde no existe el concepto de shader y el catálogo de funciones posibles está implementado en el hardware, siendo por tanto fijas. Sin embargo, no todo sería fijo. Los TEV (que significa
Texture EnViroment unit) sí parecen estar bajo control del programador. Ocuparían el lugar de píxel shader en una GPU «normal», y por tanto participan en la fase de renderizado. Se sabe que en GC, y no hay evidencia de que haya cambiado en Wii, hay cuatro píxel pipelines, es decir, hardware para trabajar sobre cuatro píxeles al mismo tiempo (como sucede en Xbox). Por tanto, podemos imaginar a «Hollywood» como una GPU con cuatro unidades de píxel shader, cuatro TMU y cuatro ROP. De este modo se puede aplicar casi todo lo aprendido, pero teniendo en mente que
no son lo mismo; es sólo un «truco», para entenderlo y recordarlo.

TEV y unidad de píxel shader se podrían considerar equivalentes. Ambos son combinadores de color, encargados de modificar y combinar el color de los píxeles para reflejar un determinado comportamiento, material o efecto, como podría ser el del agua o alguna compleja reflexión en una superficie. Para ello, se echa mano de operaciones matemáticas que son realizadas en hardware por unidades vectoriales de elevado rendimiento. Y los píxel shaders son simplemente un lenguaje, un medio de comunicarse y controlar este proceso. Los TEV, que no permiten ser programados de la misma forma, parecen estar algo más limitados, aunque por la forma en la que trabajan, tienen también sus ventajas. La única que conozco con relativa certeza es la forma en la que se van realizando las lecturas de texturas y que comento a continuación. En una unidad de píxel shader, antes de empezar a aplicar los efectos, hay que leer las texturas necesarias. En el TEV se pueden posponer lecturas, a la espera de un determinado resultado o condición. Así, de algún modo es posible intercalar las operaciones sobre los píxels con lecturas de texturas dentro de una misma pasada. En una unidad de píxel shader habría que recurrir a una pasada adicional (consumiendo ciclos de reloj extra). De todos modos, los shaders ofrecen un mayor abanico de posibilidades según muchos, y yo, que no soy ningún experto en la materia, transmito lo que he podido averiguar. En conclusión, el TEV es equivalente, pero no hace las cosas del mismo modo que una unidad de píxel shader. Después de ver los resultados, yo soy de los que piensa que debido a las diferencias en su diseño y construcción, hay cosas que uno hace más eficientemente que otro, como casi siempre en ingeniería (y en la vida misma). GameCube y Wii han demostrado ser capaces de rivalizar con juegos que corren en arquitecturas de shaders, tanto en rendimiento como en calidad gráfica y posibilidades de efectos, como son la Xbox y las tarjetas gráficas de PC a su nivel. Quizá se habría agradecido un diseño más estándar, para facilitar la vida a los programadores, pero Nintendo no tiene ningún interes en que sus juegos sean «portados» a PC o a otras consolas, así que, como suele ocurrir, el hardware de la Gran N tiene sus peculiaridades (cartuchos en N64, mini DVD en GameCube, dos pantallas en DS, control «revolucionario» en Wii, etc.). No quiero cerrar estos apartados sin antes remarcar que desde hace ya unos años, las GPUs no están construídas sobre la misma arquitectura que he explicado. Lo aprendido sigue siendo de gran utilidad, porque a grandes rasgos el proceso es el mismo. Siguen existiendo las tres fases principales de aplicación, transformación y renderizado. La diferencia fundamental es que ahora las unidades de shaders pueden trabajar tanto sobre píxels como sobre vértices, y por tanto ya no hay distinción a nivel hardware entre unas y otras. Xenos, la GPU de Xbox 360, pionera en este sentido, dispone de 48 unidades de shaders, repartidas en tres grupos de 16, que se pueden asignar a píxels o a vértices de forma dinámica, es decir, durante la ejecución del juego. Se comparte un mismo hardware para las fases de transformación y renderizado, y es mucho más fácil mantener los recursos de la GPU ocupados, porque se puede adaptar a las necesidades de la escena.
La complejidad de la escena
Las escenas tridimensionales, así como los objetos y personajes, pueden ser modelados usando programas como 3ds Max, Maya o alternativas libres y gratuitas como Blender. La base del modelo no es otra cosa que un conjunto de vértices, al que se suele llamar «
mesh«. Una vez finalizado el proceso, se salva, de modo que pueda ser leído por el motor de renderizado del juego. Sin embargo, hay que considerar con cuidado la capacidad de la máquina donde va a funcionar. A menudo los modelos son demasiado detallados como para que puedan ser movidos en tiempo real, y entonces lo que se hace es emplear modelos con un menor nivel de complejidad, lo que suele implicar un menor número de vértices y, por tanto, polígonos. Es muy habitual que las secuencias cinemáticas de los juegos usen los gráficos reales de juego y se vean mucho mejor de lo que lo hacen durante el desarrollo, cuando el jugador tiene el control. Esto es porque dichas escenas han sido previamente renderizadas, fotograma a fotograma, formando un vídeo que puede visualizarse sin carga computacional para el sistema gráfico. De lo contrario, el hardware sería incapaz de mover con fluidez las escenas cinemáticas. En cambio, durante el juego mismo hay que controlar el nivel de detalle para permitir un movimiento suave, especialmente en videoconsolas. En los ordenadores es otra historia, y se suele dar libertad al usuario para aumentar y disminuir tanto la resolución como el detalles de modelos, texturas y sombras, porque hay equipos que pueden ser mucho más potentes que otros. Si le pides al hardware más de lo que puede darte, entonces la tasa de fotogramas por segundo caerá y el juego empezará a funcionar a trompicones, para acabar volviéndose injugable. Para hacerse una idea, un mesh de un personaje que esté formado por 150.000 vértices, que sea visualizado en tiempo real con fluidez, a unos 40 fotogramas por segundo, exige del hardware gráfico el movimiento de unos seis millones de vértices por segundo (150.000 * 40). Vértices, pero, ¿cúantos polígonos son eso? Usando tríangulos, entre dos y casi seis millones de polígonos por segundo, en función del número de vértices que compartan. En el caso extremo de que cada triángulo esté formando por sus propios vértices, serían dos millones (150.000 / 3 * 40). En el caso extremo de que todos los vértices estén compartidos, habrá un triángulo menos que vértices, o casi seis millones (149.999 * 40).

Izquierda: se comparten los vértices. Nº de triángulos = vértices - 1. Derecha: cada triángulo tiene sus vértices. Nº de triángulos = vértices / 3.
Aunque ambas cifras son importantes, son el número de vértices los que realmente consumen recursos de cálculo, o en otras palabras, las que son «GPU-killer». En cualquier caso, 150.000 vértices para un modelo constituye una cifra más que considerable. Además de la complejidad de la geometría en sí misma, hay que tener en cuenta que efectos como la generación de la sombras consumen también una importante porción de recursos. Basta con intentar reproducir a mano una simple escena en perspectiva, para darse cuenta del impacto del número de vértices en el tiempo de realización.

Ejercicios elementales de perspectiva.
También la resolución tiene una influencia directa y definitiva. A mayor número de píxeles por fotograma, mayor tráfico de datos en el buffer de vídeo, lo que consume ancho de banda de memoria y también recursos de renderizado, píxel shader, texturización, ROP…
¿Donde queda exactamente Wii?
Rendimiento final de una GPU y la dificultad de las comparaciones.
No es nada fácil responder a esta pregunta. Lo mejor que se me ocurre es delinear brevemente cómo hacerse una idea comparativa. Incluso dentro de las GPU que usan una arquitectura de shaders, no todas las unidades de shaders son igual de potentes. Puede que tengan la misma función, pero cada diseñador tiene la libertad de implementarla como quiera. Igual que sucede con una CPU, cada modelo ofrece rendimientos distintos, aunque todas se llamen CPU. O coches; unos son grandes, otros más fiables, azules o negros, pero todos son coches. Para hacerse una idea, en un primer acercamiento, de la potencia relativa de una GPU, podemos sumar el número de unidades de shader, y multiplicarlo por la frecuencia de reloj del core de la GPU. Esta comparación habría que hacerla entre dos GPUs del mismo tipo, o bien de shaders no-unificados, o bien de shaders unificados. Por actualidad, voy a centrarme más en éstas últimas. Cuánto más parecida sea la arquitectura mejor, porque muchos factores afectarían al resultado, haciéndolo más y más impreciso. De modo ilustrativo, voy a referirme a las tarjetas gráficas NVIDIA GeForce 8800GT y ATI Radeon HD3870, que tienen unos añitos, pero servirán perfectamente (las cifras pueden variar un poco, tomadlo pues como aproximado, pero bastante fiel). La Radeon tiene un número de
stream proccessors (shaders) muy superior (320 frente 112), y su core funciona a mayor velocidad (777 MHz por 600 MHz). Así, nada más empezar, parece una diferencia abismal, pero no lo es tanto. La GeForce usa una frecuencia de reloj distinta para el core que para los shaders, o en otras palabras, funcionan a distintas velocidades. En concreto, los shaders son mucho más rápidos, alcanzando unos vertiginosos 1.500 MHz. Nuestro primer acercamiento queda así:
- Radeon: 777 * 320 = 248.640
- GeForce: 1500 * 112 = 168.000
La Radeon obtiene una mejor puntuación. Pero este resultado se aplica a la potencia de cálculo bruta. A estas alturas será obvio pensar que el ancho de banda de la memoria es tanto o más importante. De nuevo, la memoria en la Radeon es algo más rápida (.1125 MHz contra 900 MHz). Como ambas tienen el mismo ancho de bus para la memoria, 256 bits, la Radeon gana en ancho de banda, por emplear un reloj más alto. Se calcula como siempre, multiplicando el ancho del bus de la memoria por la frecuencia de reloj de dicha memoria ((Como ya he comentado en anteriores artículos, la división por 8 es para obtener un resultado en bytes, en lugar de en bits.)).
- Radeon: 1125 * 2 * 256 / 8 = 72 Gbytes/s
- GeForce: 900 * 2 * 256 / 8 = 57,6 Gbytes/s
Como las dos GPUs tienen 16 ROPs, según los anteriores números, podría parecer que la Radeon es una tarjeta claramente superior. Sin embargo, al suponer eso nos equivocaríamos. Basta con ojear pruebas de rendimientos reales en juegos (
benchmarks), para observar una pequeña pero clara diferencia a favor de la GeForce. Vamos a ver porqué. En primer lugar, para ilustrar lo que dije antes, que no todas las unidades de shaders son iguales, no es que la Radeon tenga 320 shaders, sino que más concretamente son 64 shaders que operan en formato vec5, mientras que los 112 shaders de la GeForce son escalares. Recordando la diferencia, una operación escalar es la que involucra dos operandos. Por tanto, en el chip de NVIDIA se pueden realizar 112 operaciones en paralelo. En cambio, una operación vec5 involucra cinco operaciones, donde hay implicados diez operandos. Así que para poder comparar el número de shaders de una con los de la otra, se dice que el chip de ATI puede realizar 320 (64*5) operaciones en paralelo. Pero cuidado de nuevo, esto es si se programa debidamente. ¿Qué sucede si se lanza a un unidad de shader vec5 una operación escalar simple, como una división? Como es capaz de hacer cinco operaciones, y sólo le pides una, se está desaprovechando la mayor parte de su potencia. Es como si consumiera el recurso de cinco unidades de shader. Mientras, la GeForce consumiría una única unidad. No debería ser decisivo, porque como he comentado varias veces a lo largo de la serie, lo normal es que en entornos de procesamiento gráfico, las operaciones estén empaquetadas en grupos, en lo que se denominan operaciones vectoriales. Pero es un factor a tener en cuenta, sobretodo porque el rendimiento final dependerá del entorno (lo bien o mal que estén aprovechados). El otro «culpable» es un dato que he obviado a propósito. La Radeon dispone de 16 unidades de texturización (TMU), mientras que la GeForce tiene 56. En pocas palabras, cuando llega el momento de texturizar, el chip de NVIDIA es capaz de aplastar a su competidora y compensar su menor rendimiento teórico en otros ámbitos. Me gustaría que este ejemplo sirviera como ilustración de la importancia, no sólo de tener puntos fuertes, sino del equilibrio, y como cada parte de un sistema condiciona el funcionamiento de las otras. No soy partidario de ninguna de las dos compañias/marcas/modelos. Y no significa ni que NVIDIA haga/diseñe mejores GPUs, ni que todas ellas sean superiores a las de ATI. No es ni tan siquiera una opinión. He recurrido a estos modelos por motivos puramente ilustrativos. Volviendo a la cuestión principal: ¿dónde queda exactamente Wii, en términos de GPU? Es una pregunta que no puedo responder. Y tampoco es mi objetivo, porque sería entrar en una espiral hacia ninguna parte. La mayoría de los detalles técnicos son desconocidos, y es por tanto imposible dar una respuesta concreta. Mientras en el mundo de los ordenadores es todo modular y existen multitud de pruebas a las que se pueden someter las tarjetas gráficas, para corroborar su rendimiento, y compararlas unas con otras, en el mundo de las consolas tenemos que basarnos en la especulación y los resultados. Aunque se pudieran ejecutar aplicaciones para realizar benchmarks, no se podría quitar la GPU y poner otra, sino que se está forzado a medir todo el sistema, en conjunto. El caso de Wii es aún peor, porque mientras multitud de detalles e información sobre los sistemas gráficos de PlayStation 3 y Xbox 360 son públicos y accesibles, esta política no es ni mucho menos la que gusta a Nintendo. Así pues, la mejor prueba, varios años después de haber salido al mercado, es evaluar los juegos que han sido lanzados hasta el momento. Para terminar, volveré a mi costumbre de hacer tablas resumen, y aprovechar que he hablado de dos tarjetas gráficas que podían ser consideradas «alta gama» durante el comienzo de la andadura de esta generación. Es sencillo comprobar que estas tarjetas gráficas, orientadas a los ordenadores personales, son ampliamente superiores, pero también más costosas. Como ya es habitual, jugar en un PC implica un mayor desembolso, pero también unas mejores prestaciones gráficas.
[1] Realmente la Xbox 360 y la Radeon HD3870 tienen 48 y 64 shaders vec5, pero como acabo de comentar, voy a indicar su número multiplicado por 5, para poder compararlo más directamente a la Geforce 8800GT.
[2] Xbox 360 tiene 16 unidades de textura con soporte de filtrado, que son realmente las equivalentes al resto de competidores. Además dispone de 16 sin capacidad de filtrado, que suelen usarse para samplear vértices, o texturas sin filtrar, algo que no permite usarlas como se suelen emplear las TMU. Por lo tanto, he considerado que tiene 16 TMU, para equipararla en este apartado al resto. Por si quedan dudas: ¿cómo calcular ciertos parámetros?
GFLOPS En el caso de shaders unificados, cada shader es capaz de hacer 2 operaciones en coma flotante por ciclo: MHz (shaders) * shaders * 2.
En el caso de la PS3, cada tipo de shader es distinto: MHz (shaders) * ( píxel shaders * 27 + vertex shader * 10 ).
Ancho de banda de memoria (en MBytes/s)
MHz (memoria) * 2 * ancho de bus / 8.
Píxel fill-rate (Mpíxels/s):
ROPs * MHz (core)
Téxel fill-rate (Mtéxels/s)
TMU * MHz (core) Como he dicho anteriormente, me gustaría aclarar la diferencia entre tasa de relleno en píxels por segundo y en téxels por segundo. El primer valor representa el número de píxels que puede renderizar el sistema gráfico en cada segundo, mientras que el otro valor hace referencia al número de píxels de textura. Sobre lo que nosotros vemos en la escena como un único píxel, en realidad ha podido ser fruto de un proceso de multitexturización, o en otras palabras, el resultado de la aplicación de varias capas de texturas sobre una superficie (ver imagen inferior). Cuando la tasa de relleno en téxels es superior a la dada en píxels, esto
no determina el número máximo de pixels que puede generar, sino más bien da cuentas de la capacidad del sistema para superponer texturas. Ejemplo: si el valor en téxels por segundo es el doble que el de píxels por segundo, entonces lo que sucede es que podrían aplicarse sobre cada píxel dos texturas (téxel) y así sucesivamente.

Izquierda: superficie plana de un material con color #C4843B (RGB) Centro: se aplica una textura. Derecha: se superpone una segunda textura.
Hablemos de circuitos integrados
Para algunos este artículo ha podido ser un «no me dice nada nuevo», o un «se ha quedado en la superficie», pero estoy convencido de que otros muchos deben de estar saturados de información. Y para ellos, en este punto, ¡he metido una caña importante! Cuando planeaba el contenido de este artículo, hace ya más de un año, mi idea era centrarme en Wii. Finalmente, he acabado escribiendo un artículo orientado a los chips gráficos. No ha sido casual, ni tampoco una apuesta fácil. Me ha parecido la mejor manera de enfocarlo para, como siempre, aprender, y sobretodo rematar esta serie de artículos. Si bien, debo mencionar que no ha sido una explicación básica ni académica sobre gráficos 3D (mucho menos 2D), sino más bien una introducción empezando por el tejado. Solamente he mencionado algunas curiosidades históricas y si alguien tiene interés, debo decir que existe mucha información al respecto en la red, comenzando por el principio y las bases, como el
sombreado gouraud y el
phong o
mipmapping, que quedan fuera de estos artículos. Para darle un poco de variedad y tocar un tema completamente distinto y no poco interesante, me gustaría hablar de algunos de los chips, tanto de Wii, como de sus contemporáneas. Éste (y ahora sí) será el último tema que trataré en «La carrera de los bits y los megahercios». Fundamental para haber logrado mi objetivo de tocar, al menos superficialmente, todos los ámbitos más o menos relacionados, detrás de las ideas de potencia. Actualmente, la mayoría de los chips o circuitos integrados se fabrican sobre una superficie de silicio de extrema pureza, a base de procesos muy complejos que acaban configurando la estructura de un gran circuito, en plano. Se llaman circuitos integrados precisamente porque integran en una única pieza lo que antes se hacía con elementos individuales. A partir de un cilindro de silicio, crecido artificialmente gracias a un proceso muy controlado, se cortan finas láminas circulares llamadas obleas (
wafer, en inglés). Normalmente se hacen muchos chips idénticos sobre una misma oblea, unos al lado de los otros, formando una rejilla, y que son luego cortados en dados (
dies, en inglés).

Bloques cilíndricos y ya procesados de silicio, de donde se obtienen las obleas vírgenes.
El componente principal de todo circuito integrado es el transistor. Ya hablé un poco sobre ello en el
artículo 4, pero como breve reseña diré que un transistor es un dispositivo con la capacidad de dejar pasar una determinada cantidad de corriente, en función de cómo se polarice. Se usan como amplificadores en circuitos analógicos, o como conmutadores en circuitos digitales. Todas las aplicaciones de las que he hablado en estos artículos son puramente digitales, así que para nosotros, un transistor es como un diminuto interruptor, controlado eléctricamente. Aunque existen muchos tipos de transistores, y al menos dos grandes familias, los procesadores y otros muchos circuitos digitales modernos, usan casi exclusivamente transistores MOSFET (o simplemente MOS). Dentro de los MOS, existen los PMOS y NMOS (positivo y negativo, respectivamente). Esta distinción hace alusión al tipo de portadores que contribuyen a la corriente en su interior y dependen de la forma en la que se dopan con impurezas. Toda corriente eléctrica en un metal es debida a un flujo de electrones, pero a su vez, cuando un electrón se mueve en una dirección, un huecos se mueven en la opuesta. En un transistor de tipo N los portadores son electrones y en los de tipo P, huecos. La tecnología de fabricación más usada en la actualidad es la CMOS, o MOS complementario, cuyo nombre viene del uso conjunto de transistores PMOS y NMOS en los mismos circuitos. Procesadores más antiguos, comos los usados en las consolas y ordenadores de 8 bits, también usaban transistores MOSFET, pero sólo los de tipo NMOS. Puestos a elegir, tienen un mejor desempeño que sus parientes los PMOS, debido a que la movilidad de los electrones en silicio es mucho mayor a la de los huecos. En CMOS se requiere un transistor de cada tipo para todo. En efecto, esto implica que son necesarios más transistores para realizar una misma función, algo que a primera vista puede parecer contraproducente. Sin embargo, la tecnología CMOS tiene beneficios muy importantes, sobretodo en tema de consumo y rendimiento. No voy a profundizar más, pero la idea que subyace en esta estrategia es conseguir que los circuitos únicamente consuman potencia en las transiciones de estado, es decir, mientras se pasa de «1» a «0», o viceversa. Algo que no era posible en los antiguos procesadores NMOS. La magia de los transistores es posible gracias a los semiconductores, que no son aislantes, ni tampoco son buenos conductores, como los metales. El silicio es el semiconductor más usado en la actualidad y lo ha sido desde mediados de los 60, cuando superó al germanio. Gracias al dopado con determinadas impurezas, se consiguen semiconductores de tipo P (con exceso de huecos) y de tipo N (con exceso de electrones), y se puede controlar su conductividad, así como otras características. Por ejemplo, un diodo, un dispositivo capaz de dejar pasar corriente únicamente en un sentido, y no en el otro, está compuesto por un semiconductor con dos zonas, una N y una P. El campo electrico formado en la unión entre ambas zonas al redistribuirse el exceso de portadores de cada lado, hace la «magia». Igualmente, un transistor requiere tres zonas, N-P-N, o P-N-P, y de aquí precisamente surgen los tipo NMOS y PMOS. En general, los transistores MOS se fabrican sobre obleas de silicio. En función de cómo se trabaja su superficie y cómo se va dopando se pueden crear transistores, diodos, resistencias o condensadores que luego se unen con conexiones metálicas a varios niveles.

Foto exclusiva de una oblea de circuitos integrados diseñados por la empresa española SIDSA.
Hay que recordar que en chips fabricados, por ejemplo, a 65 nm (nanómetros), los elementos pueden llegar a estar separados por una distancia de tan sólo 65 nm. En nuestra escala, ¡esto es muy, muy cerca! Hacer cosas tan pequeñas con tanta precisión no puede lograrse con métodos puramente mecánicos. Las diminutas estructuras se van formando gracias a técnicas de fotolitografía, usando revestimentos fotosensibles, que de forma similar a la superficie de una película fotográfica, son alteradas por la incidencia de luz. La idea básica es usar máscaras, plantillas con zonas oscuras y transparantes, para transferir patrones sobre la oblea. De este modo se puede eliminar una parte muy concreta de la resina, controlando qué zonas son y no son iluminadas, y así controlar con mucha precisión las áreas sobre las que se trabaja. Una mota de polvo podría arruinar un chip entero. Por eso, las instalaciones donde se realizan los pasos críticos requieren un ambiente mucho más limpio que el de un quirófano. En concreto, según un estándar, menos de 35 partículas de como mucho media micra, por cada metro cúbico. Para hacerse una idea, en una habitación normal esta cifra se podría contar en cientos de miles, o millones, además de albergar otros muchos contaminantes letales para un chip «desnudo». La tecnología necesaria es muy costosa y fabricar un chip mínimamente complejo es extremadamente caro (hablamos de un millón de euros como poco). Una vez que el diseño está hecho y se tiene el prototipo, las sucesivas copias son más baratas, porque el proceso está altamente mecanizado. Sin embargo, para que resulte rentable se requiere un volumen mínimo de producción y venta. Dicho esto, me gustaría hablar sobre el tamaño de los procesadores de las actuales consolas de sobremesa. ¿Por qué? ¿Qué puede tener de interesante? Puede parecer demasiado friki, incluso enfermo, pero no lo es tanto. El área de silicio que requiere un chip para ser fabricado da, en primer lugar, una idea del coste que conlleva. El beneficio que se obtiene con un determinado chip decrece muy pronunciadamente según aumenta el área ocupada. Esto quiere decir que una ligera reducción en el área, puede implicar un gran ahorro. Es el mayor motivo por el cual los principales chips de muchas consolas acaban, en versiones posteriores, siendo fabricados en una tecnología más pequeña, como ha ocurrido con PlayStation 3 y Xbox 360, cuyos procesadores y chips gráficos, originalmente fabricados en tecnología de 90 nm, han pasado a procesos de integración de 65 nm. Al ocupar menos área, se obtienen un mayor número de chips por cada oblea, consiguiendo además que el porcentaje de unidades defectuosas decrecezca. Así pues, se obtiene un mayor rendimiento económico (
throughput o
yield, en inglés). El conocer el tamaño de procesador y GPU de Wii son una ayuda inestimable a la hora de deducir cierta información sobre ellos, además de hacerse una idea de su complejidad, en comparación a sus competidores (para lo que hay que tener en cuenta otros factores más complejos). He preparado una pequeña tabla-resumen para ilustrarlo.

En esta tabla, el tamaño está mm², y entre paréntesis, el número de veces en que superan en tamaño PS3 y Xbox 360 a Wii. Todos ellos en tecnología de 90 nm., es decir, el hardware tal cual vio la luz por primera vez en el mercado. Salta a la vista la enorme diferencia de tamaño que hay en las CPUs. El veterano procesador de Wii es diminuto.

Xbox 360. Chip gráfico.
Lo que llamo GPU de Xbox 360 está compuesto por dos chips independientes. Xenos (marcado en rojo), que contiene el «
northbridge» y el procesador gráfico en sí mismo, por un lado, y un chip con circuitería adicional y 10 Mbytes de memoria eDRAM (en amarillo) al servicio del sistema gráfico (y que como ya mencioné en el quinto artículo, es muy rápida, y permite, por ejemplo, antialiasing casi gratuito en muchos casos).

Wii. Procesador, chip gráfico, northbridge, memoria 1T-SRAM, DSP.
La GPU de Wii, Vegas (señalado en rojo), de sólo 9 x 8 mm., como en el caso de Xbox 360, es en realidad northbridge + chip gráfico. Muy próximo está Napa (en amarillo), de 13.5 x 7 mm., que contiene un procesador digital de sonido (
DSP, en inglés), junto a los 24 Mb de memoria 1T-SRAM que ya existían en GameCube alojadas en dos chips independientes (ver imagen inferior). Esta 1T-SRAM es parte de la memoria principal de la consola y no debe ser confundida con los 10 Mbytes de eDRAM de Xbox 360 ya mencionados, que son endiabladamente más rápidos y se usan principalmente como buffer de video. El chip gráfico en Wii, Vegas, también tiene una memoria embebida que usa como buffer de vídeo y memoria de texturas (de la que hablé en los dos anteriores artículos), pero de sólo 3 Mbytes, y con unas pretensiones mucho más modestas.

GameCube. Sus dos chips de memoria RAM (1T-SRAM), de 12 Mbytes cada uno.
A modo de recordatorio, a pesar de que parece que la CPU y GPU de Wii son muy parecidas a las de su predecesora:
- Flipper (la GPU de Gamecube) tenía un tamaño de 110 mm².
- Gekko (la CPU de Gamecube) ocupaba 43 mm².
Como puede verse, las versiones usadas en Wii son más pequeñas que las originarias de GameCube, y son por tanto más baratas de fabricar. Esta reducción de tamaño en los chips de Wii se debe principalmente a que en su antecesora se usaba una tecnología de integración de 180 nm., mientras que en Wii se pasó a 90 nm. Hace tiempo que la tecnología de integración de 65 nm. llegó a esta generación de consolas, al menos en Xbox y Playstation. Respecto a 90 nm., los chips en 65 nm. quedan reducidos a la mitad de superficie (porque la resolución aumenta en las dos dimensiones), lo que los hace más baratos. Además, al tratarse de tecnología CMOS, esto implica un menor consumo, y por tanto, menor generación de calor, algo beneficioso para el usuario. Y en el caso de la Xbox 360, parece haber contribuído inestimablemente a reducir la elevadísima tasa de fallos que ha sufrido desde sus comienzos (como las temidas y famosas «tres luces rojas»). Pero los 65 nm. no son, a estas alturas, ni mucho menos, la cresta de la ola. En los ordenadores personales se acaban de estrenar los 32 nm. en CPUs, y hace ya un poco, los 40 nm. en GPUs. Como anécdota, la industria de los chips se enfrenta a un nuevo reto en la actualidad, para poder mantener su ritmo de miniaturización. Se sigue empleando la fotolitografía óptica, con luz ultravioleta de 193 nm. de longitud de onda, pero pronto será imposible seguir reduciendo la escala de integración sin usar otro tipo de tecnología para transferir los patrones a la oblea. Entre los candidatos a reemplazar la fotolitografía óptica están la fotolitografía de ultravioleta extremo (EUV), que todavía no está lista para su implantación, y la fotolitografía de haz de electrones (
e-beam), que está, si cabe, aún más lejana. Debido a este contratiempo, los grandes fabricantes buscarán formas de optimizar al máximo la tecnología actual para los 22 nm., pero es posible que el salto a los 15 nm., dentro de unos pocos años, requiera un cambio. No es ni mucho menos la primera vez que la industria se encuentra con un obstáculo así. De hecho, hace no muchos años hubo que superar un problema importantísimo, debido a que uno de los componentes más delicados de los transistores MOS, el llamado «óxido de puerta» (un aislante requerido en uno de los terminales de cada transistor), había alcanzado una delgadez tan extrema, que no permitía seguir reduciendo el tamaño de los transistores, sin degradar sus características. Esta delgadez no era ninguna tonteria, llegando al grosor de tan sólo 5 capaz atómicas. En esa escala, este aislante empezaba a dejar de serlo, debido en parte a efectos cuánticos. Brevemente, un electrón deja de ser una «pelotita» diminuta, para convertirse en una onda, con una probabilidad de encontrarse en un determinado lugar. El aislante era tan fino, que el rango en el que era probable encontrarse caía a ambos lados del mismo, pudiendo así atraversarlo. Este efecto producía fugas de corriente, con efectos parásitos, que aumentaban el consumo, perjudicando el desempeño del transistor. Tras varios años de investigaciones y duro trabajo, este escollo se superó recurriendo a nuevos materiales, como el hafmio, con una constante dieléctrica más alta (mejor aislante) que el óxido de silicio. Su coste era más elevado, encareciendo la producción, pero era razonable, y sobretodo, necesario. Se les conocen como materiales «
high-k» (o de «alta-k», donde «k» hace referencia a la constrante dieléctrica). Estos transistores MOS mejorados empezaron a usarse en los procesadores de las grandes compañías en los 45 nm., como Intel en su Core 2 Duo «Penryn», y también AMD en sus nuevos Athlon/Phenom. Este ritmo de miniaturización tan agresivo, que ha sido casi constante desde la aparición de los primeros circuitos integrados, se ajusta a la famosa
Ley de Moore. Volviendo a las consolas, es interesante mencionar que cuando PlayStation 2 salió al mercado, su procesador, Emotion Engine, ocupaba 226 mm², y su sintetizador gráfico, 279 mm². Tamaños muy similares a los de su sucesora (230 y 258 respectivamente). En otras palabras, los transistores son más pequeños, pero al haber un mayor número de ellos, se «compensa», por decirlo de alguna manera. Para ver la evolución desde otro punto de vista, es interesante saber que en las primeras PS3, que llevan incorporado el hardware completo de una PS2, ambos, el Emotion Engine y el Graphic Synthesizer, están integrados en un único chip de tan sólo 87,5 mm². Los dos. Pero a pesar de poder, gracias a los avances de la minutuarización, comprimir casi toda una PS2 en un pequeño espacio (ver en amarillo, imagen inferior), fue suprimida en posteriores versiones, perdiendo así la retrocompatibilidad total. Supongo que el motivo de esta decisión son los estrechos margenes de beneficios en los que se ha movido Sony.

PlayStation 3. Chips que integran los principales componentes de PS2 marcados en amarillo.
En tema de consumos hay poco que comentar. Me atrevería a decir que sólamente el procesador de PS3 podría «tragar» entre 3 y 5 veces lo que toda la Wii, ambos a plena carga. La simplicidad y el uso de un único núcleo hacen del procesador de Wii un dispositivo muy eficiente, que con una arquitectura obsoleta está dando la talla. Su consumo está quizá unas diez veces por debajo del de PlayStation 3, una buena cifra teniendo en cuenta que en cuanto a velocidad (en ciclos de reloj) se refiere, es unas cuatro veces y media más lento (3200 MHz vs 729 MHz), pero es también una buena cifra para el Cell, que dispone de ocho núcleos secundarios, mucha más memoria y un complejo sistema de interconexión que alimentar. Así pues, ambos chips son francamente buenos en sus respectivos niveles y para sus objetivos. Bien empleado, y exprimido al máximo, Cell es capaz de alcanzar un desempeño con una mejor relación de consumo que el chip de Wii. Pero si lo que se busca es un rendimiento moderado, entonces el bajo consumo del procesador de Wii resulta muy atractivo y adecuado. Por cierto, la CPU de Wii, «Hollywood», debe de estar compuesta por algo más de 20 millones de transistores. Una cifra muy modesta para los tiempos que corren, y que en cualquier caso debe de estar próxima a los 21 millones que componen cada uno de los ocho SPE del Cell, pequeños procesadores optimizados para cálculo vectorial ((De estos 21 millones, sólo una tercera parte la componen los circuitos lógicos, mientras que el resto se emplea en memoria local de alto rendimiento, donde se reciben del núcleo principal las instrucciones a ejecutar y usa como RAM local.)). En cuanto a número de transistores, Cell al completo debe de estar unas diez veces por encima de Hollywood, lo que justifica su mayor coste y también su elevado rendimiento, y es por esto que una aplicación bien programada hace palidecer al diminuto procesador de la pequeña consola de de Nintendo. Y el último «por cierto». De los ocho SPE de Cell, uno viene desactivado en las PS3, precisamente para aumentar el «
throughput«, o rendimiento económico, del que antes hablaba. Es fácil de entender que por la complejidad intrínseca en la fabricación de circuitos integrados, un determinado número de chips saldrán defectuosos. Y de todos los Cell, habrá algunos que tengan la memoria caché dañada, o el core principal, o su circuitería de interconexión, y deberán ser desechados. Habrá otros «Cell» que tengan múltiples defectos, e igualmente deban ser descartados. Pero por simple estadística, habrá otros donde uno y sólo uno de los SPE esté dañado. En este caso, durante el proceso de test al que se somete a todos los circuitos integrados, se identifica, y se deshabilita el SPE problemático, pudiendo salvarse el chip, y ser montado en una consola. Desconozco cómo se realizará el proceso, pero una técnica habitual consiste en emplear un láser para cortar determinados puntos en el chip, y así deshabilitar ciertas funciones, para venderlo como un módelo inferior, por ejemplo. Este tipo de «recortes» son muy habituales en el mundo de los ordenadores.
Conclusiones
No podría acabar esta serie, escrita a lo largo de varios años, no solo sin una conclusión, sino sin volver a repetir que aunque la orientación ha sido casi totalmente hardware, las consolas se rigen por patrones diferentes a otros computadores y sistemas informáticos. En el mundo de las videoconsolas, los videojuegos son los que dan significado al hardware. Cuando se busca un ordenador potente para trabajar sobre cierta aplicación, el rendimiento y sus capacidades definen casi totalmente al aparato, al lado de otras consideraciones como el precio, tamaño, coste de operación y mantenimiento, etc. En una consola, uno busca diversión. No es necesario un rendimiento extra por parte de la electrónica si no aporta nada a la experiencia de juego. Y sobre todo porque aunque poco a poco esto vaya cambiando, una consola sólo vale para jugar, con ciertas salvedades. En cualquier caso no es como un PC, en el que si un día decides hacer diseño web, o edición de video, o producción musical, puedes hacerlo. Donde tampoco puedes instalar software no firmado o aprobado, ni cualquiera puede desarrollar aplicaciones, sin necesidad de pagar royalties ni pasar por la aprobación de su fabricante. El catálogo de software, en este caso juegos, para una consola, es quizá su punto más fuerte. La Wii ha demostrado con creces que un sistema barato, pequeño, ligero, cómodo y con visión y originalidad, puede fácilmente plantar cara a monstruos computacionales. Algo que en otro terrenos sería impensable, en las videoconsola se vuelve real. Y esa «magia» es lo que le da ese toque genuino. Y mi objetivo con estos artículos ha sido claro; hacer llegar a cuantos más mejor, conceptos sobre el hardware y su rendimiento, en esta
Carrera de los bits y los megahercios, así como ilustrar cálculos sencillos y ejemplos reales. No he buscado ser estrictamente riguroso ni actual. Con lo primero quiero decir que he preferido dar una visión de conjunto antes que un detallado examen númericamente exacto. Con lo segundo quiero decir que no he pretendido hablar sólo de cosas de actualidad palpable, precisamente porque la tecnología avanza muy rápidamente y a menudo los pasos son fugaces. En otras épocas de la historia, tradiciones era transmitidas de generación en generación, a menudo sin muchos cambios. Ahora, a lo largo de la juventud de una persona, tienen lugar a su alrededor verdaderas revoluciones en el aspecto técnico: nuevos lenguajes y tecnologías de programación obligan a una intensa renovación a nivel profesional, plataformas de hardware constantemente cambiantes, donde quedar desfasado es cuestión de un breve espacio de tiempo y cantidades ingentes de conocimientos se tornan inútiles. Por eso yo soy partidario de aprender mirando al pasado, admirando las maravillas que en su momento se hicieron con máquinas que aunque hoy sean «antiguallas», no dejan de ser maravillas, precisamente porque en algún momento lo fueron. Gracias a los ingenieros y diseñadores que trabajaron codo con codo, y también frente a frente, durante los orígenes de los ordenadores, y más tarde de las máquinas de videojuegos, hemos llegado a una época de esplendor gráfico y una mayor expansión, que nadie sabe a dónde conducirá. Pero de momento estamos aquí, listos para vivirlo, ¿no? Aunque el contenido y el nivel de los expuesto ha sido muy variado, y entiendo que no al alcance de todo el mundo, me gustaría pensar que todo aquél que ha tenido la paciencia y el interés suficiente en leer los nueve artículos que han compuesto esta serie, hayan disfrutado y aprendido algo, al menos lo suficiente para no caer en terrenos puramente utópicos, como los en su día anunciados «75 millones de polígonos por segundo» de PlayStation 2, o los «125 millones» de Xbox, que son fantasmadas de un calibre muy importante. Si bien son cifras teóricamente alcanzables, que se pueden deducir numéricamente (luego no son mentiras como tales, sino un engaño disimulado), en un juego real ninguna de estas máquina puede ni siquiera soñar con tales cosas (de hecho, seguramente tampoco las de esta generación). Por mojarme un poco, me atrevería a decir que una cifra realista podrían oscilar entre unos 10 y unos 15 millones de polígonos por segundo.. Me gustaría mucho recibir comentarios tanto si sólo habéis leído este artículo, como si habéis seguido la serie entera, tanto si son críticas, como felicitaciones, o correcciones. Ha sido un placer compartir lo poco o mucho que sé con todos vosotros. Seguiré escribiendo.
Solo los usuarios registrados pueden comentar - Inicia sesión con tu perfil.
Se agradecen estos artículos técnicos. Poco mas que decir porque de esto no tengo ni idea, tal vez despues de leerlo un poquito mas. Que nintendo no desvele datos sobre la wii, es lógico, como un buen «Mago» no desvela sus trucos de «Magia».
Realmente buenos los contenidos de cada tema. Felicidades y ánimos para seguir con nuevos artículos.
Intentaré sacar un poco de tiempo para leerme este también que suelen estar interesantes estos artículos.
A pesar de que David escribe de año en año (o es Anait la que los dosifica), estos artículos son muy, pero que muy, interesantes.
Estos 9 -por el momento- artículos son dignos de ser guardados en un índice en la barra de marcadores del navegador, sinceramente.
Sólo me queda animar al autor a que siga regalándonos estos pedazo de artículos, que engrandecen, aún más, AnaitGames.
Gracias.
Vaya, la serie de artículos que me hizo visitar asiduamente anait se ha acabado. El fin de una era. He disfrutado un montón, David, y aunque algunas cosas se me escapan en general he vuelto a aprender bastante (sobretodo el tema de cómo funcionaba un pipeline, que es algo que siempre me ha intrigado y nunca me he molestado en averiguar). Hay un plural con z por ahí pero como no podía dejar de leer ahora no se en qué página está enterrada XD
Qué tiempos, con la Última explicaba que la N64 realizaba este tipo de iluminación por hardware (aunque supongo que se aplicaría por soft en otras consolas porque era un método de lo más usado en las 32 bits).
Ha sido un placer y espero que aunque hayas acabado por ahora nos puedas echar una mano con lo que salga hacia el 2013-2014 y las locas estructuras que estarán preparándose para desterrar a nuestras vetustas PS3s y 360s.
Un par de dudas ¿la iluminación, HDR, y efectos especiales como los cuerpos volumétricos o el motion blur se cargan en los ROP? Pensándolo bien creo que necesitamos unos cuantos artículos más, é XDD
Acojonante el curro que te has pegao con el artículo. No conocía la existencia de los 6 anteriores, pero viendo este deben ser al menos igual de buenos.
En favoritos queda y… que escribas muchos más!
WHOA!
Felicidades David, yo como Ingeniero Electronico me siento acojonado de ver el altisimo nivel y la calidad en la simplificacion de la informacion que haz realizado;sinceramente estos articulos podrian ser candidatos a tesis de Ingenieria.
Estos articulos deberian tener una importancia especial aqui en Anait; no pueden pasar como un articulo cualquiera, son un trabajo impecable explicado de una manera increible
Poner todo esto en un PDF para bajarlo… POR FAVOR!
me saco el sombrero ante este artículo.
Geniales todos, aunque de los primeros ni me acuerdo ya. Los tengo guardados en disco así que volveré a releerlos todos en breve.
Por cierto:
¿Y ahora qué?
mi cavernicola yo no entender
Al poco de descubrir esta página publicaste el 7º post de esta serie y me leí los 7 del tirón. Solo puedo decir gracias una vez más. Gran trabajo
Muy buenos articulos, me gustan todos.
En primer lugar, y como suelo decir, muchas gracias a todos (sin excepción), por vuestros comentarios, felicitaciones, críticas,… (aunque en esta ocasión no ha habido críticas, jeje). Lo que significan estos artículos está completo gracias a vosotros, y no podría estarlo sin vosotros.
También quiero decir que tomo nota de todo lo que habéis propuesto, y que cerrar esta serie no es para retirarme, sino para renovarme; ya estoy trabajando en nuevos y novedosos (espero) artículos, para cambiar de rumbo, sin dejar de lado la filosofía de acercar aspectos interesantes (y a menudo tan cotidianos como desconocidos) a la mayor cantidad de personas posible.
Adelanto ya que serán al menos 2 nuevos artículos, que espero que podáis leer pronto. Además, me consta que están trabajando desde Anait para poder publicarlos con mayor brevedad.
Desde luego que estaré al loro para escribir sobre nuevas arquitecturas que vayan surgiendo, a modo de addendum a esta carrera de bits y megahercios. El nivel de detalle y la rapidez dependerá del tiempo que pueda dedicarle, no os voy a engañar. Acepto que me metáis caña
Miguel Angel Martínez, a tu pregunta, y hasta donde yo sé, en los ROP se cargan todos los píxel que van a parar al buffer de video, y por ende, a la pantalla. Los efectos o bien se han aplicado ya por shaders, por software, por alguna otra característica hardware de la GPU, o se aplican en esta última etapa. No creo que exista un post-procesado una vez que se sale de los ROP.
Hasta donde yo sé, el requisito para hacer HDR por hardware es el soporte hardware de la versión 2.0 de shaders (aunque también tiene una carga software). Por tanto, supongo que estos efectos se hacen en los shaders o stream processors de lar arquitecturas unificadas. Aún así no lo tomes como una respuesta definitiva.
Las imágenes HDR, al contrario que una «normal», usan un rango de valores de color más amplio. Es decir, en lugar de representar los colores normalizados entre 0,0 (negro absoluto para el monitor) y 1,0 (blanco absoluto para el monitor), se usa un rango mucho mayor, lo que permite contener más información. Luego, para representarlo, se «sub-muestrea» (por así decirlo) para acabar teniendo una imagen «normal» para el monitor (de las de entre 0,0 y 1,0). Aunque se acabe con una imagen «normal» en ambos casos, el resultado es mejor en HDR, porque la fuente contiene inicialmente más información. Los resultados se evalúan mejor viendo ejemplos, que analizando los números.
Si me dejo algo, por favor, no dudéis en preguntar.
Pues bien (joer a la de días que escribo), tenía éste artículo como lectura pendiente, y hoy por fin, he sacado tiempo para poder leerlo y comentar algo. Qué decir, que me ha parecido un final genial, para una serie de artículos geniales, quizás para mi gusto, me hubiese gustado que profundizasen algo más, pero es lógico que deban ser «para todos los públicos». Así que nada, a esperar la siguiente serie de artículos con ganas.
Muy buenos artículos (lástima que un poco complejos para el común de los mortales! :S) por otra parte sirve para tener en cuenta el títánico labor que hay detrás de cada hardware y software (que muchas veces lo damos por sentado sin mas), ya sea para trabajar, crear o para -lo que nos compete a nosotros- invertirlo en ocio. Gracias y espero los siguientes artículos, sobre todo si tienen datos interesantes, como este con el grosor de 5 capaz atómicas del material dieléctrico! me dejó muy sorprendido.
La verdad,han sido muy instructivos tus artículos,es de agradecer que satisfagas las ansias de conocimiento en harware,que tenemos los jugones,de una manera amena e instructiva además de facil de entender.
En lo único que discrepo es en considerar que Dreamcast sea una consola de trancisión,ya que fué la primera consola de sexta generación(QUE NO DE 128 BITS COMO TU ACLARASTE) y así la clasifican en muchas fuentes de información.Además gracias a tus datos me doy cuenta que entre Dreamcast y PS2,Gamecube Y XBOX,hay mucha menos diferencia de poder que la que hay entre WII vs PS3 y XBOX 360(las consolas de 7ma generación)la poca vida util de Dreamcast se debió más bien a los errores de Sega(32x Mega CD),la falta de recursos de la compañia por tales errores,la pérdida de credibilidad,y la no inclusión de un lector de DVD.
SALUDOS Y MUCHAS GRACIAS.
Sorry,escribí mal la palabra Hardware….
Lo que pretendo decir,es que Dreamcast tuvo una corta vida útil,por motivos distintos a la falta de poder que tenía con respecto a las demás consolas de sexta generación,de lo contrario WII estaría completamente perdida y resulta que va ganandole a consolas muchísimo más poderosas que ella…uuuf!!! espero que ahora me haya dado a entender.
Para cuando un artículo de SNES vs Génesis(Mega Drive)???
Ese sí que estaría genial para los que disfrutamos esa época!!!
Muchas gracias!!
Una cosa no quedó muy clara…¿cuantos polígonos mueve Wii??tanto planos como texturizados…