La entrada anterior era para explicar los motivos por lo cuales el SoC de Scorpio derivaría del de PS4 Pro con modificaciones, esta en una argumentación documentada desde el otro lado.

Una de las cosas que AMD ha incluido en Vega es el Infinite Fabric, en realidad es un mecanismo de comunicación entre procesador que funciona de manera muy similar al NVLink de Nvidia y permite la comunicación directa punto a punto entre dos procesadores distintos, esto es importante porque permite la conexión directa entre una CPU y una GPU en un mismo sistema sin que el puerto PCI Express actue y sin tener que hacer que ambos se encuentren en un mismo procesador.

Mirando en un artículo en semiaccurate sobre la tecnología me encuentro con lo siguiente:

Hablando de data fabric este será amplio, rápido y escalable. AMD afirma que los enlaces de baja latencia y las estructuras en común de alto rendimiento, incluyendo los protocolos CHT+ en ese lado, con enlaces multi-chip y multi-socket. Esto significa que funcionara también en MCM como Naples para conectar los cuatro chips en el enorme empaquetado.enorme empaquetado.

¿Que significa esto? Hasta ahora en los SoC/APU de AMD veíamos un bus llamado Fusion Compute Link apodado Onion, que era el que hacía el contacto entre la CPU y la GPU y entre la CPU y el espacio de memoria de esta que era considerado «coherente» porque el FCL se comunicaba con el Northbridge de la GPU que se encargaba de que hubiese una coherencia de la memoria. Pero esto solo ocurría a nivel de SoC/APU, en PC si querías comunicar la CPU con la GPU tenías que hacerlo utilizando el puerto PCI Express. Pero el truco aquí es que se menciona a «Naples» y precisamente es pura CPU pero Naples es enorme por el hecho de que son 4 Ryzen/Summit Ridge y hacer un chip de dicho tamaño sería enorme por lo que a AMD les sale mucho más barato separar el chip en cuatro unidades (4 Ryzen) y ponerlos encima de un MCM para comunicarlos entre si.

El siguiente diagrama es un Summit Ridge/Ryzen donde se puede ver un elemento llamado «Coherent Interconect» pues ese elemento es el Infinite Fabric:

500x1000px-ll-dca5e8da_5398d76da3e11a4e28c40eb99d198e8b_xl

Y es aquí donde llegamos a lo realmente interesante:

AMD afirma que Infinie Fabric esta en Vega, Summit Ridge y Raven Ridge, esencialmente todos los productos que hagán a partir de ahora sin contar revisiones de antiguas arquitecturas.

Es decir, podemos realizar un MCM con un GPU de arquitectura Vega existente en el mercado y una CPU de la familia Zen sin necesidad de desarrollar un SoC y teniendo ambos chips separados pero encima del mismo sustrato. En consolas ya hemos visto una configuración con CPU y GPU separados pero en modo MCM con Wii U donde debido a las diferentes técnicas de fabricación de CPU y GPU no se podían fabricar juntos los dos chips.

wii-u-logic-board-ibm-amd-mcm

 

Pero hay una ventaja adicional a la hora de separar los chips y no es otra que el hecho de que cada uno de ellos pueda alcanzar sus máximos de rendimiento. En un SoC nunca, pero absolutamente nunca sus componentes alcanzan el mismo rendimiento que en separado, es por ello que es preferible esto para que alcancen una mayor velocidad de reloj siempre y cuando el diseño industrial de la consola no lo impida (Wii U te estoy mirando a ti). Pero supongamos que exista una futura consola con esta configuración, no se si Xbox Scorpio la utilizará, pero tengo muy claro que «PS5» si e hice una especulación sobre la misma ya hice en su día.

En realidad no creo que Scorpio se base en una configuración de este tipo, más que nada por motivos de coste, pero por un momento vamos a suponer que es así y voy a contradecirme para que la gente sepa como sería un SoC de Xbox Scorpio… Bueno, un NoC porque una configuración así es llamada como Network on a Chip por AMD:

amd-infinity-fabric-data-on

Para empezar entramos en un problema muy gordo y es que tanto la CPU como la GPU tendrían sus accesos a la memoria diferenciados:

zen-die

Y luego nos encontramos que en consola el Southbridge por motivos de «seguridad» se encuenra siempre fuera del chip por lo que sería únicamente util serían los GMI que son los Infinite Fabric y por tanto pasaríamos de tener dos Northbridge (una coherente comunicado con la CPU y otro no-coherente) que sería de la propia GPU y por tanto distribuye los espacios de memoria de la siguiente manera:

NonFullHSA

A tener un solo Northbridge con una configuración que sería así:

FullHSA

¿Y cual es el problema? Cuando desarrollamos un juegos para Xbox One la GPU tiene dos espacios de memoria distintos aunque fisicamente sea uno solo. Es como tener dos barrios colindantes de una misma ciudad y una oficina de correos para ambas y después de una reforma se ha decidido utilizar una sola oficina de correos para toda la ciudad. ¿Y que significa esto? Pues basicamente que tiene que haber una coherencia de caches no solo entre los miembros de la CPU sino también con la Cache L2 de la GPU, en Wikipedia se explica muy bien el porque:

Cuando los clientes de un sistema, en particular las CPUs en un multiprocesador, mantienen cachés de una memoria compartida, los conflictos crecen. Haciendo referencia al dibujo, si el cliente de arriba tiene una copia de un bloque de memoria de una lectura previa y el cliente de abajo cambia ese bloque, el cliente de arriba podría estar trabajando con datos erróneos, sin tener conocimiento de ello. La coherencia de la caché intenta administrar estos conflictos y mantener consistencia entre las cachés y la memoria.

Es decir, Vega al contrario de Polaris tiene una coherencia de cache con la CPU lo que permite que su controlador de memoria pueda acceder a otras memorias del sistema que van más allá de la memoria de la gráfica, en el caso de una consola de videojuegos esto tiene menos sentido al haber menos niveles de memoria… ¿O si que lo tiene?

hbccvega

La NVRAM es lo que llamamos memoria no-volatil y cada vez vemos más discos duros SSD por lo que sería posible volcar datos directamente una memoria SSD muy cercana al MCM hacía los componentes del propio MCM y con una latencia y por tanto un ancho de banda menor, pero de eso ya hable en la entrada sobre la PS5 y es aquí donde tengo que dar un jarro de agua fria enorme a los que esperan Vega+Ryzen porque si Microsoft quiere mantener la compatibilidad hacía atrás no puede colocar el HBCC. ¿El motivo? Los Move Engines/DME/Swizzle Copy no sirven solo para mover los datos entre la ESRAM y la DDR3 sino entre la parte coherente y la no-coherente. En realidad tenemos cuatro unidades en Xbox One por este motivo en vez de dos, bueno, al menos de manera aparente y a simple vista.

Los Move Engines forman parte de la GPU, no son parte del sistema porque se encuentran en el Northbridge de la GPU (GPU MMU en el diagrama y como Swizzle Copy).

xbox-one-gpu-bus-overview

¿Como llevamos esto a Xbox Scorpio manteniendo una AMD Vega como GPU? Hay que tener en cuenta que sin los Move Engines sería posible también hacer movimientos de memoria de un punto a otro pero el código esta pensado para utilizarlos… ¿Como lo hacemos para mantenerlos y poder colocar una GPU AMD Vega en Scorpio? Es mucho más sencillo de lo que parece, dado que tanto la GPU como la CPU van a poder ver todo el espacio de memoria entero es igual si hemos trasladado datos de una parte de la memoria a otra con el Move Engine, no deja de estar accesible a ambos componentes por la coherencia.

Volviendo al simil de las oficinas de correos, si antes para llevar una carta del barrio A al barrio B teníamos que:

  1. Colocar la carta en el buzón.
  2. Que la oficina de nuestro barrio la cogiese y la enviase a la oficina de correos del otro barrio.
  3. Que la oficina de correos del otro barrio lo envie al remitente.

En el caso del sistema plenamente unificado tendríamos:

  1. Colocar la carta en el buzón.
  2. La oficina de correos general la envia al remitente.

¿Y en el caso que nos ocupa? Pues basicamente sería una mezcla de los dos, tendríamos por un lado las oficinas de barrio A y B funcionando de manera normal cuando se enviará una carta a través de las mismas y por otro el controlador general y es aquí donde entramos en uno de los elementos que se decían sobre Scorpio en el video reciente que hizo DF:

 

Optimizar para ESRAM es simplemente hace uso de los Move Engines/DMA/Swizzle Copy para pasar dato desde el espacio de memoria coherente al no-coherente, como en Xbox Scorpio si utiliza una AMD Vega como GPU todo el espacio de memoria estara plenamente unificado como coherente no importa donde se encuentre el dato y el uso de los Move Engines es para mantener la compatibilidad de los juegos de Xbox One con el nuevo hardware por lo que es más que posible que la GPU de Xbox Scorpio no sea una Polaris sino una AMD Vega pero el problema es que la AMD Polaris también permitiría una compatibilidad hacía atrás con Xbox One y su tecnología esta mucho más probada, es decir… Microsoft tanto con una AMD Polaris como una AMD Vega tiene que añadir los Move Engines y la diferencia clave estaría en la CPU soportada y aquí es donde me gustaría entrar a responder a un comentario en concreto que dice así:

Que no exista en el mercado no significa que MS no lo pueda tener. Ya pasó con la tecnologia de la GPU de Xbox360 y ya pasó con la CPU de One y PS4, ya q no existian con 8 Cores.

Además q pueden tener un prototipo de Ryzen tranquilamente. Te creerás q AMD no hace prototipos de sus proximas unidades xD
De verdad… curratelo un poco en tus argumentos.

Yo no digo q sea fijo RavenRidge. Solo digo q una posibilidad.
Menos opciones? si. pero tmb tiene opciones.

El Raven Ridge no es el SoC con la  configuración con 8 núcleos Zen sino 4+GPU de 12 CUs, pero como he citado antes utiliza el Infinite Fabric para comunicar ambas partes por el hecho de que para comunicar Zen y Vega desaparece por completo el Fusion Compute Link y aparece el Infinite Fabric. Dicho de otra manera, si la GPU es un AMD Vega en Xbox Scorpio entonces la CPU es Zen, si no lo es y la GPU es un AMD Polaris entonces entrará en la ecuación que la CPU sea Jaguar y aquí es cuando tenemos que utilizar la lógica.

raptor-dinosaur-in-suit

Si Xbox Scorpio se basa en tecnología ya existente… ¿Como es que no esta en el mercado todavía y Microsoft ha de tardar tanto en sacarla? ¿Acaso no es posible para Microsoft sacarla ya si su SoC es derivado de PS4 Pro como comente el otro día? En pleno aburrimiento sacando al perro me acorde de algo que escribí hace unos días comentando una limitación del AMD Polaris y porque este tiene solo unos 36 CUs y en el mercado no han salido configuraciones superiores.

En el caso del AMD Vega no sabemos cual sería la organización en lo que al número de HWS se refiere pero aquí entramos en uno de los cuellos de botella que tenía el AMD Fiji en los Fury y es que el planificador no era lo suficientemente rápido como para alimentar a todos los elementos al mismo tiempo. Hay que tener en cuentra que el planificador de cada CU podía almacenar unos 40 Wavefronts  en su lista que se solventaban en unos 40 ciclos de reloj por completo, es decir, el AMD Fiji podía tener en reserva dentro de las CUs hasta unos 40 Wavefronts a procesar por lo que en total habían unos 2560 Wavefronts.. ¿El problema? Cada uno de los ACE y el Procesador de Comandos Gráficos solo podia enviar un Wavefront por ciclo de reloj, y aunque cada CU tardaba unos 4 ciclos como mínimo en solventar un Wavefront y en ese tiempo el planificador podía enviar hasta unos 4 en realidad esto explica la configuración de 36 CUs que tiene PS4 Pro y la RX 480.

¿Como? Es sencillo, dado a que desde el planificador se pueden enviar un Wavefront por ciclo de reloj y tenemos 9 planificadores que pueden enviar 4 Wavefronts a diferentes CUs al tiempo en que una CU completa el primero entonces tenemos la capacidad de cubrir las 36 CUs en el caso del RX 480.

¿En que se traduce eso? Pues basicamente que el limite de Polaris (si la GPU se basa en el mismo) es ni más ni menos que los 36 CUs que es la misma cifra que tiene PS4 Pro y todo por el hecho que ese es el límite ideal del planificador de la GPU, se pueden colocar más CUs pero entonces el planificador no tiene suficiente rendim aquí entramos en un problema grande que echa por tierra lo que escribí el otro día. Es cierto que la GPU de PS4 Pro se basa en Polaris con ciertas modificaciones concretas (como el uso de NCUs en vez de CUs para poder hacer 2 operaciones en FP16 por ciclo) pero por el resto es practicamente igual (incluyendo los planificadores) y pese a que la RX480 puede alcanzar los 1266 Mhz de velocidad en PC.

amd-radeon-rx-480-gpuz

En PS4 Pro alcanza una velocidad de solo 911 Mhz por un motivo muy simple, se trata de un chip más grande al incluir más elementos en él y debido a esto puede alcanzar velocidades menores que en la versión solo GPU por lo que la hipotesis del overclock sobre el chip de PS4 Pro es cuanto menos… poco pausible. Es más, no los podemos separar porque no hay un «Infinite Fabric» como interfaz porque eso pertenece al Vega completo en conjunción con una CPU Zen y en el caso de que pudiese hacerse una subida de vueltas Sony lo hubiese hecho con su PS4 Pro tras saberse el anuncio de la Xbox Scorpio o… ¿Acaso lo podían hacer y la cantidad de chips buenos por oblea bajo tan drasticamente que decidieron no hacer el overclock? Lo que ha de quedar claro es que si la GPU es Vega entonces la CPU que lo acompaña es un Zen independientemente de si la configuración es un NoC en un MCM (CPU y GPU separados en el mismo sustrato) o se trata de un SoC al uso, dado que ambos utilizarán el Infinite Fabric para comunicarse.

Para continuar me gustaría responder el siguiente comentario:

Que no exista en el mercado no significa que MS no lo pueda tener. Ya pasó con la tecnologia de la GPU de Xbox360 y ya pasó con la CPU de One y PS4, ya q no existian con 8 Cores
Además q pueden tener un prototipo de Ryzen tranquilamente. Te creerás q AMD no hace prototipos de sus proximas unidades xD
De verdad… curratelo un poco en tus argumentos.

Yo no digo q sea fijo RavenRidge. Solo digo q una posibilidad.
Menos opciones? si. pero tmb tiene opciones.

Y este otro:

Sobre tus especulaciones de que lleve Jaguar no sé por donde irán los tiros al final, pero lo que tengo claro es que Scorpio será una consola clave para MS y su vision de llevar tu biblioteca de juegos contigo, compres los juegos en la consola XBOX que la compres.

Ya lo hizo con la virtualizacion de XBOX360 para ejecutar los juegos en ONE, y volverá a hacerlo para emular el codigo de ONE en Scorpio si hace falta.

Ten en cuenta que ese whitepapper es de la epoca de E3 2016. Medio año. Y ese white papper tmb lo ha seguido al pie de la letra PS4 PRO.

Los ultimos SDK no tienen nada q ver en lo de si lleva o no lleva Scorpio Ryzen o emulacion directa de One xD
La cosa es que aún queda mucha info por saber de la consola, y que hay 2 vertientes.

  • Economica y menos arriesgada. (aunque con 6TF y arquitectura de GPU más moderna
  • MAs hardcore, y más arriesgada para competir x precio. Está vendría con RavenRidge de 8 cores(16theads) hecha a medida. Y ya rondaría los + – 500€
  • AMD ya le shizo Jaguar a medida con 8 cores a Sony y MS. Antes solo existian de hasta 4

Pero de ahí a que en año y medio no le de tiempo a MS (que empezarian antes) a encontrar una solución a la forma de hacer más faciles los ports de PC a XBOX ONE/SCORPIO hay un trecho.

Mira lo que ha dicho uno de los de ORI, dejando claro que ese tema no es problematico para MS.

c28_kfwxcaa_1zf

No puede ser Raven Ridge por el hecho que este no cumple con las especificaciones de base, otra cosa es que pueda derivar de dicho SoC:

RavenRidge

Tenemos solo 4 núcleos de la CPU y con solo 12 CUs no creo que lleguemos a las especificaciones de Scorpio pero tanto la CPU como la GPU se pueden aumentar… ¿Pero que ocurre si ambas son demasiado grandes en conjunto? Por suerte tenemos el Infinite Fabric para separar ambos elementos, eso si, una consola así no sería precisamente barata por el hecho que los costes de la CPU+GPU subirían en comparación con tener un SoC y es aquí donde entra el dilema de todo esto, posible es posible, pero hemos de pensar si Xbox Scorpio es Xbox One Pro o si es un borrón y cuenta nueva.

En cuanto a la CPU, no hay modulos Jaguar de 8 núcleos, siguen siendo módulos de 4 núcleos de la misma manera que de la familia Zen también lo son, en el caso del Jaguar es porque la cache L2 que es compartida esta conectada a 4 núcleos, esto se puede ver en las litografías de los SoC de Xbox One y PS4:

XboxSoC ps4-reverse-engineered-apu

Con la familia Zen ocurre lo mismo y los núcleos se encuentran en grupos de 4 alrededor de la cache L3… Ahora bien… ¿Donde se encuentra el problema? El único problema lo he comentado, es en tema de costes, colocar un Zen con 8 núcleos más la GPU que tendría que tener sería un problema de costes que obligaría a separar los chips en un NoC… ¿Es imposible eso? No, no lo es pero como he comentado antes depende de como se plantee Microsoft su nueva máquina, si un borrón y cuenta nueva compatible hacía atrás con la consola o una versión mejorada de Xbox One.

Es más, con lo que se sabe de «Game Mode» de Windows 10 entra una posibilidad que ya comentare en otra entrada.

PD: ¿Cual creeis que será la configuración de Xbox Scorpio?