Blog Personal.

AMD, Futuro, Radeon, Uncategorized

RDNA Mobile: Situación Real

Hace poco ha aparecido la siguiente diapositiva:

En realidad es completamente falsa pero de paso podemos aprovechar para hacer un viaje acerca de lo que va a ser el SoC de AMD para smartphones en colaboración con Samsung.

El Cancelado AMD K12

El AMD K12 fue el nombre de una cancelada CPU de AMD basada en el conjunto de registros e instrucciones ARMv8 que fue cancelado hace unos años.

La idea con el K12 por parte de AMD no era ir al mercado de los smartphones sino al de los servidores basados en ARM,

al final la actual consejara delegada de AMD, Lisa Su, decidió cargarse el proyecto por canibalizar recursos e ir en contra de lo que acabo siendo en el mercado los procesadores de las gamas Epyc y Threadripper basados en la arquitectura Zen (x86-64) por lo que la aventura de AMD con el conjunto de registros e instrucciones ARM nunca llego a materializarse.

Durante el desarrollo conjunto crearon una plataforma llamada Skybridge, en realidad era un Northbridge/Data Fabric al que se le podían conectar tanto CPUs de la gama x86-64 como el K12, para ello crearon un conector universal dentro del propio SoC. Pues bien, pese a la cancelación del K12 y que Skybridge desapareció de los mapas de ruta como nombre no desapareció por completo en cuanto a desarrollo y es el actual Uncore/Northbridge/(Scalable) Data Fabric de la gama Zen en todas sus variantes y el conector universal es el Infinity Fabric, el cual le permite a AMD realizar SoCs a medida más fácilmente y diferentes configuraciones de los procesadores, solo necesitan que estos tengan una interfaz IF con la que comunicarse con el Uncore/Northbridge/(Scalable) Data Fabric.

Es decir, AMD dividió el desarrollo de los dos chips en tres equipos antes de la cancelación. Uno de ellos trabajaría en el Uncore/Northbridge/(Scalable) Data Fabric de los chips y los otros dos en las dos familias de CPU. La idea de AMD era hacer que en ambos diseños por aquel tiempo en desarrollo, tanto Zen como K12 compartiesen el mismo Uncore/Northbridge/(Scalable) Data Fabric por lo que el K12 no tenia que ser más que un núcleo ARMv8 con una interfaz Infinity Fabri entre la cache de último nivel y el Uncore/Northbridge/(Scalable) Data Fabric

Dado que económicamente y en personal los recursos de AMD eran limitados se tomo la decisión de cancelar el K12 para darle preferencia a los que acabaron siendo los núcleos Zen, decisión que a día de hoy se ha demostrado acertada.

El retorno del K12

El año pasado, sorprendentemente apareció la siguiente nota de prensa hablando de la joint venture entre Samsung y AMD:

Los términos clave de la asociación incluyen:

  • AMD otorgará una licencia de IP de gráficos personalizados basada en la arquitectura de gráficos RDNA altamente escalable recientemente anunciada a Samsung para su uso en dispositivos móviles, incluidos teléfonos inteligentes y otros productos que complementan las ofertas de productos de AMD.
  • Samsung pagará las tarifas y regalías de la licencia de tecnología AMD.

En realidad esto no es más que el mismo tipo de acuerdo semi-custom que tiene AMD con los fabricantes de consolas. Ahora bien, la pregunta es… ¿Como conectamos RDNA a un SoC basado en ARM? El problema que tenemos es el uso del Infinity Fabric como interfaz de conexión y si, ya se que en las tarjetas dedicadas de PC se sigue utilizando el PCI Express, pero lo que hay es un puente IF-PCI Express. Como he comentado antes el IF es el conector universal y propietario de AMD y esta esta completamente relacionado con el Uncore/Northbridge/(Scalable) Data Fabric de AMD para la gama Zen.

Por lo que la forma más fácil de entenderlo es que el SoC que están realizando para Samsung sea un SoC de muy bajo consumo para PC pero con los núcleos Zen cambiados por núcleos ARM, no obstante el cambio en el conjunto de registros e instrucciones de x86-64 a ARM supone cambiar el direccionamiento y con ello las unidades MMU del sistema.

  • La MMU x86/64 por la MMU ARM.
  • La GPUMMU se mantendría igual.
  • La IOMMU x86/64 por la IOMMU ARM (SMMU).

Precisamente en en la entrada Master Class sobre direccionamiento y acceso a memoria os comente como funciona el direccionamiento en los x86-64 y tenéis que tener en cuenta que un cambio de una CPU con un conjunto de registros e instrucciones por otro supone un cambio en el direccionamiento común de la CPU a través de la IOMMU de la gama Zen, el cual esta pensado para operar on el direccionamiento de memoria de los x86-64 por lo que AMD si quiere casar sus RDNA con ARM necesita utilizar el IOMMU de los ARM, el cual es llamado SMMU en la literatura de los ARM y adaptar el mecanismo de coherencia en el direccionamiento de memoria con el de ARM.

Tened en cuenta que cada conjunto de registros e instrucciones tiene su propio direccionamiento virtual de tal manera que los bits de una dirección virtual para x86-64 va a ser diferente en ARM por lo que lo que se tiene que tener en cuenta es que el direccionamiento entre ambos no es compatible y que Android esta diseñado alrededor del direccionamiento del los procesadores con conjunto de registros e instrucciones ARM por lo que la conclusión es que RDNA Mobile carecerá de todos esos elementos a nivel de GPU que permiten la coherencia de memoria con x86-64 que tiene la versión de escritorio y habrán sido reemplazados por aquellos que dan coherencia de memoria con ARM.

Esto significa además que la ATC (Address) Translation Cache que traducía el direccionamiento de a GPUMMU a un direccionamiento compatible con el direccionamiento virtual de las x86-64 habrá desaparecido por completo ha sido reemplazado por una ATC para compatible con ARM en el proceso con tal de dar coherencia total. En todo caso AMD tiene que hacer este cambio si quiere que la GPU pueda acceder a los Ring Buffers con lineas de comandos que escribe la CPU para la GPU en el espacio de memoria de la CPU.

Por otro lado, la IOMMU en los núcleos x86-64esta dentro del IO Hub en el caso de los SoC de AMD por lo que se reeplazaría el IO Hub por completo de la ecuación por lo que las interfaces de E/S serian completamente distintas y más adecuadad para el bajo consumo respecto a las disponibles en PC pese a compartir el mismo Uncore/Northbridge/(Scalable) Data Fabric.

El medio japones Expreview comento no hace mucho que Van Gogh, uno de los SoC en desarrollo por parte de AMD bajo x86-64 tiene un consumo de solo 9W (más bajo que el de Renoir en su versión de 15W) y utiliza Zen 2 (x86-64)+RDNA. Lo importante aquí es el consumo y el hecho de que utilice RDNA y creo que el SoC que AMD esta realizando para Samsung deriva del SoC Van Gogh o más bien, es el SoC Van Gogh con un trasplante de cabeza (x86-64 x ARM) pero dejando el resto del SoC casi completamente igual y sin más cambios que los que he especificado arriba aparte de una interfaz que permite conectar los núcleos ARM al Uncore/Northbridge/(Scalable) Data Fabric ¿El mercado objetivo para el chip? En realidad son dos chips, el primero de los cuales esta pensado para:

  • Tablets.
  • Chromebooks.
  • Unidades HMD (Realidad Virtual).
  • Portátiles ultraligeros basados en ARM.

No es un chip para smartphones debido a que su consumo objetivo estaría un poco por encima, para ello existirá una versión menor pensada para smartphones los planes no son esos con el primer chip que se estaría realizando aunque este tendría un hermano menor para smartphones con una configuración menor pero ninguna tiene que ver con lo que se ha filtrado.

  • Ambos SoC utilizan interfaz de memoria LPDDR5.
  • Interfaz de memoria: 64 bits para el modelo para smartphones, 128 bits para el modelo para tablets.
  • 24 CUs (12 WGP/12 DCU) para el modelo para tablets.
  • 12 CUs (6 WGP/6 DCU) para el modelo para smartphones..
  • El modelo para smartphones > Apple A13Z en cuanto a GPU.
  • La configuración de las CUs es la misma que en los modelos para PC por lo que olvidaos de cosas como «Custom Compute Units».
  • Pese a que los medios hablan de RDNA 2, en realidad es RDNA 1 con algunas mejoras leves por lo que olvidaos de Trazado de Rayosy Variable Rate Shading pero no de los Primitive/Mesh Shaders.

Esto es todo, tenéis los comentarios de esta misma entrada para comentar y no olvideis que tenemos Discord.

4.8 4 votes
Article Rating
4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nitupensis

AMD que se conozca lanzo la familia opteron A1100 basados en ARM para servidores, de hecho son los únicos que han lanzado comercialmente a empresas hasta la fecha, nosotros tenemos varias placas del fabricante Lenovator con estos soc opteron de cuando estuvieron a la venta y creo que Amazon los estuvo usando remarcados para ciertas tareas en su cloud. Eso si nunca les sacaron sucesores usando arm. 
 
 
 
 

Last edited 3 months ago by Nitupensis
Nicco

Solo los vendieron un par de ensambladores a nivel empresarial y no fueron muy populares, por lo que tuvieron un periodo de vida bastante corto. Amazon no los uso que tenga constancia, lo que si se indicó es que inicialmente AMD los estaba realizando en exclusiva para Amazon, pero al no cumplir con los rendimientos esperados, Amazon termino decantándose por realizar su propio diseño y AMD saco los A1100 tras varios retrasos, más por darle salida y aprovechar el proyecto que otra cosa, vamos solo 4 ensambladoras se interesaron en usar estos SoC y solo dos llegaron a lanzar productos… Read more »

Last edited 3 months ago by Nicco
Lalala

Lo lógico es que sea RDNA 2 sin unidades de intersección de raytracing. Todo lo demás mejora el rendimiento. Mesh shaders, vrs, IA…

Steven

Hola disculpa la duda cambiaran el rastealizador a tile como Apple