Por lo visto un nuevo SoC/APU de AMD de carácter desconocido ha aparecido en las bases de datos de los benchmarks-

El código del chip es muy parecido al que vimos de Gonzalo/Ariel recientemente pero con algunas «sutiles» diferencias.

Empezando de derecha a izquierda, podemos leer 18_13F9 en vez de 18_13F8. Komachi en su cuenta de twitter nos dice que los dispositivos marcados en el rango 13E0 a 13FF en el PCI-ID pertenecen a los dispositivos marcados como Ariel.

Y en efecto así es… Solo que en la base de datos del PCI ID hay dispositivos no especificados.

Por lo que estaríamos hablando de una versión con una GPU con la misma arquitectura pero otra posible configuración. En cuanto al 18 en el 18_13F9 no marca la velocidad de reloj de la GPU.

El siguiente punto es peliagudo, ese /12/ en el /12/_13F9 hay gente que afirma que se refiere a que la velocidad base de la GPU son lo 1.2 Ghz pero otra gente con la que estoy de acuerdo es que la GPU en vez de basare en «Navi 10» se basa en «Navi 12». ¿Y que es Navi 12? Pues aquí tenemos que entrar en el reino de la especulación.

Hace poco y lo comente hace unas entrada, hablando sobre las posibles configuraciones de la familia RDNA, comente sobre las especificaciones de la llamada «Navi 14» que va a tener un bus de 128 bits GDDR6 con 12 WGP/24 CUs. Esta GPU tiene la particularidad que rompería el «limite» de Navi 10 de solo 5 WGP/10 WGP por cluster. Pues bien Navi 12 al estar en medio vendría a tener un bus de 192 bits GDDR6 para si, pero siendo posible una configuración de 6 WGP/12 CUs por cluster entonces lo que tendríamos sería una posible configuración de 18 WGP/36 CUs en el caso de la /12/18_13F9 de la AMD Flute. Se ha de aclarar que no sería una «Navi 12» al uso sino una con soporte Raytracing por hardware.

Si nos movemos a la izquierda nos encontramos con que el código evoluciona a 15_32/12/18_13F9, pero la parte 15_32 no hace referencia a la GPU sino a la CPU, el propio benchmark nos deja claro que estamos hablando de una CPU con una velocidad base de 1.6 Ghz, algo que es extraño para ordenador por ser demasiado baja pero con una velocidad boost de 3.2 Ghz.

En realidad diría que la CPU esta pensada para colocarse a 3.2 Ghz únicamente en ciertas situaciones como es la reproducción de videojuegos de la siguiente generacíón, pero en cosas como la navegación de menús, el visualizado de películas y otra funciones de mucha menor carga de trabajo la CPU se coloca a si misma a 1.6 Ghz.

Tened en cuenta que los tres fabricantes se han auto-impuesto niveles de consumo según el tipo de aplicación que se ejecute en sus consolas.

El problema real no se ve en el código, aunque el 15 que viene antes podría tener relación.

Llama poderosamente la atención es la sustitución del 16 por un 15 respecto a Ariel Gonzalo dado que este cambio en el código podría tener relación con un cambio en la cache L3 del sistema, la cual habría sido recortada respecto a un CCX estándar de los Ryzen 3000 que tiene un total de 32MB de cache L3. ¿A cuanto? El siguiente gráfico en el benchmark nos da una pista importante.

Para entender la latencia de la memoria, se ha de tener en cuenta que mientras el bloque de un programa quepa integro en las caches lo que hará la CPU será integrarla en la cache más cercana a los registros, si no cabe en la cache de un nivel entonces los datos son enviados a la cache superior hasta a llegar a la memoria RAM.

Lo que nos indican los resultados es que la cantidad de Cache L3 por CCX en este caso se ha reducido a un 25%, de 16MB a 4MB. ¿El motivo de ello? Lo más seguro es que querer ahorrar espacio en la retícula del chip y que esta sea un poco más pequeño con tal de aumentar la cantidad de chips buenos por oblea. Este cambio significa que el rendimiento va a ser un poco peor que con un Zen 2 estándar en cuanto a rendimiento.

Lo que no toca a continuación es salir de lo que es el chip en si mismo y mirar a la memoria, unos 16GB nos indican un bus de 256 bits con lo chips en modo clamshell, con dos chips por controlador de memoria GDDR6.

Cuando los chips de 2GB GDDR6 estén disponibles en masa entonces quien monte el sistema podrá reducir la cantidad de chips disponibles en placa a unos 8 en total reduciendo costes o en su defecto aumentar la RAM hasta los 32GB de memoria.

Juntando esto con lo que Gonzalo/Ariel tiene una Navi 10 dentro y un bus de 320 bits (256 bits+64 bits) creo que en el caso que nos ocupa y teniendo en cuenta que hablamos de 256 bits entonces estaríamos hablando de 192 bits+64 bits. Aplicando la mismas reglas del otro día y suponiendo también una GDDR6 a 14 Gbps…

GbpsmemclkTotalCPUSSD+SBGPU
141.754485612380
13.91.7375444.855.612377.2
13.81.725441.655.212374.4
13.71.7125438.454.812371.6
13.61.7435.254.412368.8
13.51.68754325412366
13.41.675428.853.612363.2
13.31.6625425.653.212360.4
13.21.65422.452.812357.6
13.11.6375419.252.412354.8
131.6254165212352
12.91.6125412.851.612349.2
12.81.6409.651.212346.4

La diferencia es que el sistema que nos ocupa al contrario de la simulación no tiene memoria DDR4, pero ya os comente que cuando comente la posible configuración esta tenía que tener el ancho de banda de la DDR4 en la GDDR6 aparte del de la GPU. Obviamente no tenemos el ancho de banda de «Navi 12» en PC como referencia.

Pero la RAM nos indica de cual de los dos fabricantes estamos hablando porque en el video del teaser de Xbox Scarlett se intuía una configuración de 320 bits o de 384 bits. Personalmente pienso que Xbox Scarlett tiene una configuración de 320 bits GDDR6 y el AMD Flute no tiene esa configuración por lo que estaríamos hablando del SoC de PS5 en este caso, el cual sería un poco menos potente que el de Xbox Scarlett.

Es decir, AMD Flute es el SoC de PS5…

Volviendo al chip y tirando completamente hacía la izquierda nos encontramos con un número muy largo, pues bien, parece ser que es la muestra de calificación y esta lista para ser producida en masa.

Esto es interesante porque esto significa que hablamos de un chip final que esta preparado para ser enviado en masa para que Sony construya los kits de desarrollo de PS5, pero esto no es un kit de desarrollo sino un PC montado deprisa y corriendo por AMD para testear el SoC al completo, lo digo porque habrá gente que dirá… Bueno Urian, han probado el sistema con un HDD al uso y no un SSD en el benchmark… Y es cierto.

Los chips que tienen un Ryzen, precisamente en el IO Hub, que es la parte relacionada con la E/S aparte de tener un conjunto de controladores USB tiene un controlador PCI-Express en el que normalmente:

  • 4 Lineas van al Chipset/Southbridge del sistema.
  • 4 Lineas van a una interfaz SATA o para un Disco Duro SSD a través de una interfaz PCI-Express.
  • El resto de lineas se deja para una GPU externa y/o se desactivan. En consolas lo más seguro es que acaben desactivadas al no tener utilidad aparente.
  • Esto es aplicable tanto a los sistemas basados en Zen 1 como en Zen 2.

Ariel/Gonzalo vs Flute

Tened en cuenta que estos datos son especulatorios pero a no ser que hayan cambios por el momento, la cosa quedaría así.

SoCAMD FluteAMD Gonzalo/Ariel
CPUZen 2Zen 2
Ghz1.6/3.21.6/3.2
Núcleos 88
Hilos1616
Cache L164KB+32KB64KB+32KB
Cache L2512KB512KB
Cache L38 MB32 MB
GPURDNA «Custom»RDNA «Custom»
Ghz1.81.8
«Clusters»34
WGP1820
CU3640
FP32 TFLOPS8.39.2
TMUs144160
T. Fillrate259.2 GTexels/s288 GTexels/s
ROPS4864
P. Fillrate86.4115.2
Tipo de RAMGDDR6GDDR6
Bus256 bits¿320 bits?
Ancho de Banda409.6 GB/s512 GB/s

Por cierto, no me hagáis la burrada de comparar los FLOPS con los de la actual generación, el motivo de ello ya lo explique aquí en una entrada reciente.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.