Trasladando de Wii U a NX (II): GPU, DMAE y Memorias

Antes que nada os voy a traducir la siguiente réplica escrita por Sebbbi, quien es programador de la saga Trials y sus perlas de sabiduría  técnica sobre consolas son siempre bienvenidas, es importante leerla para entender el contexto respecto a un elemento en concreto del hardware de Xbox One, la memoria embebida, esto es importante para lo que viene después en la misma entrada en lo que a Wii U respecta y el salto de Wii U a NX.

Mirad algunas de las presentaciones de la GDC y el SIGGRAPH (en los últimos tres años). Se mencionan optimizaciones a medida de la ESRAM por varios equipos. Y estoy seguroque cada juego AAA utiliza fuertemente la ESRAM hoy en día y tiene montones de código para esta. Sin la ESRAM el ancho de banda total de la Xbox One es de 68 GB/seg. Incluso los juegos Indie se están volviendo tan gráficamente intensivos que perder 2/3 del ancho de banda total ya no es una elección realista.
Necesitas dirigir manualmente tu uso de la ESRAM y políticas de localización de esta, mover los datos hacía dentro/fuera y escribir/leer datos hacía/desde la ESRAM utilizando la ESRAM y los Compute Shaders. La ESRAM de Xbox One no es una cache automática, esta es una memoria scratchpad completamente manual. La cache eDRAM L4 de Intel (en algunos  modelos Broadwell y Skylake) por el otro lado es una cache automática. Las caches necesitan un espacio considerable en el chip para los tags de la cache y el hardware coherente. Microsoft (AMD)  probablemente decidieron que una cache manual era más adecuada para una consola, debido a que el código a medida será escrito para la consola de todos modos. Intel por otro lado escogio implementar una cache eDRAM de 64MB/128MB completamente automatizada porque en el software de PC casi nunca se optimiza para una sola arquitectura.
La arquitectura de memoria UMA de las consolas modernas (Xbox 360, Xbox One, PS4) hacen dificil emular juegos en una plataforma con una GPU dedicada (como es el PC). Los juegos de estudios internos de los fabricantes pueden utilizar algoritmos donde la CPU y la GPU estén colaborando estrechamente. Este nivel de (baja latencia) cooperación no es posible en un PC con una GPU dedicada. En general ninguna consola con la que he trabajado ha sido diseñada para ser completamente compatible hacía adelante (he trabajado con 7 consolas). Es siempre un sacrificio hacer la consola anterior completamente compatible hacía atrás. Mientras los desarrolladores tengan permiso para acceder al hardware a bajo nivel, la compatilidad 100% a lo fácil no ocurrira.
La cosa esta en que si Microsoft o Sony no permitieran acceso al hardware a bajo nivel, pero su competidor lo permitiera, los juegos se verían y se moverían con un framerate más suave en la consola del competidor. A nadie le gustaría esto, ni a los clientes y tampoco a los fabricantes. Es mejor dejar a los desarrolladores utilizar el hardware al completo ya que resulta en los mejores juegos.

Voy a aplicar lo que dice Sebbbi a otro sistema con una GPU con memoria embebida y con una organización del hardware muy parecida a la de Xbox One, me estoy refiriendo a Wii U:

wiiu

Wii U tiene en el SoC donde se encuentra la GPU, Latte, unos tres pozos de memoria embebida, estos son:

  • MEM0: Compuesta por unos 2MB eDRAM y 1MB SRAM… Hacen la misma función que el eFB y el eTC de la GX GPU de GameCube y Wii, son memorias automáticas por lo que no requieren el manejo por parte de los desarrolladores para funcionar, aunque su uso solo es para la compatibilidad hacía atrás.
  • MEM1: Compuesta por unos 32MB de memoria embebida, esta memoria no es automática sino manual por lo que ocurre lo mismo que la ESRAM.
  • MEM2: Los 2GB de memoria externa DDR3

Esto se ve mejor definido aquí:

Captura de pantalla 2016-04-29 a las 16.16.23

El hecho que la MEM2 sea la dedicada para texturas es importante por la relación entre ancho de banda de la memoria donde están las texturas, número de unidades de texturas y los shaders. En todo caso hay una cosa me llama la atención de la información del SDK que es la siguiente:

Captura de pantalla 2016-04-29 a las 16.19.01

Lo de los 3GB para la MEM2 llama la atención desde el momento en que si hubiese un modelo con 3GB entonces tendríamos una placa base con 6 chips de memoria en vez de cuatro, el ancho de banda sería mayor en un 50% y el número de Shaders físicos para gráficos pasaría de los 160 a los 240. Es solo un pequeño inciso de algo que me llama la atención.

¿Y que hay de la MEM1? Pues al igual que la ESRAM de Xbox One es de manejo manual como he dicho antes… ¿Y como se que es manual? Pues porque existe una API en el sistema que se encarga del manejo del traslado de memoria desde la MEM2 (memoria principal) a la MEM1 memoria embebida.

Captura de pantalla 2016-04-29 a las 16.25.15

Es decir, el DMA Engine es lo mismo que los Move Engines de Xbox One, realizan la misma función, la cual no es otra que el hecho de poder trasladar datos desde la memoria interna del chip a la memoria externa y viceversa. Por cierto, el rendimiento de las transferencias de una memoria a otra utilizando el DMAE se puede ver en el siguiente gráfico

Captura de pantalla 2016-04-30 a las 15.17.57

El portar un juego de Wii U a una NX con una configuración distinta de memoria y sin el DMAE llevaría consigo los mismos problemas que se enfrentaría un juego a la hora de ser portado a un hardware futuro de Nintendo que prescindiera de la eDRAM y por tanto del DMAE que un juego de Xbox One a un futuro hardware que prescindiera de los Move Engines y la ESRAM… Pero las similitudes no terminan aquí. ¿Verdad que en la documentación de Xbox One los Move Engines/DME son llamados también unidades Swizzle?

xbox-one-gpu-diagram-100051501-orig

En el caso de Wii U/Cafe ocurre lo mismo y es aquí donde entramos en un elemento que es importante y que tienen compartidas ambos hardware… ¿Cual es la ventaja que tiene que la memoria embebida sea de manejo manual? Más que nada el hecho de tener control absoluto sobre como funciona la misma, el handicap es perder ciclos de reloj e instrucciones en manejar en la copia de datos de una memoria a otra.

Una vez explicado de manera general el DMAE veamos la MEM2 y su relación con la GPU.

MEM2 y GPU.

Con tal de evitar conflictos en el acceso a las texturas o partes de estas la memoria principal MEM2 se divide en dos canales (1GB cada una) de 8 bancos distintos:

Captura de pantalla 2016-04-29 a las 16.43.48

Para acceder a un canal u otro de la la MEM2 de manera manual la GPU utiliza el siguiente formato de instrucción de direccionamiento de 32 bits:

SurfaceAddressBits

Los bits 0 a 7 son ignorados, el bit 7 nos marca en cual de los dos canales de la MEM2 se encuentra el dato, los bits 9, 10 y 11 (2^3=8) marcan en que banco puede encontrarse el dato, los bits 12 a 31 sirven para marcar la dirección de memoria dentro de dicho banco. El resto son unos 20 bits que marcan las diferentes páginas de 4KB, la cifra de 32.768 es un direccionamiento de 15 bits realmente por lo que realmente un futuro  sistema podría soportar una cantidad de memoria RAM mayor.

(2^15)*4KB= 131.072 KB = 128 MB

(2^20)*4KB= 4.194.304 KB = 4 GB.

No deja de ser algo anecdótico y es muy difícil que cada uno de los bancos tenga un formato de 4GB cada uno en un futuro pero es importante porque esta es la forma en la que el controlador de memoria de la GPU7/GX2 accede a la memoria principal del sistema. En todo caso hay un handicap en el hardware de Wii U y es que el tercer bit para escoger banco no esta activo, por lo que el total de memoria con el que puede operar la GPU de Wii U es solo con 4 bancos y por tanto 512MB/0.5GB.

Captura de pantalla 2016-04-29 a las 17.05.44

El hecho de esta limitación es curiosa, porque si miramos la placa base de Wii U veremos que tiene 4 bancos de memoria, es decir… 4 chips de memoria, los cuales están encuadrados en amarillo en la siguiente fotografía de la placa base de la consola:

WiiUBoard

Es decir, tenemos uno cuatro bancos que comparten los dos canales entre ambos, no olvidemos que la memoria DDR funciona con con dos canales simultáneos pero es curioso comprobar como el diseño del sistema se hizo pensando en 8 bancos de memoria y que hay posibilidad para ello en un futuro sistema si este parte desde lo hecho en Wii U. Hay que tener en cuenta que estamos hablando de un escenario con los pozos de memoria: interna (MEM1) y externa (MEM2) y el uso del DMAE, todo ello para facilitar la transición de Wii U a NX, por lo que en el caso de la MEM2 tenemos las siguientes configuraciones posibles:

Memoria Bancos Bus Ancho de banda  Densidad
DDR3-1600 4 64 bits 12.8 GB/seg 2 GB
DDR3-1600 8 128 bits 25.6 GB/seg 4 GB
DDR3-1866 4 64 bits 14.9 GB/seg 2 GB
DDR3-1866 8 128 bits 29.15 GB/seg 4 GB
DDR3-2133 4 64 bits 17 GB/seg 2 GB
DDR3-2133 8 128 bits 34 GB/seg 4 GB
DDR4-2133 4 64 bits 17 GB/seg 4 GB
DDR4-2133 8 128 bits 34 GB/seg 8 GB
DDR4-2400 4 64 bits 19.2 GB/seg 4 GB
DDR4-2400 8 128 bits 38.4 GB/seg 8 GB
DDR4-2666 4 64 bits 21.33 gB/seg 4 GB
DDR4-2666 8 128 bits 42.7 GB/seg 8 GB
DDR4-3200 4 64 bits 25.6 GB/seg 4 GB
DDR4-3200 8 128 bits 51.2 GB/seg 8 GB
GDDR5-5000 (Clamshell) 4 64 bits 40 GB/seg 4 GB
GDDR5-5000 4 128 bits 80 GB/Seg 4 GB
GDDR5-5000 (Clamshell) 8 128 bits 80 GB/Seg 8 GB
GDDR5-5000 8 256 bits 160 GB/seg 8 GB
GDDR5-6000 (Clamshell) 4 64 bits 48 GB/seg 4 GB
GDDR5-6000 4 128 bits 96 GB/seg 4 GB
GDDR5-6000 (Clamshell) 8 128 bits 96 GB/seg 8 GB
GDDR5-6000 8 256 bits 192 GB/seg 8 GB
GDDR5-7000 (Clamshell) 4 64 bits 56 GB/seg 4 GB
GDDR5-7000 4 128 bits 112 GB/seg 4 GB
GDDR5-7000 (Clamshell) 8 128 bits 112 GB/seg 8 GB
GDDR5-7000 8 256 bits 224 GB/seg 8 GB
GDDR5-8000 (Clamshell) 4 64 bits 64 GB/seg 4 GB
GDDR5-8000 4 128 bits 128 GB/seg 4 GB
GDDR5-8000 (Clamshell) 8 128 bits 128 GB/seg 8 GB
GDDR5-8000 8 256 bits 256 GB/seg 8 GB

Tenemos un abanico de configuraciones posibles bastante grande, no obstante tenemos que descartar todas aquellas que no nos permitan llegar a un mínimo de rendimiento visual, hay que tener en cuenta que existe una relación directa entre la MEM2 y las unidades de texturas de la GPU y estas con las unidades shader al estar acopladas a estas. Dado que es muy seguro que Nintendo haga uso de la arquitectura GCN para la GPU de NX tenemos que tener en cuenta como son sus controladores de memoria:

Cada controlador de memoria tiene una anchura de 64 bits para dos canales de 32 bits GDDR5 independientes. Para productos de bajo coste, la GDDR5 puede ser reemplazada por memoria DDR3. Para grandes cantidades de memoria, la GDDR5 puede operar en modo clamshell y hacer uso de dos DRAM por canal, doblando la capacidad.

Si miráis la la tabla de arriba veréis que la DDR3 a igualdad de bits que la GDDR5 no es comparable sino que su rendimiento es mucho menor, en realidad la equivalencia es que 64 bits GDDR5 se suelen sustituir por 128 bits DDRn por temas de ancho de banda, es por ello que he decidido tachar todas las configuraciones de 64 bits DDRn de la tabla de arriba, sabiendo esto y teniendo las configuraciones posibles en cuanto a CUs he hecho esta otra tabla:

Bus TMUs CUs Stream Processors
64 bits DDRn/32 bits GDDR5 12 3 192
64 bits/32 bits GDDR5 16 4 256
128 bits DDRn/64 bits GDDR5 24 3+3 384
128 bits DDRn/64 bits GDDR5 28 3+4 448
128 bits DDRn/64 bits GDDR5 32 4+4 512
256 bits DDRn/128 bits GDDR5 48 3+3+3+3 768
256 bits DDrn/128 bits GDDR5 52 3+3+3+4 832
256 bits DDRn/128 bits GDDR5 56 3+3+4+4 896
256 bits DDRn/128 bits GDDR5 60 3+4+4+4 960
256 bits DDRn/128 bits GDDR5 64 4+4+4+4 1024

Las configuraciones de 64 bis DDRn han sido eliminadas de la ecuación por motivos obvios ya explicados y teniendo en cuenta lo que explique en la entrada anterior  he eliminado lo que no supone el mínimo de colocar los juegos de Wii U de 720P a 1080P, por lo que he marcado en rojo la configuración con 384 Stream Processors. Cada array de hasta 4 CUs tiene conexión con la Cache L2 y esta con el controlador de memoria, la jerarquía de cache se ve mejor en el siguiente diagrama:

Captura de pantalla 2016-04-30 a las 10.47.55

Cada 4 CUs en la arquitectura comparten el acceso a la cache L2 y en algunas excepciones por redundancia se colocan hasta 3 CUs por bloque dejando la 4 inactiva y de de ahí la tabla que he hecho antes en cuanto al número de CUs, aquí se ve mucho mejor con configuraciones de 4 CUs:

Captura de pantalla 2016-04-30 a las 11.11.50

Y de 3 CUs:

Captura de pantalla 2016-04-30 a las 11.11.50

Esto se ve mejor mirando la organización de la arquitectura GCN:

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-34-638

Es decir, la configuración con la memoria externa es la que va a afectar el número CUs y con ello el rendimiento gráfico de la potencial GPU de la consola, dado que hemos establecido que los mínimos son los juegos de Wii U a 1080P y lo deseable de 720P30 a 1080P60 si tomamos lo que dije en la anterior entrada:

Como no podemos tener shaders parciales esto redondeando serían unos 448 hilos de ejecución simultaneos, o lo que es lo mismo, unas 7 CUs de la arquitectura GCN ejecutando código por lo que si el mínimo sería colocar los juegos de Wii U de 720P a 1080P con un simple cambio de resolución entonces una GPU con 7 CUs es suficiente, si en cambio se busca ir a los 1080P60 desde los 720P30 entonces estaríamos hablando de 14 CUs, pero se ha de tener en cuenta que la GPU7/GX2 funciona a 550Mhz por lo que puede ser que el número de CUs sea inferior a esa cifra de 14 o simplemente con tal de ahorrar en consumo la velocidad de reloj sea inferior.

Una vez explicada la relación de la MEM2 con la GPU toca explicar la de la MEM1. En cuanto la relación CPU-MEM2 la explicare en otra entrada.

MEM1/eDRAM, relación con la CPU y la GPU.

Antes os he comentado como la presencia del DMAE y su uso para el traslado de datos de la MEM1 a la MEM2 y viceversa supone que el hecho de eliminar el esquema de memoria que tiene Wii U en el nuevo sistema supone re-escribir de nuevo el código del juego. Pero antes de ir a la MEM1 hay que tener en cuenta que la configuración de Wii U es la de un sistema con memoria no unificada y que pese a utilizar memoria embebida tiene ciertas diferencias con la memoria embebida de Xbox One en cuanto al acceso a esta, si miramos la litografía de Xbox One veremos como la ESRAM se encuentra al lado de la GPU pero muy alejada de la CPU:

Teardown-Xbox-One-processor-die-2

Mientras que en Wii U la eDRAM no solo esta al lado de la GPU sino que se encuentra directamente al lado de la interconexión GP I/O/(60Xe) que comunica con la CPU del sistema.

wiiudie_blocks

Esto tiene una explicación, la ESRAM de Xbox no esta pensada para que la CPU acceda a la misma:

Xbox-One-ESRAM

Mientras que en el caso de Wii U y el SDK nos los deja bastante claro, la CPU tiene acceso a dicha memoria:

Captura de pantalla 2016-04-30 a las 9.12.02

Lo que ocurre es que en el acceso por parte de la CPU es que no hay un sistema de coherencia con la memoria, esto es curioso y me llama poderosamente la atención porque es habitual que exista dicha coherencia en sistemas con cache compartida, claro esta que en el caso de la CPU de Wii U dicha cache L2 de la CPU realmente no es compartida sino que cada núcleo de la CPU tiene la suya propia:

espresso_annotated

espresso_intro

Es más, Nintendo en el SDK recomienda utilizar el mecanismo DMA de los núcleos del Espresso, los cuales se comunican con el DMAE del Latte para el acceso tanto a la MEM1 como a la MEM2.

Captura de pantalla 2016-04-30 a las 9.16.06

¿Pero como es que la CPU tiene acceso a la MEM1? El motivo de ello es simple, para ejecutar los juegos de Wii se necesita tener el esquema con dos pozos de memoria principal que esta tenia, los 24MB de memoria interna y los 64MB de memoria externa. En modo Wii la MEM1 hace el trabajo de la memoria interna para la CPU y la MEM2 (DDR3) la de la memoria externa. Pero una vez explicado el motivo por el cual la CPU se encuentra conectada a la eDRAM nos toca hablar de la GPU, en concreto de la relación de esta con la MEM1/eDRAM.

En realidad en lo que a la relación GPU-Memoria en Wii U tenemos una relación como en el PC donde la GPU tiene una memoria local para si misma y luego puede acceder a la memoria principal del sistema. El problema aquí es que la memoria local no tiene suficiente densidad como para almacenar las texturas, aunque se puede texturizar desde la misma… Aunque sobre ello en concreto ya entraré más adelante.

Captura de pantalla 2016-04-29 a las 16.58.27

Tenemos 8 canales distintos en vez de 2 en la MEM1, si miramos la litografía del Latte de Wii U podremos ver que esta dividida en 8 bancos iguales…

Captura de pantalla 2016-04-29 a las 17.11.33

… como este:

Captura de pantalla 2016-04-29 a las 17.12.36

El motivo de dicha división es porque la GPU soporta hasta 8 muestras de búfer de imagen, estas se pueden utilizar haciendo uso de Forward Rendering o del Deferred Rendering, en el primer caso la GPU pueda hacer uso del MSAA hasta 8x a nivel teórico pero no tiene suficiente memoria para ello incluso a 720P, el motivo de ello es que la formula para el MSAA es la siguiente:

Resolución*(Color+Profundidad)*Número de muestras.

Por lo que en MSAAx8 y a 720P la memoria ocupada sería:

1280*720*8*8= 56.25 MB

Nintendo recomiendo el uso del FXAA y también el renderizado por diferido donde también hay unas 8 muestras pero el búfer de profundidad no se vuelve redundante y solo tiene que ser utilizado en una de las 8 muestras para tener su acceso al mismo.

Captura de pantalla 2016-04-30 a las 9.33.25

No obstante el sistema en cuanto a densidad tiene sus problemas, unos 32MB se hacen limitados para un búfer de imagen de 1080P en 16:9, en dicho caso cada uno de los bancos de la eDRAM debería pasar de los 4MB de memoria a unos 9MB de memoria aumentando el total de memoria embebida de los 32MB a los 72MB. La memoria utilizada en Wii U es de 40nm de Renesas:

necele_08

La densidad es de 0.06 y la eDRAM disponible en el mercado que tiene más números de ser utilizada por Nintendo sería la de 28nm de TSMC, no tengo datos de eDRAM en procesos más avanzados y es por este motivo que ayer os puse esto:

Captura de pantalla 2016-04-30 a las 9.39.21

Ahora bien, la eDRAM no es la mismo que la eSRAM y la densidad de esta última es de 0.16um^2, esto es debido a que en densidad la eDRAM tiene una ventaja de 3:1 pero una gran cantidad de eDRAM también es contraproducente pero hemos de tener en cuenta que esto es diferente a la eDRAM de GameCube/Wii, aquí el desarrollador tiene acceso libre a la memoria embebida para gestionarla como quiera y es aquí donde se ve como el trabajo de la eDRAM no es el de almacenar los búfers de imagen sino que estos pueden estar en cualquier sitió, esto plantea dos problemas adicionales:

  • Los efectos de post-procesado.
  • Los efectos de los Pixel Shaders que dependen de los ROPS (como los mapas de sombras).

Para que los mapas de sombras sean eficientes necesitas que se encuentren en la misma memoria a la que se encuentran conectados los ROPS por lo que el mapa de sombras se encontrará dentro de la MEM1/eDRAM junto a no ser que se desplace alguna muestra fuera de la MEM1, este es el motivo por el cual los juegos de Wii U normalmente prescinden de los mapas de sombras. Y en cuanto a los efectos de post-procesado tiene que ver no solo con el espacio sino con el ancho de banda de la eDRAM, el cual en modo lectura+escritura no duplica el ancho de banda como la ESRAM de Xbox One al no tener un modo duplex sino que la divide en ambas direcciones. Aunque realmente la eDRAM tampoco es mala idea, el problema es la densidad de la eDRAM y perdonad si vuelvo a citar a sebbbi de nuevo pero es importante en el contexto en el que estoy hablando:

Una eDRAM de lectura/escritura practicamente anularia todos los costes de ancho de banda de la generación/sampleado del g-buffer y el rendering de post-procesado (es decir, efectos a pantalla completa que son consumidos en las etapas tardias del pipeline). Y sería genial para la computación desde la GPU.

Sin embargo no anularía el coste en ancho de banda de los shadow maps, a no ser que tengas una enorme cantidad de eDRAM. Un solo atlas de shadow maps toma unos 64MB, e incluso este no es suficiente si quieres renderizar por encima de los 720P con mapas de sombras/shadow maps de buena calidad.

Un mapa de sombras de 64MB no es suficiente para resoluciones encima de los 720P y dado que estos aumentan en potencias de 2 entonces el mapa de sombras ideal para 1080P es de 256MB por lo que el total de memoria embebida que necesitamos para no tener ningún handicap sería de 256MB+72MB, es decir… Un total de 328MB de memoria. Es por ello que es importante tener en cuenta que una de las ventajas del manejo manual de la eDRAM es que permite hacer cosas como ir desplazando de la eDRAM hacía la MEM2 aquello que ya esta resuelto y/o cuyos datos en ese momento no se necesitan para ser utilizados en ese mismo momento. Esto es otro de los elementos que Wii U tiene en común con Xbox One y es por ello que la cita de sebbbi del principio de la entrada es importante.

El DMAE hace la misma función que los Move Engines/Swizzle Copy que existen en Xbox One, exactamente la misma. Es más, al igual que ocurre en las Xbox (360 y One), Wii U soporta un mecanismo de Tiling… Pero este es descrito de la siguiente manera en el SDK de Wii U:

Captura de pantalla 2016-04-30 a las 10.05.10

Una superficie puede ser una textura o un búfer de imagen, la referencia es a la MEM2 donde tenemos 2 canales como hemos visto antes con 4 bancos cada uno, pero no tenemos acceso a 8 bancos en el caso de la MEM2 tal y como se ha visto antes… ¿El motivo? El hecho de poder colocar los otros 4 bancos en la MEM2 por el simple hecho de que Nintendo reconoce que hay shaders cuyo rendimiento al ejecutarse bajo la MEM2 es nefasto, lo dicen ellos mismos en el SDK:

Captura de pantalla 2016-04-30 a las 10.12.38

¿Se puede texturizar desde la MEM1? Es que aquí esta la trampa y mucha gente lo compara con el Virtual Texturing que se puede realizar en Xbox One cuando no lo mismo en absoluto. Si que se puede texturizar pero esto supone que los 4 de los 8 canales de la MEM1 se usen para lectura y no para escritura, afectando al ancho de banda. Pero es que lo mismo ocurre con los efectos de post-procesado así como para los mapas de sombras donde también se tienen que utilizar los canales para lectura. Es decir, el código de Wii U al igual que ocurre con el de Xbox One esta lleno de operaciones con la unidad DMA para ir desplazando los datos entre la MEM1 y la MEM2.

El siguiente elemento a tener en cuenta son los RB del sistema, tenemos unos 2 en total con 4 ROPS cada uno de ellos:

GPU7BlockDiagram

Los RB o Render Back-End son descritos de la siguiente manera en el SDK de Wii U/Cafe

Captura de pantalla 2016-04-29 a las 17.25.25

Pues bien, los RB han sido una de las piezas que desde el R700 no han evolucionado incluso en las GPUs más modernas de AMD y el ancho de banda por cada uno de ellos es 8 bytes por ciclo por que en RGBA8 pueden escribir color+profundidad en un solo ciclo por lo que por ROP el ancho de banda de la GPU es de:

550 Mhz* 8 bytes= 4.4 GB/seg.

Esto es menos que los 6.4 GB/seg por canal de la MEM2 pero si los juntamos todos:

4.4 GB/seg*8 ROPS = 35.2 GB/seg.

Dados los problemas existentes que he comentado unas pocas lineas más arriba lo ideal sería integrar en el siguiente sistema una memoria embebida con dos canales (DDR) por banco, si esto se hubiese hecho en Wii U entonces el ancho de banda de la eDRAM sería de 70.4 GB/seg y las operaciones de lectura no entrarían en conflicto con las de escritura pero esto significaría tocar el acceso a la MEM1 en NX, haciendo que uno de los bits inactivos pase a estar activo para elegir el segundo canal.

Además existe una relación entre la anchura en bits de la interfaz con la memoria embebida y el número de RBs y es un simil que se da también en Xbox One. La interfaz de la GPU7/GX2 con la MEM1 es de 512 bits para 2 RB, curiosamente si comparamos con Xbox One veremos que el ratio es el mismo ya que Xbox One tiene una interfaz de 1024 bits (256 bits x 4) para una GPU con 4 RB (16 ROPS).

XBox_One_SoC_diagram

Hay que tener en cuenta que no existe una relación directa entre el número de RBEs y el número de CUs, pero hay que tener en cuenta que no tener el suficiente ancho de banda supone un handicap para los ROPS al mismo tiempo que no tener la tasa de relleno teórica suficiente es un desperdicio del ancho de banda de la memoria a la que estén asignados. En Wii U tenemos unos 8 ROPS (2 RBs) y es posible que Nintendo repita dicha configuración en NX si esta lleva memoria embebida u opte por una de 16 ROPS (4 RBs) en todo caso el ancho de banda ideal pasa a ser:

Velocidad de reloj*Número de ROPS*16 bytes.

Dado que los búfers de imagen se procesan en la memoria embebida (MEM1), la MEM2 deja de tener importancia en el tema del ancho de banda con los ROPS. Desconozco la densidad que escogería Nintendo para NX en el caso de que esta utilice memoria embebida, en todo caso el mínimo sería una cifra de 32MB y el número de RBs sería de 2 con unos 8 ROPS. Tened en cuenta que estamos hablando de un escenario en el que el sistema hereda el esquema de memoria de Wii U y eso tiene unas consecuencias que he ido explicando en esta entrada. ¿La siguiente? El peliagudo tema de la CPU y el Café Core OS.

Anuncios