Test des Radeon RX 9070 & 9070 XT : AMD de retour aux affaires ?

RDNA 4

Pour vous aider dans la compréhension de ce dossier, vous pouvez lire auparavant la page que nous avions dédiée à RDNA 3. Avec les RX 9070 (XT), AMD étrenne une nouvelle révision de sa microarchitecture grand public : RDNA 4, qui se doit - tout comme ses concurrentes - d’évoluer non seulement au niveau des performances brutes (comprendre, en rastérisation/GPGPU), mais également sur deux autres fronts inaugurés il y a quelques années : le Ray Tracing et l’IA. Dans ces deux cas, les rouges souffraient d’un retard par rapport à la concurrence verte, pionnière du secteur, bien qu’AMD ait réussi à camoufler tant bien que mal la déficience côté machine learning (c’est-à-dire des performances en multiplication de matrices en retrait) au moyen d’une implémentation FSR s’en passant, mais avec un résultat visuel de moindre qualité. Or, avec le FSR 4 (que nous détaillerons ultérieurement), la firme de Lisa Su a également basculé sur l’IA, requérant de ce fait un support matériel et, ainsi, une mise à jour hétérogène de la brique de base de la microarchitecture : les Compute Units (CU). Voyons cela en détail, d’abord par le côté « classique » du CU, avant de plonger sur la partie matricielle puis l’accélérateur de Ray Tracing. 

Des CU plus compétents, mais toujours en dual issue

Au niveau de la structure interne, les CU demeurent « dual issue » et conservent la particularité introduite avec RDNA 3 d’intégrer non pas une, mais deux unités vectorielles SIMD32 : une principale et une auxiliaire. Ces deux unités sont en théorie utilisables en parallèle — en pratique la chose est plus complexe et soumise à de nombreuses conditions — via l’instruction VOPD. En fait, RDNA 4 reprend la majeure partie de la structure logique de la génération précédente, dont l’accouplement par deux des CU (nommés également WGP pour WorkGroup Processors… mais qui n’a rien à voir avec le Dual Issue !). Nous retrouvons ainsi nos deux unités vectorielles SIMD32, la principale gérant également les calculs entiers ; des unités « transcendantales » calculant les opérations complexes — inverse, racine carrée inverse, racine, puissance, logarithme, sinus, cosinus — en SIMD toujours, mais sur 8 éléments ; ainsi qu’une unité scalaire et une unité d’IA sur laquelle nous reviendrons plus en détail dans la sous-section suivante. Rassurez-vous toutefois, quelques améliorations viennent se glisser çà et là pour augmenter (toujours plus !) les performances dans le pipeline de rendu classique !

En effet, les unités scalaires sont désormais capables de calculer sur des opérations flottantes, limitant ainsi le travail des unités vectorielles dans certains cas. Des primitives de synchronisation supplémentaires apparaissent, à savoir les split and named barriers : la première autorise les threads à continuer à exécuter partiellement des opérations alors que la barrière est atteinte, et la seconde permet à un nombre restreint de threads d’appliquer la barrière de manière à spécialiser davantage les waves utilisées lors de l’ordonnancement des calculs. L’idée est ici de maximiser l’utilisation des unités et éviter au maximum les temps d’attente, même lors des synchronisations. En outre, les manipulations de registres par blocs de 32 (éventuellement en utilisant un masque pour en omettre) sont également améliorées, ce qui a pour effet d’accélérer les appels de fonctions. Similairement à ce qui se fait sur les CPU, de nouvelles instructions de prefetch ont été ajoutées, ce qui permet de rapatrier en avance des données dans le cache lorsque les mécanismes de prédiction sont dans les choux, évitant ainsi un blocage du pipeline au moment de leur utilisation.

Comme toute la série des RDNA, les CU sont regroupés par deux pour mettre en commun leur cache, formant un (choisissez ce qui vous arrange) WorkGroup Processor/Compute Engine/Dual CU

Or, si vous êtes familiers des modèles de programmation des GPU, cela signifie que ces instructions sont asynchrones : le GPU ne doit pas se bloquer pour attendre la donnée — autant faire directement le chargement plutôt que le prefetch. C’est ainsi que le modèle mémoire de RDNA 4 se relaxe en autorisant les chargements dans le désordre (ou Out-of-Order en anglais) : il est possible pour le sous-système mémoire de continuer à fournir les threads en données alors qu’une requête est encore en cours de traitement. Tant que les CU demeurent In-Order (c’est-à-dire que leurs instructions sont exécutées dans l’ordre d’arrivée, avec blocage complet si cela est nécessaire), l’intérêt est limité… sauf pour le Ray Tracing où le BVH (un algorithme utilisé dans ce cadre) et ses accès non-alignés, créent de nombreuses bulles dans les files d’attente mémoire, entraînant de potentiels ralentissements sur d’autres threads. Avec RDNA 4, l’exécution des requêtes mémoire dans le désordre — couplées aux 64 Mio d’Infinity Cache, qui passe en troisième génération sans plus de précision sur leur évolution — évite ce phénomène.

Enfin, la dernière nouveauté de RDNA 4 prend place dans l’allocation de registres. Usuellement, les charges de travail (graphiques ou scientifiques) des shaders sont régulières, c’est-à-dire que l’on peut facilement approximer le nombre de registres, les calculs et l’empreinte mémoire des programmes sans avoir à les exécuter. Avec le lancer de rayons, cela n’est plus le cas, notamment parce que la trajectoire d’un rayon après rebond est imprévisible. Sur RDNA 3, le GPU utilisait un nombre de registres fixe par shader, suffisant pour être sûr de pouvoir le nourrir correctement tout au long de son exécution : une approche correcte, mais qui résulte en une utilisation incomplète des ressources matérielles lorsque la période pendant laquelle tous les registres sont utilisés est courte (cf. schéma ci-dessous).

La solution proposée avec RDNA 4 est d’offrir un mode (facultatif) dynamique d’allocation permettant de piocher à la demande dans une pile de registres disponible à tous. En cas de famine (pas assez de registres pour tout le monde), la partie logicielle viendra stopper le shader le temps que l’un d’entre eux se libère. Sur le papier, cette optimisation permet d’améliorer l’efficacité du GPU en autorisant l’exécution concomitante d’un nombre accru de shaders ; encore faut-il savoir l’utiliser correctement !

Des cœurs IA plus versatiles

Alors que CDNA — l’architecture pour data center d’AMD — intègre des unités matricielles puissantes capables d’opérer en FP32 complète, que l’on aurait pu penser débarquer sur ces RX 9000, RDNA 4 suit en fait timidement la voie de RDNA 3. Ainsi, point de cœurs matriciels à proprement parler (les rouges conservant ce terme pour ceux de CDNA), mais des « IA Core » plus modestes limités au FP16 (le « F32 » marketing correspondant à des multiplications-accumulation sortant bien du 32-bit flottant, mais prenant en entrée du 16-bit flottant !). Cependant, la concurrence de NVIDIA n’est pas meilleure à ce niveau, puisque les Tensor Cores verts sont également dépourvus de capacité de traitement FP32 complet. En outre, la firme de Lisa Su n’a pas chômé, puisque RDNA 4 rattrape le retard des architectures précédentes en apportant la prise en charge de la sparsité à un facteur 50 % maximum (c’est-à-dire la capacité d’opérer sur des matrices composées d’un maximum de 2 zéros par blocs de 4 éléments), permettant de virtuellement doubler la capacité de calcul. D’ailleurs, cette capacité de calcul FP16 est elle aussi doublée pour culminer à 1024 opérations par cycle par CU (en mode dense) ; les rouges rajoutant au passage les formats de données FP8 et BF8 pour toujours plus de puissance pour les réseaux de neurones modernes.

De plus, RDN4 inclut des instructions de chargements globaux des données matricielles, dont un permettant de transposer à la volée des matrices lors de leur mise en registres, ce qui accélère grandement certaines opérations de calcul scientifique et de machine learning.

Au niveau des interfaces, les multiplications matricielles passent toujours par l’instruction wmma , mais l’effet de cette dernière est étendu pour prendre en charge les changements matériels. Intéressant, bien que le système demeure encore limité dans son utilisation. Il est par exemple toujours impossible d’effectuer ces multiplications matricielles en même temps que des opérations vectorielles au sein du même CU (il faudrait pour cela avoir recours à wgmma), ce que propose désormais la concurrence pour le grand public avec les neural shaders.

Toujours plus de Ray Tracing !

Depuis l’avènement du lancer de bâton rayons dans les jeux modernes, les Radeon ont été frileuses dans ce domaine et offrent des performances bien en deçà des concurrentes vertes. La « faute » incombant au choix d’intégrer des cœurs aux capacités limitées, ce qui permettait par contre de réduire la taille de la puce, et, ainsi, son coût. Avec RDNA 4, la prolifération de la technique de rendu sur la scène triple-A ne donne guère d’alternative : les rouges doivent se mettre à niveau là-dessus !

Et (sur le papier tout du moins) force est de constater que l’innovation est bien là. Déjà, le débit des unités BVH (Bounded Volume Hierarchy, une des étapes du Ray Tracing), est doublé par l’ajout d’une unité supplémentaire Intersection Engine, également chargée des collisions rayons-triangles. De ce fait, les cœurs RT travaillent désormais sur un arbre à 8 branches maximum par niveau au lieu de 4, ce qui réduit fatalement la profondeur de la structure, et donc le nombre d’étapes pour en venir à bout. C’est tout ? Non, une structure de donnée plus compacte de 40 % a également été développée afin de réduire l’empreinte mémoire du Ray Tracing pour toujours plus d’efficacité et moins de pollution des caches.

De plus, une unité de transformation des rayons est ajoutée pour traiter les opérations de modification de la structure du rayon tout au long du parcours du BVH. Auparavant, ces dernières étaient exécutées sur la partie classique des CU, ralentissant le rendu. Citons également des améliorations au niveau de la gestion de la mémoire tampon de 128 kio par double-CU gérant les structures du BVH (Local Data Share sur le slide précédent, ou Shared Buffer sur celle des CU) en rajoutant de nouvelles instructions permettant une gestion plus fine des données.

Enfin, là où NVIDIA proposait sur Blackwell des unités de gestion des brins (cheveux, herbes, etc.), AMD s’est concentrée sur un autre aspect : l’orientation des boites. Si les boites traversées par les rayons ont traditionnellement des arrêtes parallèles aux axes (comprendre, verticales ou horizontales selon des paramètres spécifiques à la scène), cela n’est pas bien adapté pour certains objets situés en travers. Dans ces cas-là, la traversée du BVH est très souvent caduque, puisque même les boites contenant l’objet sont en fait majoritairement composées du… vide qui l’entoure. En autorisant des rotations au niveau des boites, il est possible de décrire avec plus d’efficacité les objets qu’elles entourent, et, ainsi, accélérer le parcours du BVH d’en moyenne 10 % selon la firme.

Mises bout à bout, ces améliorations permettent au total de doubler les performances dans les tâches de Ray Tracing ; bien que le progrès exact soit dépendant de la scène observée (i.e. de la structure traversée lors du BVH). De quoi limiter les baisses de framerate liés à l’activation de la technologie en jeu, qui pourra éventuellement être assistée par un FSR infusé à l'IA. C’est en tout cas l’objectif qui ressort des modifications effectuées au sein de l’architecture, bien plus concentrées sur les cœurs IA et le Ray Tracing que le pipeline de rendu classique. Évidemment, il nous reste encore à vérifier cela en pratique sur le banc de test !

Média Engine

Si les GPU servent principalement à jouer, ces dernières années ont vu proliférer le streaming, comprenez ici le fait de diffuser ses parties en temps réel auprès de ses amis et/ou public. Pour éviter de surcharger le CPU de cette tâche, les puces graphiques intègrent des encodeurs matériels — AMD AMF, Avanced Media Framework dans notre cas —, pour réaliser l’encodage desdites vidéos à la volée. Problème : la qualité de la vidéo de sortie dépend de l’implémentation du media engine chargé de faire la conversion, et AMD est notoirement en retard sur ce point. RNDA 4 prétend ainsi corriger le tir avec 25 % de gain en qualité annoncés en H264, 11 % en HEVC. Les performances sont également en hausse avec un gain en encodage de 30 % maximum en 720 p, et 50 % de gains lors des décodages sur les codecs AV1 et VP9. À voir en pratique via les retours des streamers.

Display Engine

Dernier pan de nos RX 9000 : le Display Engine, chargé de la transmission des images depuis le framebuffer jusqu’à l’écran. AMD est assez avare de détails à ce sujet, mais communique tout de même sur des améliorations de la consommation au repos sur les configurations multiécrans, une prise en charge matérielle des images précalculées (l’insertion des images tout juste calculées dans une file, de manière à limiter les synchronisations CPU-GPU à l’affichage de ladite image), et surtout l’insertion de Radeon Image Sharpening 2 directement à ce niveau. Ainsi, l’activation de l’option se résume à un unique bouton, quelle que soit l’API utilisée : cool ! Au niveau des connectiques, le classique duo DisplayPort (2.1 a) et HDMI (2.1 b) est de la partie : pas de souci de compatibilité à ce niveau même si on notera que les RX 9000 se limitent pour le premier à l'UHBR13.5 alors que les RTX 5000 proposent de l'UHBR20.

C’en est fini du détail de l’architecture RDNA 4, passons maintenant à la description du premier die en faisant usage.

Navi 48

Pour cette génération de cartes graphiques, AMD a annoncé (à l'heure actuelle) avoir conçu 2 GPU. Navi 44 qui équipera les 9060(s) et Navi 48 dévolu aux 9070(s). Nous allons donc nous intéresser à celui-ci en particulier. Même si les rouges ont souhaité limiter sa taille pour contenir les coûts de production, la puce intègre tout de même 53,9 milliards de transistors, soit davantage que GB203 (45,6 Mds) des RTX 5080 / 5070 Ti à titre d'exemple. Ce critère n'est pas totalement comparable entre concepteurs, mais cela démontre tout de même qu'AMD n'a pas renoncé à un GPU avec certaines ambitions. Il est gravé avec le procédé N4P de TSMC pour une superficie de 357 mm², donc moindre que GB203 (378 mm²).

Il nous semble que la fameuse gravure 4N utilisée par TSMC pour NVIDIA est moins dense que le N4P, même si la densité dépend aussi d'autres facteurs issus de la conception des unités et de leur répartition mémoire / calcul ; et qu'un relâchement de la densité peut également signifier une meilleure optimisation pour monter en fréquence. Quoi qu'il en soit, AMD peut caser davantage de Navi 48 sur un Wafer 300 mm que ne le peut Nvidia pour GB203. Les coûts respectifs de production dépendent du tarif négocié par Wafer et des rendements respectifs (Yields), mais il est probable que les rouges disposent ici d'un avantage. Et ce Navi 48 donc, comment se compose-t-il ?

Diagramme de blocs Navi 48

Diagramme de blocs Navi 48

Il s'appuie sur 4 Shaders Engines, chacun comprenant 8 Dual Compute Units (soit 16 CUs en tout), une unité de rastérisation, une autre chargée des primitives et enfin 4 partitions de 8 ROPs. Le sous-système mémoire est composé d'une hiérarchie de 3 caches, le dernier niveau nommé commercialement Infinity Cache par AMD étant doté d'une taille de 64 Mo interconnectés à 16 contrôleurs mémoire 16-bit. Enfin, sont présents les différents moteurs d'affichage et multimédias (encodage/décodage), ainsi que les processeurs centraux de commande et géométrie. Comment se différencient les 2 cartes ? Eh bien les rouges vont procéder à la désactivation de 4 Dual CUs au sein d'un ou plusieurs Shader Engines, sans toucher pour autant au sous-système mémoire. Cela conduit à conserver 87,5 % des unités de calcul, une baisse relativement modeste même si AMD va jouer sur d'autres leviers pour limiter la plus petite des deux, à savoir la limite de puissance et donc les fréquences de fonctionnement. Récapitulons tout cela dans le tableau suivant. 

À noter également qu'AMD emboite le pas de son concurrent en basculant lui aussi son GPU sur une interface PCIe Gen5 (x16). Voilà pour cette présentation de RDNA 4 et du premier GPU l'étrennant, passons à présent aux cartes reçues pour ce test.