En esta entrada voy a limpiar el exceso de informacion de lo propuesto en las anteriores de esta misma serie. ¿El motivo? Pues por el hecho que toda especulación sobre el futuro no deja de ser una propuesta y como tal necesita una réplica, una antipropuesta del original con tal de llegar a un concepto mucho más ordenado y limpio, esta no es una entrada con una linea de continuidad de las demás solamente, sino que va más allá de eso, es un ejercició de reflexión sobre lo anteriomente escrito.

the-thinker-auguste-rodin-png-A95vde-clipart

Dicho esto, lo mejor es empezar a realizar la entrada.

En el Hot Chips AMD ha estado hablando de las ventajas de separar un SoC en varios chips distintos encima de un MCM, que es lo que es el AMD Epyc.

AMD-EPYC-Four-Die-with-Infinity-Fabric

Respecto a crear un solo chip monolitico.

MCMAMDMonolithic.png

Cada uno de los chips encima del sustratoes un AMD Ryzen que se comunica externamente con el resto de chips que forman el Epyc a través de la interfaz Infinity Fabric.

IFabric.PNG

Por lo visto el Infinity Fabric funciona a la velocidad de reloj de la memoria del sistema, en el caso del Epyc tenemos memoria DDR4-2667.

amd-epyc-server-platform-techday-presentation-deck_Page_71

¿La cantidad de bits por ciclo de reloj?

DataFabricisInfinityFabric

La memoria DDR4-2667 funciona a unos 1333 Mhz, si tenemos unos 256 bits entonces esto se va a los 42GB/s aproximadamente que es lo que aparece en la diapositiva. El Infinity Fabric es lo que permite la coherencia entre los diferentes núcleos de cara al acceso a la memoria.No sirve para acceder a la memoria principal del sistema porque eso lo hace el controlador de memoria sino para que la coherencia de las caches se mantenga entre los diferentes núcleos.

¿Pero podemos colocar una GPU donde se encuentran los otros núcleos y sustituirlos? Y tanto que podría, no hay nada que se lo impida. El Infinity Fabric sería por donde se realizaría la comunicación CPU-GPU y haría el trabajo de la interfaz Onion que es lo que le permite a la GPU tener acceso a la parte coherente de la memoria husmeando para ello las caches de nivel más alto de la CPU. Obviamente bajo el sistema que estamos describiendo se mantendría por completo el esquema de memoria coherente y no-coherente que existe en las consolas actuales (PS4, Xbox One y derivados) por el hecho que la GPU en si misma carece de un mecanismo con el que acceder a todo el ancho de banda de la memoria principal al mismo tiempo que todo el espacio de memoria.

NonFullHSA

¿Cual es la pieza que falta para hacer el acceso completamente coherente hasta para la GPU? Pues el llamado HBCC que ya integra el AMD Vega, la propia AMD es muy clara acerca de los dos posibles caminos de datos que tenemos en Vega, uno sin la utilización del HBCC sino con un controlador de memoria convencional.

VegaAlternative

Fijaos como no puede acceder a la memoria del sistema y solo a su memoria local.

hbccvega

Y este es el camino a través del HBCC, fijaos como en realidad el HBCC se situa en el lugar del controlador de memoria dado que es una versión más compleja del mismo. controlador de memoria el HBCC, pero en el caso que nos ocupa esta relacionado con la memoria HBM… La cual es utilizada como una especie de Cache L3 de la GPU, pero en especial fijaos como da el acceso a toda la memoria del sistema y en todos los niveles de la misma e incluso a la RAM no volatil (NAND Flash)

Esto significa que el HBCC permite la coherencia completa de la GPU con la memoria del sistema.

FullHSA

Pero en este punto llegamos a una pregunta clave que es a lo que ha llevad este contrabriefing ¿Es viable en una consola de videojuegos el HBCC y tener dos niveles de memoria? Se que he estado hablando de esta posibilidad en todas estas entradas pero… ¿Es economicamente viable realizar una configuración de ese tipo para una consola de videojuegos que se va a vender al mercado de consumo? La otra idea es utilizar un solo pozo de memoria GDDR6 en el sistema y mantener el esquema de memoria de la actual generación, lo cual es mucho más barato en cuanto a costes.

Es en este punto donde aparecen dos escenarios distintos de nuestra potencial consola.

#1 Esquema A

El Esquema A es el que he estado hablando todas estas entradas hasta ahora.

ConfigAComplete.crsdim.png

Lo primero que os llamara la atención es la CPU… ¿Cual es su naturaleza? Es un AMD Ryzen conservando la misma naturaleza que en PC con todos sus componentes y interconexiones y que ha vista de placa base con el resto de componentes se vería más o menos de la siguiente manera:

ConfigABoard.png

La GPU renderiza en la memoria HBM2 (Bt, Bc y Bz) y es el HBCC el que va trasladando los datos de un pozo de memoria a otro a medida que son necesarios para el renderizado, en este caso la CPU no tiene acceso a la memoria HBM. ¿Pero cual sería la memoria HBM utilizada? Una que por el momento no existe que es la HBM para el mercado de consumo.

lowcosthbm

No sabemos cual es el coste de esta memoria, lo que sabemos es que la memoria HBM2 es sumamente cara para una consola de videojuegos. La memoria HBM2 no puede alcanzar los 768GB/s que si que podría alcanzar la memoria HBMc y necesitaría para ello una tercera pila. El coste de dicha memoria es:

  • $25 para el sustrato/interposer
  • $75 por cada pila

Es decir, necesitaríamos unos $225 del coste de la consola con tal de pagar esta configuración si utilizaramos la actual HBM2 para realizar un sistema. La HBM de consumo es más barata por un motivo, reduce el ancho de banda por pila de los 1024 bits a los 512 bits. ¿Las consecuencias de ello? La cantidad máxima de chips por pila se reduce, pasando de como máximo a 4, por lo que solamente serían posible configuraciones 4-Hi y 2-Hi.

La configuracion 4-Hi la descartamos de inició. ¿El motivo? La actual configuración de la HBM2 es 4-Hi por lo que los costes realmente no serían muy diferentes, por lo que nos quedaría una configuración 2-Hi. El ratio de error en la fabricación es algo menor por lo que vamos a suponer unos $35 de coste por pila, lo que significan unos $165 para el sustrato/interposer y la memoria HBM y eso que aún no hemos contado la memoria DDR4, la cual tampoco debería subir mucho el coste del sistema, a no más allá de los $190 para la memoria del sistema, lo cual no es muy halagador para este escenario.

#2 Esquema B

En el esquema B hacemos desaparecer por completo la memoria HBM y lo reducimos todo a un solo nivel de memoria con la GDDR6, con ello hacemos desaparecer también el sustrato/interposer parae ese tipo de memoria.

Al empezar a escribir el esquema B he planteado el sistema de dos maneras, uno con bu de 384 bits, para igualar los 768GB/s del que hable en las entradas anteriores y por tanto con 12 chips de memoria. El otro planteamiento es con 16 chips de memoria (las hemos visto en la generación actual) y esto nos permitiría llegar a 1TB/s de ancho de banda.  ¿Es posible dicha configuracion? Sería posible, pero los calculos que he realizado es con memoria GDDR6 a 16Gbps y un bus de 384 bits, para llegar a los 768 GB/s, que por otra parte sería el máximo que se podría alcanzar con la HBM de consumo, dicha configuración tendría un ancho de banda teórico mucho más alto que el ancho de banda teórico de la memoria HBM de consumo. ¿El coste?  Si tenemos en cuenta que un chip GDDR5 ahora cuesta unos $6.5 entonces realizar el calculo para los 16 chips es sencillo, unos $104 en total y recordad que no hace falta el interposer.

¿De que densidad?

4_32

Parece que en un futuro veremos chips de 32Gb/4GB por lo que estaríamos hablando de una configuración de 64GB de memoria en total, la memoria GDDR6 soporta modo Clamshell, pero esto duplicaría la cantidad de chips y nos pondria los costes a $208… ¿Lo mejor? Nos conformamos con unos 64GB de memoria RAM para el sistema, que es más que suficiente para ello.

Pero para que veáis la metodología de elección he decidido colocar en una tabla las diferentes configuraciones posibles y como afectan al rendimiento de la GPU teniendo en cuenta además la propuesta del esquema A.

Conf Speed  Bandwidth (GB/s) Fillrate/s Tri. Rast/s GPU (Mhz)
384 Bits  12 Gbps 576 72 4,5 750,00
384 Bits  14 Gbps 672 84 5,25 875,00
384 Bits  16 Gbps 768 96 6 1000,00
512 Bits  12 Gbps 768 96 6 1000,00
512 Bits  14 Gbps 896 112 7 1166,67
512 Bits  16 Gbps 1024 128 8 1333,33
2048 bits HBM 768 96 6 1000,00

Estoy muy seguro que vamos a ver la velocidad de reloj de la GPU por encima de la de Xbox One X, los 1330 Mhz del punto más alto de la tabla es la que pienso yo que sería la configuración más interesante para nuestro sistema, cuyo diagrama sería el siguiente:

ConfigBComplete.crsdim.png

Su presentacion en la placa base de la consola sería más tradicional y del esquema de las consolas actuales.

ConfigBBoard

 

Comparando Esquemas

Os dejo la tabla resumida de las dos propuestas.

 

 

Esquema A Esquema B
CPU Ryzen 2 Ryzen 2
Núcleos CPU 8 8
HBM SI NO
Densidad HBM 8GB
Ancho de Banda HBM 768GB/s
Tipo de RAM DDR4 GDDR6
Ancho de Banda RAM 51.2GB/s 1024GB/s
Densidad RAM 64GB 64GB
Velocidad GPU 1000 Mhz 1333,3 Mhz
Numero CUs GPU 72 72
FLOPS (FP32) 9.22 TFLOPS 12.29 TFLOPS
FLOPS (FP16) 18.43 TFLOPS 24.58 TFLOPS
Tasa de Texturizado 288 GTexeles 384 GTexeles
ROPS 96 96
Tasa de Relleno 96 Gpixeles 128 GPixeles

Como véis la opción B gana por el momento, por lo que volcamos la mesa y eliminamos el Esquema A de la propuesta, dado que obtenemos un mayor rendimiento por un coste menor.

tableflip02

¿Terminamos con esto la serie? No, aún queda un detalle adicional que comentar, es un muy leve.

El Esquema A tiene sentido además si vamos a utilizar memoria NAND Flash en el sistema, es decir, un Disco Duro SSD. Pero el coste de estos es prohibitivo para una consola por lo que pienso que vamos a continuar viendo los clásicos Discos Duros de toda la vida incluso en la siguiente generación. Obviamente podremos colocar un SSD si queremos pero dudo que la consola base venga con un disco duro SSD.

¿El punto controvertido entre Sony y Microsoft?

archival-disk-logo-criticsight-500x279

Pero eso en otra entrada si os parece, para esta ya hay suficiente.