NX y Memoria Embebida (II)

Esto ya parece un foro, en fin…

y que pasa con wii u? es que no mueve lightmaps?

presupones que a nintendo le preocupa algo que “a full hd hay que usar mas resolucion de lightmaps, que si no las sombras se ven feas”…

…en serio… XD

¿En serio me confundes los mapas de sombras con los mapas de luces? Son dos cosas distintas. Los mapas de luces son ya pre-hechos y se usan a nivel de objeto para simular falsamente la iluminación de la escena cuando no hay generación de sombras por una fuente de luz dinámica o lo que es lo mismo… en movimiento. Los mapas de sombras se utilizan en los casos en que la fuentes de luz no tienen una posición fija por lo que las sombras si tienen que generar de nuevo y encima por cada fuente de luz que haya en la escena y en forma de un enorme mapa de sombras ya que lo que se hace es generar el mapa de sombras a partir del mapa de profundidad (Z-Buffer) y dicho mapa de sombras no cabe en ninguna memoria embebida dentro de chip actual.

El motivo por el cual hable en la primera entrada de los mapas de sombras es para hablar de una diferencia importante entre Xbox One y Wii U donde la memoria embebida no puede operar por limitaciones técnicas al menos la consola de Microsoft tiene la memoria externa con el suficiente ancho de banda, en el caso de Wii U esto no ocurre porque el bajo ancho de banda de la memoria externa de la consola resulta un enorme cuello de botella para este tipo de operaciones.

seguro que al final tiene 64 mb de edram, hay que sacar un par de buffers a la ddr3 y ademas ahi se procesan los lightmaps 4k.
supongo que algo mas de ancho de banda que wii u si tendrá, como para cargar con ese par de buffers “extra”.

¿Que es eso de algo más de ancho de banda? Existen dos relaciones en una GPU: La primera es la del ancho de banda de la memoria no embebida/número unidades de texturas, es una relación muy parecido a la de los ROPS pero a la inversa. La otra y actualmente más importante es que las TMUs suelen estar emparejadas con los Pixel/Fragment Shaders por lo que el número de TMUs esta directamente relacionado. La pregunta es… ¿Como es que en Wii U pese al ancho de banda de la memoria embebida no tenemos una mayor cantidad de unidades de texturas? La primera es por limitaciones físicas en cuanto al tamaño del chip, pero la segunda es que pese a que la consola puede texturizar desde la memoria embebida en un gran número de casos debido a la poca densidad de esta lo hará desde la DDR3 y es ahí donde el rendimiento de la misma bajaría en picado. Por lo que hay una relación directa entre el ancho de banda de la memoria no embebida y el número de unidades de texturas y estas con la cantidad de stream processors/shaders.

Lo normal es que a medida que sube la resolución de pantalla lo haga también el número de unidades de texturas en proporción. La media de la genéración 32/64 bits era 1 TMU para 240p, en la generación DVD la cosa paso a los 480p y 4 TMU de media, en la generación 720P pasamos de media a unas 16 TMU (Aunque PS3 tenga 24) y el salto a lo 1080P ha sido más discreto porque esta vez no hablamos de un salto de resolución 4X ya que la resolución es 2.25X realmente. Es por ello que Microsoft ha pasado de las 16 TMU a las 48 TMU (x3) y Sony de las 24 TMU a las 72 TMU (x3 también). En todo caso aumentar la resolución supone aumentar en la misma proporción el resto de elementos del sistema y si Wii U es una consola 720P entonces veremos a NX como consola 1080P y dado el precedente entonces veremos un salto 3X en cuanto a las TMUs, pasando de 16 TMUs a 48 TMUs.

Como punto curioso el ratio de Stream Processors/Shaders con las TMUs en la arquitectura R700 es de 10:1 y dado que lo más seguro es que utilice arquitectura GCN que tiene un ratio 16:1 entonces es posible que veamos una consola con una GPU con la misma potencia que la de Xbox One o similar.

lo que no se es si la ddr3 será 4 veces mas densa en 2016 y con el mismo numero de chips y ancho de banda similar que wii u ya cumple los 8 gb. en cualquier caso si es ddr4 porque a medio plazo vaya a ser mas barata que la ddr3, junto a su proceso de fabricacion menor, significa mas frecuencia en los chips con igual consumo. por ejemplo para conseguir 20 gbps con el mismo numero de chips. siendo 22 gbps el ancho de banda gddr3 de la old gen.

Lo que existe de cara a aumentar la densidad por “chip” pero sin aumentar el número de chips, y tampoco el ancho de banda, es la 3DS-DDR4.

3-130ZQJ035C8

captura-de-pantalla-2015-08-08-a-las-11-30-09

Es decir, en vez de tener cuatro chips en placa los apilamos todos y nos comunicamos con los mismos a través de un cableado TSV. Este tipo de chip no necesita ser montado sobre un sustrato/interposer compartido con el procesador principal por lo que puede trabajar tranquilamente como memoria externa. Eso si, hay que tener en cuenta los costes asociados de apilar cuatro chips de memoria utilizando este proceso, el cual es más complejo que cuatro chips de memoria por separado y por tanto más caro. Por otro lado el hecho de apilar unos cuatro chips no significa que la interfaz con el procesador se reduzca de tamaño tampoco y hay una relación muy importante entre las interfaces de memoria y el tamaño del chip. Es decir, todo esta interconectado de forma equilibrada y la decisión en un componente acaba por afectar al resto.

Mi apuesta por la HBM2 es simple de explicar… Elimina la necesidad de una memoria externa y todo lo que ello implica a nivel de diseño del chip, es simple y llanamente un…

keepitsimple

En el caso de que Nintendo con NX repita el mismo error que con Wii U en cuanto al ancho de banda de la memoria externa esta claro que para ciertas operaciones hará falta un tipo de memoria mucho más rápida. Me es igual si la memoria es embebida en el chip o en el empaquetado pero si se puede utilizar esa memoria como única y suprimir la externa sería mucho mejor. ¿El motivo? Dicha memoria externa sería a la que estaría conectado el Northbridge/Crossbar Switch de la CPU mientras que la interna sería a la que estaría conectada la GPU, la cual no necesitaría ser coherente con la de la CPU al utilizarse solo en el contexto gráfico.

export

Pero claro, necesitamos que la GPU sea capaz de acceder a su espacio en la memoria principal si la MEM1 no tiene suficiente densidad por lo que el escenario de repente cambia y el diagrama del sistema se complica un poco.

b

Ahora bien, tengamos en cuenta que el hecho de que la memoria tiene que ser coherente entre CPU y GPU es porque la GPU en modo  computación de propósito general necesita acceder al espacio de memoria de la CPU, esto es algo que no existía en consolas previas de Nintendo por lo que los buses de la CPU y la GPU con la memoria no eran coherentes entre si. No solo eso sino que la CPU podía acceder a la MEM1 y su espacio en la MEM1 es llamado Memoria Interna en los diagramas.

wiiudiagram-e1404123816731

Es decir, en Wii U el diagrama simplificado sería el siguiente:

c

Pero el añadido del Compute Shader cambia por completo las reglas del juego y se han de tener en cuenta esas nuevas reglas. Es decir, si queremos mantener el acceso de la CPU a la memoria embebida en las nuevas reglas de juego entonces tendríamos que tener la siguiente configuración… ¿cierto?

d

Pero hay un problema, el dispositivo encargado de la coherencia es el Northbridge por lo que de repente nos encontramos con el siguiente diagrama que es en realidad una imposibilidad.

export-2

Es decir… la MEM1 no puede estar conectada a dos interfaces distintas…. es una imposibilidad física y no se puede realizar. ¿La única solución? Tenemos dos, la primera es dejar que la MEM1 sea solo para gráficos y que pase a ser no-coherente por l hecho que no este conectada al Northbridge del sistema sino al propio de la GPU… ¿Se ha probado esto antes? Pues si, con Xbox One.

XBox_One_SoC_diagram

Si os fijaís la memoria embebida no se accede a través del Northbridge por lo que no hay mecanismo de coherencia con la ESRAM en dicho sistema. Por lo que por el momento vamos a suponer que la memoria embebida no es coherente y por tanto es solo para gráficos y aquí es donde entramos en dos escenarios distintos.

Memoria en chip…

46_110228092208_1

 

En dicho escenario el diagrama del sistema sería el siguiente:


e

Pero esta configuración tiene problemas asociados, en primer lugar no soluciona la dependencia con la memoria externa de cara al texturizado por lo que es una solución incompleta en el caso de Nintendo, recordemos que ellos suelen realizar sistemas donde el diseño de la placa base es bastante simple en cuanto al número de chips. Los problemas asociados con Wii U ya los conocemos y al contrario de lo que ocurría cuando se realizo Wii U ahora si que son posibles otros escenarios aparte de la memoria embebida, se que soy pesado con esto y puede que me equivoque pero soy de los que piensa que la memoria embebida no es una solución a estas alturas.

La otra posibilidad sería la memoria en el empaquetado pero dejando por el momento la memoria externa, con memoria en el empaquetado me refiero a cosas soluciones similares a las siguientes:

En el segundo caso la densidad de dicha memoria puede ser mucho más grande por lo que acaba apareciendo la posibilidad de poder almacenar toda la información relacionada con los gráficos incluidas las texturas, es decir, la no-coherente con la CPU por lo que nos encontraríamos con el siguiente esquema en este caso:

f

Pero esta solución tiene un problema, tiene un exceso de interfaces de memoria en el sistema y una sobre-complicación en el uncore debido a esto. Es más, el hecho de unificar la memoria elimina costes innecesarios. ¿Pero cual? Teniendo en cuenta la dependencia del ancho de banda de la GPU esta claro que la memoria externa sería la que acabaría siendo eliminada por completo de la ecuación haciendo que el sistema final quedará de la siguiente manera:

g

El resultado sería una placa base para el sistema la mar de limpia en cuanto a la cantidad de componentes y de consumo menor que la solución de tener dos pozos de memoria separados. También los costes en consecuencia serían mucho más bajos en este sistema al eliminar la DDRn de la ecuación.

Esto es todo, perdón por el retraso en responder la entrada, pero mis ideas de como debería ser el sistema están muy claras, otra cosa es que al final sea así.

Anuncios