Test • AMD RX 5700 XT & RX 5700

• RDNA : Caches et autres points

Il est temps à présent d'évoquer une autre évolution fondamentale apportée par RDNA : les caches, leur hiérarchie, la bande passante entre ces derniers et les diverses unités, ainsi que les différentes latences associées. Ces points sont critiques au niveau de la performance, mais aussi de la consommation énergétique d'un GPU (chaque requête sollicitant les contrôleurs mémoire étant extrêmement énergivore), c'est pourquoi AMD a décidé de procéder ici aussi à des modifications importantes. Afin d'éviter de complexifier davantage ce sujet, nous éluderons certains éléments tels que les caches de données et instructions qui n'évoluent pas ou peu, ils sont toutefois représentés sur les schémas illustrant cette section. 

Des caches améliorés

Pour commencer, les accès à la mémoire locale partagée (Local Data Share ou LDS composée de SRAM à l'instar des caches, et d'une taille de 64 Ko par CU), ont été améliorés. Cette dernière est un espace mémoire à proximité directe des ALU, disposant d'une latence très faible et s'intercalant entre le cache de niveau 0 (16 Ko / CU) et les registres (1024 / SIMD32 soit 128 Ko, chaque unité scalaire disposant de 32 Ko de son côté). AMD indique que la bande passante depuis le cache vers les unités de calcul, est à présent doublée par rapport à GCN à 128 octets / cycle. Un nouveau niveau de cache apparaît également, nous détaillerons celui-ci un peu plus bas. La conséquence de ces modifications est une réduction de plus de 20% des latences d'accès aux différents caches et de 7% pour la mémoire vidéo. Abordons à présent le cas particulier du L1 avec cette nouvelle micro-architecture : depuis l'introduction de GCN fin 2011, le cache de premier niveau (16 Ko) partagé entre les 4 SIMD16 d'un CU, n'a pratiquement pas évolué. Ce dernier existe toujours avec RDNA, mais porte à présent le nom de L0. Pourquoi ?

Eh bien avec la nouvelle architecture, un cache L1 constitué de 512 Ko fait son apparition. Il est divisé en 4 partitions, chacune interconnectée à un bloc de 16 ROP ainsi qu'au L2 (par le biais d'une Fabric dédiée). Chaque Shader Array (5 WGP ou 10 CU si vous avez lu la page précédente) intègre une de ces partitions de 128 Ko. De ce fait, les unités d'exécution profitent à présent d'un niveau de cache supplémentaire, au travers des 512 Ko de ce nouveau L1. Précisons au niveau du slide ci-dessous, qu'AMD fait apparaître 16 blocs nommés MC alors qu'il n'y a que 4 contrôleurs mémoire sur le diagramme général. Ces 16 "MC" représentent à priori les interconnexions de la GDDR6 : 8 puces avec 2 canaux pour chacune, soit bel et bien 16 canaux mémoire en tout.   

Poursuivons la partie dédiée aux caches, en nous attachant au L2 cette fois. Ce dernier reste stable à 4 Mo pour un GPU Navi 10, soit la même valeur que Vega 10/20, mais le double de Polaris 10/20/30. Là-aussi, ce cache est divisé en partitions plus petites (16 x 256 Ko), elles-mêmes en liaison avec les contrôleurs mémoire par le biais de l'Infinity Fabric. On notera tout de même que davantage d'unités sont clientes de ce L2 par rapport aux précédentes architectures, qui devaient alors pratiquer un accès direct à la mémoire, moins efficient. L'image animée ci-dessous permet de comparer les relations entre les unités et le cache L2 (+ L1 pour RDNA) dans le cas de GCN 4 (Polaris = uniquement les CU), puis GCN 5 (Vega = CU / CP / ROP) et enfin RDNA.

Toujours du côté du sous-système mémoire, s'il est un point où son concurrent disposait d'un avantage conséquent, c'est bien au niveau de la bande passante effective de cette dernière. En effet, le caméléon pouvait se contenter d'une puce avec bus 192-bit face à une version 256-bit, à ISO performance et mémoire (GP106 vs Polaris 10). Diverses raisons expliquent cela, dont la supériorité des algorithmes de compression couleur sans perte (Delta Color Compression ou DCC qui permet un codage différentiel des couleurs par rapport aux pixels adjacents) des verts. AMD a donc remis ces derniers sur le plan de travail et indique être parvenu à des algorithmes plus performants, mais aussi une utilisation étendue de ces derniers au sein du GPU. Les rouges ne communiquent pas de chiffres quant aux gains, mais en constatant que TU106, cible principal de Navi 10, utilise le même type de mémoire adressée via le même bus (RTX 2070), il ne fait pas de doute quant aux progrès de RDNA à ce niveau.

A noter tout de même pour clore le sujet, la disparition du HBCC (High Bandwidth Cache Controller) avec RDNA, tout du moins dans cette itération, l'option n'étant plus disponible au sein des pilotes destinés à la série 5700. Il s'agit pour rappel d'un mode de gestion évolué de la mémoire lancé avec Vega, permettant l'extension de l'espace mémoire GPU à la RAM ou aux disques du PC via pagination, la mémoire vidéo (HBM2 sur Vega) agissant alors comme un cache de dernier niveau pour ceux-ci.

Un GPU rééquilibré

Depuis l'avènement de Fermi et de ses unités géométriques découplées au plus près des SM (TPC), les verts dominent assez largement à ce niveau à gamme équivalente. AMD a toutefois fait progresser ce point au fur et à mesure de ses GPU. Il est difficile de considérer ce dernier comme handicapant sur les Radeon à l'heure actuelle pour un usage ludique, d'autant que les moteurs modernes sollicitent bien davantage les unités d’exécutions du GPU, que toutes autres. Les rouges modifient toutefois légèrement leur approche du sujet, avec à présent un "gros" processeur géométrique centralisé, accompagné d'unités traitant les primitives (triangles, lignes, etc.) et la tesselation au sein même des Shader Engines.

Si ces derniers ne sont qu'au nombre de deux sur Navi 10, le nombre de Primitive Units en leur sein est doublé (une par Shader Array), permettant ainsi de maintenir la génération et le traitement (réutilisation, etc.) de 4 triangles par cycle (voir plus si usage des Primitive Shaders introduits sur Vega et qui restent de mise avec RDNA). L'éjection des triangles inutilisés (pas affichés) via Culling, est toutefois deux fois plus rapide que sur les générations précédentes des rouges. AMD ne précise par contre pas, si les unités de rastérisation sont toujours de type DSBR (Draw Stream Bining Raseterizer) comme c'est le cas de Vega, et permettant des gains opportunistes via l'usage de Tiled Rendering.

Toujours dans un souci de rééquilibrage de son architecture, ici dans sa déclinaison Navi 10, AMD a décidé de doubler le nombre de ROP (Render OutPut unit) par rapport à Polaris, s'alignant ainsi au niveau de ses précédents haut de gamme, à 64 unités en tout (16 / Shader Array). De quoi lutter à armes égales dans cette gamme avec les verts. Mais les rouges ne se sont pas arrêtés en si bon chemin et ont décidé de faire progresser un élément qui est pourtant leur point fort depuis l'intronisation de GCN, le domaine du GPU Computing. Ainsi, les ACE (Asynchronous Compute Engine) sont légèrement retouchées pour prendre en charge le Tunneling des Async Compute, afin de pouvoir gérer précisément l'usage des ressources (jusqu'à l'arrêt complet en libérant complémentent les pipelines) lors d’exécution de tâches concomitantes, pour en privilégier certaines lorsque le besoin s'en fait sentir. 

AMD précise que toutes ces modifications apportées à l'architecture entraînent une progression de l'IPC de 25% par rapport à GCN. Les retours d'expérience des travaux réalisés dans le cadre de Zen, ont permis de gros progrès au niveau de la gestion d'énergie (synchronisation des signaux d'horloge) ou des ressources matérielles nécessaires pour la montée en fréquence. En effet, une bonne partie de l'inflation des transistors entre Fiji et Vega, n'avait pas été allouée pour de nouvelles fonctionnalités ou ALU, mais justement dans ce but (redondance de signal, correction d'erreurs, etc.), avec les conséquences que l'on connait au niveau de la consommation et des performances ludiques.

Le ratio de performance par watt progresse donc de 50% entre GCN et RDNA, ce qui est considérable. Il faut bien sûr prendre un peu de recul vis-à-vis de ce chiffre, car AMD compare une Vega⁶⁴ à une RX 5700 XT ne partageant pas le même procédé de gravure. Cela reste toutefois considérable et rappelle la rupture qu'a marquée NVIDIA à l'occasion du lancement de Maxwell. Les rouges insistent également sur le fait que 60% des gains réalisés côté performance, sont imputables à l'augmentation de l'IPC. Les seules améliorations liées au seul process, ainsi qu'à une meilleure gestion de la montée en fréquence, n'auraient pas suffi selon le concepteur. Vu le résultat de la Radeon VII, on ne peut être qu'en accord avec cette assertion.

Le Futur

Difficile depuis le lancement de Turing de complètement oblitérer la question du Ray Tracing. AMD en est bien conscient et a donc préparé sa réponse à ce sujet. Pour le moment, c'est un peu "circulez il n'y a rien à voir" (ce qui n'est pas faux non plus en termes de contenu pour l'heure), l'accélération hardware de ce type de rendu 3D n'avait pas été prise en compte lors de la conception de RDNA. Les rouges s'en tiennent donc pour l'heure à leur approche destinée aux applications professionnelles. Par contre, comme les annonces côté consoles et la dépose d'un brevet sur le sujet l'ont laissé entendre, une prochaine itération de RDNA proposera bel et bien une accélération matérielle de cette technique de rendu hybride, lancée par son concurrent. Enfin, AMD partage également sa vision plus lointaine sur le sujet, avec un usage du Cloud Computing pour un rendu intégralement en Ray Tracing à l'avenir.

Il ne faudra à priori pas attendre bien longtemps pour tester la version 2 de RDNA, qui est déjà dans les tuyaux et devrait débarquer en utilisant un procédé de gravure 7 nm optimisé (incluant vraisemblablement l'EUV) l'an prochain ou début du suivant. On peut donc légitimement penser que c'est à ce moment que la prise en charge hardware du Ray Tracing aura lieu. Reste à connaitre l'efficacité de cette implémentation (qui ressemble fort à ce que le caméléon a fait pour Turing d'après le brevet déposé), ainsi que les autres modifications qui seront apportées à l'architecture. Mais aussi et surtout si le gros "GPU" attendu pour enfin concurrencer NVIDIA en haut de gamme, utilisera cette nouvelle itération de RDNA, ce qui conduirait à un lancement l'an prochain au mieux, et un affrontement avec des puces concurrentes utilisant un process équivalent cette fois. 

Voilà, c'est tout pour RDNA, passons au premier GPU l'intégrant page suivante ainsi que les nouveautés l'accompagnant.