Antes de empezar a entrar en detalle sobre la WiiU hay que tener en cuenta una cosa: la arquitectura de memoria de un sistema es sin duda la parte clave del diseño.
La memoria es la base sobre la que se construye un sistema, y si falla esa base, el conjunto se va al garete.
Cuando se habla del diseño de la arquitectura de memoria de un sistema hay que tener en cuenta dos conceptos:
1. El "nivel" de la memoria.
2. El coste de la misma.
Cuanto más bajo es el nivel de una memoria más alto es su rendimiento y también su coste. Así pues, en mi análisis de la WiiU me referiré a 5 niveles de memoria: Registros-Caches-RAM Embebida-RAM-BlueRay/Disco-Duro.
Esos niveles representan el grado en el que una celda de memoria concreta se aleja del núcleo del diseño, es decir, de los chips que accederán a ella. Los niveles más bajos se encuentran hoy en día dentro de los propios chips, mientras que el nivel más alto es externo y ofrecerá el rendimiento más bajo.
Y cómo se mide el rendimiento de una memoria?
Pues básicamente a partir de dos parámetros, el ancho de banda, y las latencias.
El ancho de banda es la cantidad de datos teórico que la memoria puede proporcionar a quien se los pida. Se calcula multiplicando el ancho del bus de datos por la velocidad a la que opera la memoria.
Así pues, un bus de 64 bits con una memoria que opera a 324 Mhz tiene un ancho de banda de un poco más de 2,4 GB/s (324 *1000 * 1000 * 64 / 1024 / 1024 /1024 / 8, que es el ancho de banda que tenia la memoria principal de la GameCube. Si alguien lo busca encontrará con frecuencia la cifra de 2,6 GB/s, pero ese cálculo no tiene en cuenta que Mega en hercios significa 1000*1000 mientras que en memoria, por la naturaleza binaria de los bits, significa 1024*1024).
El segundo aspecto a tener en cuenta es la latencia. Cuando le pedimos a una memoria en concreto un dato ésa tiene que buscar ese dato y luego entregarlo. El tiempo que tarda en reaccionar esa memoria es la latencia de la memoria.
Existe además otro factor que influye la latencia, y ese es la distancia entre los chips de memoria y el chip que hace la petición.
Pensad que estamos hablando de CPUs que corren en los Giga Hercios. Un giga-hercio significa que en un segundo se ejecutan mil millones de ciclos. O dicho de otra manera, un ciclo dura 1/1000.000.000 de segundos.
Cada centímetro y milímetro de más que haya entre la memoria y el chip en cuestión supone unos ciclos extra de latencia que aún sin ser culpa de la memoria en si, sí que afectan al rendimiento del chip que está a la espera.
Y cómo se traduce eso en el rendimiento REAL de la memoria?
El ancho de banda no deja de ser un dato teórico. Es decir, sería el máximo de datos que la memoria puede transferir sin tener en cuenta búsquedas de ningún tipo. En el caso de memorias estáticas o pseudo-estáticas, con latencias nulas si están embebidas en el mismo chip, ese ancho de banda teórico se corresponde con el real.
Pero cuando las latencias (ya sean por tipo de memoria o por distancia de la misma respecto al chip que la demanda) entran en juego, entonces la cosa cambia. Cada vez que se hace una búsqueda de un paquete de datos en la memoria se pierden ciclos en los que no se envía nada. Así pues, lo ideal para sacarle partido a una memoria es hacer pocas lecturas de paquetes muy grandes.
Existen luego 3 tipos de memoria a tener en cuenta para ese análisis:
1. SRAM o memoria de acceso aleatorio estática. Esa memoria es la que se usa habitualmente en los niveles más bajos. Tiene una densidad muy baja en comparación con el resto de memoria, pues necesita de 6 transistores por cada bit. Como contrapartida ofrece unas latencias nulas (1 ciclo, es decir, le pides un dato y al siguiente ciclo ya te lo entrega), lo cuál es ideal para operaciones a bajo nivel.
Tiene además un diseño muy simple a nivel de disposición de los transistores, con lo que es muy sencillo aplicarle reducciones de nodo.
2. RAM o memoria de acceso aleatorio. Tiene una densidad muy alta ya que sólo necesita un transistor y un capacitador por cada bit de memoria. Sin embargo, requiere de una lógica un poco más compleja (a diferencia de la SRAM en donde el bit de memoria siempre está disponible gracias a los 6 transistores, en la RAM convencional de un transistor se necesita un chip que "refresque" el contenido de la memoria continuamente) y tiene unas latencias un poco más altas.
3. RAM Pseudo-estática. Se trata básicamente de RAM convencional, pero además de la lógica extra del chip de refresco tiene otra aún mucho más compleja que esconde ese refresco (se refrescan todas las celdas de memoria a cada ciclo, excepto la que se pretende acceder, pero para ello se necesitan buffers adicionales), consiguiendo unas latencias equivalentes a las de la SRAM. Las ventajas son una densidad casi tan alta como la RAM convencional (cada bit necesita sólo de un transistor y un capacitador y lo único que hay extra de espacio es esa lógica adicional) y unas latencias tan bajas como las memorias SRAM.
Las desventajas son que esa lógica adicional complica mucho el diseño haciendo que la reducción del tamaño de los transistores sea mucho más difícil y que el hecho de que el diseño esté a manos de menos empresas encarezca el coste incluso más.
A todo eso, un avance que se hizo sobre la RAM es la tecnología de buses DDR. DDR, es decir, double data rate, hace que por cada ciclo de la memoria se puedan enviar dos bits de datos. Eso afecta al ancho de banda de la memoria, que pasa a ser el doble si se implementa siguiendo esa tecnología, pero no a las latencias, ya que la velocidad interna de la memoria sigue siendo la misma.
Aunque no hablaré de ello en ese análisis, la GDDR5 envía 4 bits por ciclo, doblando aún más el ancho de banda.
Explicado eso, entremos a analizar de qué se compone la arquitectura de memoria de la WiiU.
De los registros de memoria de la CPU ya hablé en su respectivo hilo, es la memoria inmediatamente conectada a las unidades de lógica de la CPU y no voy a añadir nada que no hubiese dicho ya en aquel hilo. En lo referente a la GPU, sólo podría especular en ese sentido, así que no voy a entrar en más detalle que el decir que como mínimo estará en ese sentido tan servida como un chip R700 de ATI estándar, que es el diseño base sobre el que se creó la GPU de la consola.
Así pues, a grandes trechos la arquitectura de memoria de la WiiU se compone de lo siguiente:
1. Banco principal de memoria de 32 MB. Esa memoria está embebida en el chip de la GPU y es del tipo pseudo-estático. Su latencia es nula (como ya he explicado) y su ancho de banda desconocido. Se especula con un bus de 1024 o 2048 de ancho (sacado de Neogaf, de una foto en alta resolución que permite un conteo aproximado) y si esa memoria va a la misma velocidad que el resto del chip (es lo mínimo que tendría sentido, y eso son 550 Mhz), entonces estaríamos hablando de entre 70 y 140 GB/s de ancho de banda.
2. Banco grande de memoria de 2GB. De ese tenemos toda la información. Está conectado con un bus de 64 bits y opera a 800Mhz. Como es del tipo DDR, su ancho de banda total asciende a los 12.8 GB/s.
3. Caches adicionales de la GPU de 3MB. Esos 3MB de la GPU se corresponden con la memoria embebida de la GC, así que las especificaciones conocidas las podemos extrapolar a la WiiU.
Los 3MB de caches para la GPU en la WiiU eran 1MB dedicado a cache de texturas (SRAM, sólo lectura desde la GPU y con un ancho de banda de 10,4 GB/s a una velocidad de 162Mhz) y 2MB dedicados a buffers (RAM pseudo-estática de escritura y lectura, con un ancho de banda desconocido pero especulado en 2,6GB/s para lectura y 2,6GB/s para escritura como mínimo). A 550 Mhz eso se traduce en 35,36GB/s de lectura desde el MB de cache de texturas, y 8,84GB/s tanto de lectura como de escritura para los otros 2MB que ahora ya no serán exclusivamente para buffers (la RAM principal de 32MB es lo suficientemente rápida como para contener-los).
Se trata de una especulación bastante segura, pues el ancho de banda por MB es más que suficiente con lo que no tiene sentido esperar que ese bus se incremente, y la velocidad de la memoria tiene que ser como mínimo igual a la del resto del chip si se pretenden latencias de 1 ciclo, que es evidente que se pretenden.
4. Caches inherentes del diseño. En el caso de la GPU no sabemos exactamente cuales son, así que como mínimo supondremos que los del diseño base del R700. En el caso de la CPU, nos fijaremos en la L2 que es de 3MB (512KB para los núcleos secundarios y 2MB para el principal).
Otra cosa que se ha filtrado por Marcam via twitter (el hacker que filtró las velocidades de reloj), y que parece bastante segura (sus informaciones, las que se han podido verificar, coinciden) es que el ancho de banda de la RAM principal es, en relación a su tamaño, inferior al de esos bancos de caché. Teniendo en cuenta que esos bancos tienen de media 17,68 GB/s (edición: antes estaba en 14,73 pero en realidad la media es de 17,68 ya que sólo había contado 8,84 entre lectura y escritura cuando en realidad son 8,84 para lectura y 8,84 para escritura) por cada MB de memoria como mínimo, si se cumple lo dicho tenemos que el banco principal no superará los 565,76GB/s (antes 472GB/s) de ancho de banda (tampoco es que nos aporte mucho, pero sirve para acotar aunque sea por lo muy alto).
Bien, pues, es hora de establecer una comparación con Xbox 360 (consola de la que conocemos lo que puede ofrecer) para hacernos una idea de lo que significan esos datos.
La arquitectura de memoria de la Xbox 360 es la siguiente:
1. Banco de memoria principal de 512MB con un ancho de banda de 22,4 GB/s (128 bits a 700 Mhz DDR).
2. Banco secundario de 10MB para la GPU. Tiene un ancho de memoria de escritura desde la GPU de 32GB/s y de lectura INTERNA de 256 GB/s.
3. Caches inherentes al diseño. Como en el caso de la CPU de la WiiU, sólo voy a tomar como referencia la L2 para simplificar las explicaciones. La L2 del Xenon (CPU de Xbox 360) es de 1MB de tamaño.
En el caso de la GPU, si no recuerdo mal es un diseño parecido al X1900 de ATI, así que más o menos irán por ahí los tiros, pero las caches de las GPU no las voy a tener en cuenta en ese análisis por falta de datos.
La primera gran diferencia salta a la vista. Mientras que en Xbox 360 el banco de memoria principal es el grande, de 512MB, en la WiiU el centro de atención es el banco de 32MB de memoria embebida, siendo el banco grande el secundario.
En ambos casos la totalidad de los datos del juego se cargan en el banco grande de memoria, así que partiremos de la velocidad de éste para empezar el análisis comparativo.
En Xbox 360 22,4 GB/s, mientras que en WiiU 12,8 GB/s. Recordemos que eso son valores teóricos, y la primera diferencia en ese sentido es que la latencia de la RAM "grande" de la WiiU es inferior a la del banco equivalente de Xbox 360.
Lo primero es que el superior tamaño de la memoria de WiiU (1GB frente a 480MB para juegos, y en el caso de WiiU posiblemente aún más en un futuro) permite guardar una mayor cantidad de datos. Que significa eso en un juego?
Supongamos por un momento que el resto del diseño es idéntico en ambas consolas, y fijémonos sólo en el tamaño.
Ese 1GB de memoria permite guardar más datos, aunque pueda transferir menos. Ello significaría que el rendimiento del sistema sería inferior en ese supuesto caso, pero podríamos por ejemplo tener un sistema de animaciones más complejo (ya que las animaciones se transfieren sólo en la medida que se necesitan, pero como es lógico en 1GB caben más animaciones que en 480MB), más variedad de personajes o un sistema de LOD más complejo y ajustado (podríamos guardar más modelos en la memoria, con lo que en el caso de la variedad podríamos escoger de un abanico de personajes más amplio para renderizar, y en el caso del LOD podríamos hacer un sistema más complejo en el que podríamos tener más versiones de un mismo modelado para sustituirlas de forma más progresiva, ganando en rendimiento o en detalle, o en ambas cosas incluso).
Ahora sin embargo, incluiremos las caches de la CPU en el análisis. Cada vez que esas caches se llenan es necesario acudir a la memoria que las contenga. Como los 32MB de memoria principal de la WiiU aún no entran en juego, de momento las obviamos.
Como la cache L2 de la WiiU es 3 veces más grande que la de la Xbox 360 se tendrá que acceder a esa memoria "grande" mucho menos, con dos beneficios:
1. Menos datos tendrán que ser transferidos por falta de espacio en las cache, con lo que el consumo de ancho de banda se reduce de forma sustancial.
2. Reduciendo el número de búsquedas, se incrementa el rendimiento de la memoria acercándolo más al valor teórico.
Saltemos ahora a las caches adicionales de la GPU de la WiiU. Como sucede en el caso de las de la CPU, servirán tanto para reducir el ancho de banda consumido del banco grande de memoria como para ahorrarle tiempo perdido en búsquedas, incrementando (otra vez) su rendimiento real.
Pero en donde reside la diferencia más grande es sin duda en el banco principal de la memoria de WiiU, cuyo homólogo en Xbox 360 es mucho más pequeño y también limitado.
En Xbox 360 la GPU está dividida en dos núcleos, el principal y el "hijo". El principal es la GPU en si, mientras que el hijo tiene los 10MB de memoria junto con lógica adicional para efectuar AA por hardware y z-tests.
Esa memoria es sólo de escritura para la GPU y sólo puede ser leída por la lógica adicional incluida en el núcleo hijo. Para leerse desde la GPU hay que copiar el contenido a la RAM principal y luego leerlo desde ahí.
El problema es que 10MB no son suficientes para el propósito de esa memoria. Un buffer de color son 3,52 MB a 720p, si se pretende usar esa memoria para AA sólo podrás llegar a AAx2 y eso sin contar los z-buffers.
En la WiiU, esos 32MB son la memoria principal, y son polivalentes. Se usan para todo, y es ahí donde el banco grande de memoria nota la diferencia con más fuerza. Las operaciones que consumen más ancho de banda son precisamente las que tienen que ver con el framebuffer.
Para entender la importancia de esa memoria, es importante tener claro como funciona el renderizado gráfico con respecto a la memoria de vídeo.
En la WiiU, esos 32MB no serán suficientes para contener los vértices o las texturas, pero sí los buffers.
A grandes trechos, existen dos métodos de renderizado, el forward rendering y el deferred rendering.
En el forward rendering (método tradicional usado hasta ahora) desde un punto de vista de ancho de banda leemos cada objeto de la memoria de vídeo. Sobre ese objeto se aplican transformaciones de vértice, se rasteriza, se aplican transformaciones de píxel y se escribe en el buffer de la imágen. Eso se repite por cada objeto y por cada luz que afecta a ese objeto.
En el deferred rendering calculamos las propiedades de iluminación de cada píxel de la escena y la grabamos en el G-Buffer (un conjunto de buffers necesarios para almacenar esa información, creados a partir de los modelos y las texturas de cada objeto. Contienen información como el color, cómo reflejan la luz, las normales en caso que haya normal mapping, etc. etc.), y luego aplicamos sólo una pasada con esos G-Buffers por cada luz de la escena. A nivel de ancho de banda es una operación más costosa porque necesitamos muchos más bufferes que tendremos que escribir y leer constantemente, pero a nivel computacional el coste es muy inferior.
El deferred rendering se puso muy de moda mientras se diseñaba la GPU de la WiiU, así que no sería de extrañar que esa arquitectura de memoria se pensase para el uso eficiente de ese tipo de renderizado.
32MB son más que suficientes para almacenar todos los buffers implicados en el deferred rendering (y hasta sobran unos cuantos MB para la CPU), así que el impacto de esas operaciones en la memoria grande sería nulo en la WiiU, mientras que en el caso de Xbox 360, sería inevitable.
En resumen, que la memoria principal sean esos 32MB de RAM pseudo-estática hace que el impacto sobre la memoria grande se limite hasta el punto que sólo será necesario acceder a ella cuando necesitemos transferir modelados o texturas (y sonido para el DSP, buffers ya finalizados que se guardan antes de mostrarse por pantalla y etc. etc. de cosas que tienen un impacto muy pequeño en ancho de banda), es decir, objetos grandes que se acceden pocas veces.
En contraposición, el deferred rendering es muy poco viable en Xbox 360 por falta de ancho de banda. Se ha usado una variante (defferred lighting) que tiene un coste computacional más alto pero un menor requerimiento de ancho de banda, y es que la imposibilidad de leer desde la eDram ya hace imposible almacenar allí los G-Buffers, limitando el ancho de banda del sistema a los 22,4 GB/s.
La memoria a bajo nivel, que es la que más impacto tiene en el rendimiento, es muy superior en la WiiU tanto en cantidad como en versatilidad. Se trata de un diseño muy "made in Nintendo" (desde GC, por supuesto) basado en la eficiencia más que en el músculo, y a medida que se diseñen los juegos pensando en esa arquitectura vamos a ver como la diferencia con respecto a las actuales consolas se hace cada vez más patente.