Por fin AMD ha publicado el White Paper de la arquitectura RDNA y en ella hay una serie de cosas que me llaman poderosamente la atención y que al mismo tiempo me llevan a corregir ciertas afirmaciones hechas previamente.
#1 El Funcionamiento de la Cache L1
Los diagramas de AMD son confusos ya que dan a entender que la cache L1 es tanto de lectura como de escritura.


En el documento de AMD se puede leer lo siguiente:
La memoria caché L1 de gráficos es una memoria caché de solo lectura respaldada por la cache L2 compartidos globalmente; escribir en cualquier línea en los gráficos L1 invalidará esa línea (y el dato) ira a la Cache L2 o la memoria. Ahí un modo explicito que permite hacer bypass explicito y evitar que los shaders pongan datos en la Cache L1.
Esto es curioso, resulta que todo lo que se escribe en la cache L1 se escribe realmente a la Cache L2, pero en el mecanismo de captación de datos para la lectura entonces la Cache L2 si que puede alimentar a la Cache L1 con una serie de datos. AMD no da en el Whitepaper un motivo para la existencia de la nueva cache.
Al pasar a una nueva tecnología como es el proceso de 7 nm, se reduce el área y el consumo energético de los transistores,
Uno de los mayores desafíos es que el rendimiento y la eficiencia del cableado tiende a mantenerse igual o empeora. En consecuencia, el envío de datos a largas distancias se vuelve cada vez más costoso.
Esto es fácil de entender, cuanto más lejos esta una memoria de la ALU más largo es el camino y más tiempo hay por instrucción, si se reducen las ALUs pero no la distancia del cableado por otros motivos entonces lo que acaba ocurriendo es que el salto no es tan eficiente… ¿Y que ha hecho AMD? Colocar una cache intermedia nueva como parche a la hora de la captación de datos. La captación de datos no es otra que la búsqueda de manera jerarquica de un dato concreto en la jerarquía de cache y después en la memoria.
El hecho que la cache L1 de cada cluster sea de solo lectura impide que la primera generación de los RDNA funcione como un Tile Renderer, todos los elementos cuando escriben sobre la Cache L1 realmente lo hacen sobre la cache L2 pero si pudieran escribir sobre la cache L1 directamente entonces si que podría funcionar como un Tile Renderer dado que la cache L1 serviría como memoria interna para el backbuffer de cada uno de los tiles, es posible que AMD en RDNA2, especialmente el chip que esta haciendo para Samsung permita eso, pero en RDNA por el momento no se puede por el hecho de que la Cache L1 es de solo lectura.
#2 La Cache L0
Esto es sumamente interesante, AMD ha pasado de que el ancho de banda de las caches sea de 64B/ciclo a 128B/ciclo en todos los niveles de la cache, duplicando el ancho de banda por ciclo de reloj, esto incluye la cache L0 que es utilizada como cache de texturas.

En GCN los 64B/ciclo permitían alimentar a las 4 unidades de texturas con 16B/ciclo de texturas y dado que para el filtro bilineal necesitaban la información de 4 pixeles esto permitía que este fuese gratis, pero cosa como el trilineal y anisotrópico requerían varios ciclos de reloj adicional por texel. A primera vista podemos pensar que ahora va a ser posible hacer filtro trilineal ya que el sistema ahora transmite información de 8 direcciones de memoria.
Las texturas se almacenan en la cache L0 y se acceden de manera similar a los datos.
Sin embargo, los resultados se pasan primero a la unidad de mapeo de texturas, que puede realizar el filtrado de las mismas con hasta ocho direcciones de textura por ciclo de reloj,
Si tenemos en cuenta que necesitamos 8 muestras para el filtro trilineal entonces…

… podemos suponer que las TMUs pueden realizar filtro trilineal en un solo ciclo, no obstante…
Por cada dirección, la TMU sampleara los cuatro vecinos más cercanos, descomprimira los datos y realizará la interpolación (filtraje). El valor final de texel se devuelve al SIMD a través del bus de respuesta.
Las TMUs siguen operando para el bilineal, la explicación de AMD es que esto permite tener la misma tasa de texturizado en RGBA8 como en RGBA16F, dado que en GCN la tasa de relleno era la mitad.
La unidad de mapeo de texturas ha duplicado elr endimiento para el filtraje bilineal de 64 bits (utilizado como flotante de 16 por cada canal RGBA).
Es decir, podemos hacer bilineal RGBA16F en un ciclo pero no trilineal RGBA8 no por limitaciones de la cache sino de las unidades de texturas. ¿Y si solo puede trabajar con 4 muestras entonces que ocurre con el resto de lo datos? La primera respuesta es que sirven para los dstos que no son de textura y por tanto no están relacionados con los Pixel/Fragment Shaders.
Una nueva característica de la arquitectura RDNA es que las cargas de imágenes funcionan más rápido. Aquellas cargas que no realizan muestreo (de texturas) omitirán el hardware de interpolación de texturas y funcionarán a la misma velocidad que las cargas de búfer, mejorando el rendimiento en 8X y reduciendo la latencia en un 35% en
el caso de que haya un cache miss sobre la caché L0, incluso cuando se realiza la conversión de formato. Esto permite calcular efectos de shaders, que a menudo dependen de accesos a imágenes, para ofrecer un mayor rendimiento y mayor eficiencia.
Hoy en día se utilizan lo Compute Shaders para efectos de post-procesado visual, los Compute Shaders no requieren el filtraje y al contrario de los Pixel/Fragment Shaders no requieren el tiltraje de texturas sobre los datos. En GCN todo lo que se leía de la cache de texturas de la Compute Unit era filtrado y solo se enviaba un texel de información a la Compute Unit que era el resultado del filtraje, en el caso de RDNA se pueden enviar hasta 8 datos directamente al shader en vez de 1.
Esto es importante de cara al futuro porque sabemos que no solo las ALUs dentro del Workgroup/Compute Unit Dual por un lado y la unidad de texturas por el otro van a ser clientes de la cache L0/Texturas sino que tenemos la información de cierta patente donde se nos habla de la unidad de interseccíón de rayos dentro de la unidad de texturas, cosa que veremos en las RDNA para consolas y en PC en unos meses o el año que viene.

Es decir, con el aumento de clientes de la cache de texturas/datos dentro de cada Compute Unit es normal que se haya aumentado el ancho de banda de la misma, y si os parece extraño os diré que en el caso de Nvidia Turing su equivalente es cliente del RT Core.

El cambio de los 64B/ciclo a los 128B/ciclo para todas las lineas de cache aumenta enormemente el ancho de banda respecto a cualquier chip de la familia GCN incluyendo Vega.

Por otro lado, esta información adicional nos permite completar el puzzle al completo, teniendo en cuenta que la unidad de texturas trabaja con 4 muestras y sumando el hecho que para el salto de los 1080P a los 4K donde es necesario aumentar las tasas de relleno, texturizado y sus anchos de banda correspondientes en 4X si se quiere realizar lo que es el escalado a lo bruto.

#3 Completando el puzzle de PlayStation 5
Si queremos dar el salto a lo bruto de PS4 a PS5 sin tener que modificar el software entonces necesitamos una tasa de texturizado que sea 4 veces superior, existiendo unas 72 unidades de mapeo de texturas (TMU) en PS4 entonces a 800 Mhz entonces:
72*(800*10^6)= 57.6 Gtexeles/s
Para 4K a lo bruto: 230.4 GTexeles/s
La última noticia que tenemos es que la GPU podría ir a 2 Ghz, supongamos por un momento que la tasa de texturizado en PS5 es de 230.4 GTexeles/s precisamente, esto nos debería permitir saber cuantas Unidades de Texturas y por tanto Compute Unit serían necesarias y sinceramente, con la velocidad de 2 Ghz que se filtro hace poco, los números que salen pues no son muy redondos.
Gtexels | Ghz GPU | TMUs | Compute Units | GFLOPS |
230,4 | 2 | 115,2 | 28,8 | 7372,80 |
230,4 | 1,8 | 128 | 32 | 7372,80 |
Curiosamente la tasa de FLOPS corresponde exactamente con la de 4X la tasa de FLOPS de PS4, lo cual cuadra al 100% con un salto en 4X. Esto no significa que la GPU solo tenga 32 CUs, pero solo necesita una 32 CUs (16 WGP) para reproducir los juegos de PS4 a 4K. Hay que tener en cuenta que una de las habilidades que tienen las GPUs de AMD de Polaris en adelante es la capacidad de aislar varias CUs del pipeline gráfico para otras tareas, esto es utilizado especialmente en el True Audio Next para hacer que parte de la GPU se encargue de renderizar el audio de la escena, función que no se ha perdido en RDNA.

La capacidad de reservar Compute Units debería estar. Claro esta que existe una segunda posibilidad y puede que me equivoque al 100%, pero es la que le veo más posibilidades de ser así. Creo que vamos a ver como la velocidad de reloj de la GPU irá fluctuando según cada necesidad (modo) y que en modo GCN para la compatibilidad hacía atrás va a ser necesario tener la misma cantidad de Compute Units. ¿Entonces? Pues para el modo PS4 4K sin mejoras y a lo bruto tiene más sentido una velocidad de reloj de 1.6 Ghz porque esto implica unas 36 CUs…
Gtexels | Ghz GPU | TMUs | Compute Units | GFLOPS |
230,4 | 1,6 | 144 | 36 | 7372,80 |
Tener unas 36 CUs permite colocar la GPU en modo PS4 Pro, reducir la velocidad a 911 Mhz y de paso hacer que la ejecución de las instrucciones pase a modo GCN en vez de RDNA.

Tened en cuenta que por FLOP RDNA es mucho más rápida por necesitar menos ciclos de reloj para las instrucciones.
En modo PS4 puro solo haría falta desactivar la mitad de las Compute Units y ponerlas a 800Mhz, de esta manera los juegos de PS4 se ejecutan en PS5 tal cual sin cambios pero al mismo tiempo es posible crear un modo PS4 4K… ¿Nos indica esto que la GPU de PS5 esta compuesta solo por unas 36 CUs y por tanto unos 18 WGP? Bueno, en consolas es típico eliminar alguna que otra unidad por Shader Engine, en el caso de Navi 10 (RX 5700 y RX 5700 XT) tenemos 2 Shader Engines con 10 WGPs cada uno, el RX 5700 funciona teniendo fisicamente todos ellos pero desactivando un WGP por Shader Engine, quedandose con 18 WGP/36 CUs.

Tened en cuenta que en los codigos del PCI ID se ha ido reservando las posiciones empezando por el 13E9 a principios de año..

Sabemos que el 13e9 corresponde a una Navi 10 Lite.

Por lo que podemos concluir que los huecos entre el 13f0 y el 13ff estarían reservados para diferentes iteraciones de la GPU con pequeños cambios, dando a cada iteración una ID distinta para identificarla de las anteriores pero sin cambiar la configuración general ya que obligaría a re-diseñar todo el chip.


Lo de Navi 10 es significativo porque nos marca la misma GPU que la gama RX 5700 por lo que la configuración de 40 CUS/20 WGP con 36 CUS/18 WGP activas tiene sentido. ¿Pero que significa Lite? Sabemos que cada chip de la arquitectura RDNA/Navi tiene su versión Lite.

Por lo poco que se, Lite hace referencia a cuando la GPU esta integrada dentro de un SoC/APU, es decir, cuando es una iGPU y no una dGPU (tarjeta gráfica aparte).
Pòr motivos de espacio en el chip final de PS5 tiene sentido que con solo 36 CUs hayan decidido colocar el pico de velocidad de la GPU primero en 1.8 Ghz y luego en 2 Ghz para la reproducción de juegos de PS5. Esto es algo que ya comente hace unos días en una de las entradas, que no vais a ver tantas Compute Units como la gente se espera en el hardware de PS5. Por lo que con esto ya tendríamos el puzzle cuasi completo de la consola, por no decir completo a no ser que aparezca alguna pieza secreta por el medio que por el momento desconocemos.
#4 Posibles Especificaciones de PlayStation 5
- CPU Zen 2.
- 8 Núcleos, 2 Hilos de Ejecución por Núcleo, 16 hilos en total.
- 8MB de Cache L3, 4MB de Cache L3 por CCX (4 núcleos por CCX).
- 32 GB GDDR6 con un bus de 256 bits a 18 Gbps (576 GB/s).
- GPU RDNA++ (Soporte Raytracing)
- 36 Compute Units/18 Workgroups
- 144 Unidades de Texturas
- 64 ROPS/16 RBE
- Modo PS5: 2 Ghz
- Modo PS4 4K: 1.6 Ghz
- Modo PS4 Pro: 0.911 Ghz
- Modo PS4: 0.8 Ghz (mitad de las CUs inactivas).
- TFLOPS en FP32 (modo PS5 y por tanto RDNA): 9.2 TFLOPS
- Tasa de texturizado (modo PS5): 288 Gtexeles/s
- Tasa de relleno: 128 Gpixels/s
Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.
gracias por tu analisis, siempre es agradece y es logico y adecuado
las spec que comentas spec «finales» de lo que seria ps5 es algo que cuadra perfectamente.. implica lo justo para dar un salto grande a ps4 y lo justo para que no se salga de madre en precio
salvo los 32gb de ram, que posibles son pero yo diria mas 24g o 16gb, para ajustar mas el precio y en la ps5pro dentro de 3 años despues sacar la ps5pro con 32gb o mas
salvo eso estoy de acuerdo contigo en esas spec
pd: podrias hacer una entrada sobre el SSD de como sony podria hacer un sistema , soldado a placa, como podria ser ese «cartucho» de expansion de memoria ssd que podria ser usado, la implicacion de un hd mecanico interno o solo por usb o poder usar directamente un hd mecanico de la ps4 ( cosa que dudo ya que teoricamente ps5 usa otro SO ), si sony usaria un ssd completo base o como microosft que segun microosft su ssd sera como una cache entre la cpu y un hd mecanico, cosa que implica que scarlet trae si o si un hd mecanico y un ssd pequeño125gb o 250gb como mucho, para usarlo como cache
etc etc
despues de la cpu para mi la cosa que mas espero es el uso de este ssd en ps5, son las cosa que mas lartraba ps4 y ps4pro, ya que en tema gpu se sabe que rendira mas o menso fps mas o menos pero cumpliria, pero habia que corregir el tema de la cpu era sangrante que se fuera toda la fueta por hay y el tema del ssd pues ya se empezaba a notar mcho unos tiempos de carga muy tochos
saludos y ganas ya de llegar a febrero ver ese playstation meeting t saber fecha y datos y si se puede precio tb ese dia
Me gustaMe gusta
Hola buena entrada el disco duro yo creo que será combinación ssd y hdd por coste
Me gustaMe gusta
sony creo que comento que ps5 traeria solo un ssd nada de ssd y hd y usar el ssd como cache…
esto si lo dijeron phil spencer de que scarlert usarian una cache de ssd
pero claro.. del dicho al hecho sony puede cambiar de idea
a mi no me gusta usar ssd como cache… principalmente por la razon que lso SSD se desgantan con el uso escribir una y otra vez
para lo que NO sirbe un ssd es para usarlo como cache, los destroza e la vida util se acorta de sobremanera
esto seria una de las razones grandes de no comrpar scarlet.. ya que como hagan como siempre que no peudes cambiar HD no podrias cambiar el ssd interno de esta que usa cocmo cache.. ya que va a durar poquitos años
espero que sony no use el ssd comoc ache y cumplan con lo que dijeron de ssd unico
ya ue este ademas implicaria que como minimo traeria un ssd de 500gb pero minimo extremo ya que considero que como minimo en 2020 1 tera tiene que trae si o si ps5 de base
veremos que hace sony y a ver que opciones sabe urian de posibilidades de como implementar estos ssd que seguro que el sabe mas de estas cosas
como dije yo espero que el ssd sea soldado a placa , esto abarataria costes a meter 1 tera o 2 teras ( versiones de ps5 , lease ps4 500gb ps4 1 tera ) y despues un puerto sata para un hd mecanico y un puerto m2 o algun simil donde meter un m2 memoria o cartucho, donde sony venda sus memoria expansion «propietarias» dandote opcion de tener un hd m2 ssd mas tocho o 2
pero bueno corto ya que si no…. un saludo
Me gustaMe gusta
32 gigas de ram me parecen una salvajada, y como comentaste en otro post, parece que microsoft le basta con 20, me decanto por 24 gigas como dice el de arriba, asi sony puede hacer marketing de esos 4gigas extras.
Me gustaMe gusta
Yo veo mas los 20 gb de ram:
8 chips de 2 gb gddr6 en una cara de la placa
Y en la otra 2 chips ddr3 o 4 segun coste que sumen 4 gb par el s.o. y al menos 512 mb opcionales para los estudios que quieran optimizar metiendo ahí el ejecutable y dlls
Así evitando frenazos de semáforo de ram compartida, al menos por el s.o.
Hasta aquí son 20 gb y no creo que metan más gb ddr3 para buffer de video pero es una posibilidad
Luego entre 6 y 4 chips según lo anterior de tipo ssd, entre 256 y 384 gb
Siendo así los 16 chips de memoria de ps4 entre ambas caras
Me gustaMe gusta
En ps4 son unos 900 mb para grabación permanente de los últimos 15 minutos
Me gustaMe gusta
Muy interesante tu análisis Urian, se agradece además tener más incógnitas sobre Ps5 clarificadas, o por lo menos, saber por dónde van los tiros…
Sé que esto es ya pasado, pero en ocasiones, especialmente con Nintendo, aunque también con las demás compañías de hardware, has analizado su situación, desde el punto de vista de su estrategia empresarial.
Me parece muy interesante aunque no me queda claro del todo cómo Sony pretende lograr, lo que, respecto a la conectividad y juego ininterrumpido pretenden de la siguiente consola, te agradecería que dieras tu punto de vista, gracias por tu esfuerzo.
https://www.google.com/amp/s/www.eleconomista.es/noticias-amp/9890286/La-estrategia-de-Sony-para-PlayStation-5-una-consola-para-jugar-ininterrumpidamente-y-desde-cualquier-lugar
Me gustaMe gusta
Yo creo que eso tiene que ver con el plan original de PSNow y que ahora van a poder llevar a cabo usando Azure de Microsoft. Ahora si no tienes PS4 solo puedes usar PSNow en el PC. Si buscas un poco verás cuantos dispositivos tenía Sony en mente como plan original. Tanto Microsoft (sigo pensando que por el momento solo buscan el mercado móvil de países como India, China, Corea, etc) como Sony han metido prisa a sus servicios de streaming por Google Stadia. Google tiene mucha pasta, las desarrolladores encantadas al igual que están con los dineros de la tienda de Epic.
Yo creo que el primero que consiga meterse en el ecosistema Apple tiene las de ganar. Imagina gente con IPad jugando a juegos de Playstation.
Sigo diciendo lo mismo. No es lo mismo meter el streaming en una TV en el salón que en un IPhone o un IPad.
Aunque tengo la impresión que la unión Stadia + Youtube va a dar mucho asco. Youtubers diciéndonos lo que mola Stadia, recomendando videojuegos, llevarse unos dineros por los links de afiliados, etc.
Y otra cosa que sé que lo sabéis pero cual es el negocio de Facebook y Google? Cómo hacen tanto dinero estas empresas? Sabéis lo que cuesta mantener Gmail, YouTube, etc?
No va a tener que ver nada DeepMind y sus inteligencias artificiales para que en el 2020 Stadia tenga versión gratuita? Como coño puedes mantener semejantes servidores sin cobrar a la gente? Cuantas compañías hay que ofrezcan VPNs gratuitas? Cuanto tardan las compañías en cerrar servidores por los gastos que ocasiona? Hace años Microsoft era el monopolio malvado y hoy en día la gente nos habla maravillas de GOOGLE porque son muy cool y usan software libre.
En fin.. siento salirme del tema y por la chapa pero no me gusta un pelo todo el poder que tiene Google y a la gente parece no importarle. Al igual que la gente en general te dice lo guay que es Apple cuando son una de las empresas más anti usuarios que hay con sus políticas mafiosas de reparaciones.
Me gustaMe gusta