Nolan Mariotte
Nous revenons de l’article d’hier où nous parlions de ce GPU après avoir vu les données des tests, et dans lequel nous avons vu que les performances n’étaient pas celles attendues et qu’il y avait une marge très étroite entre RDNA 2 et RDNA 3. Après cet article, l’auteur a réfléchi, réfléchi toute l’après-midi, car étant donné les changements dans l’architecture, il était vraiment complexe de comprendre ce qui se passait. Eh bien, nous allons lancer une nouvelle théorie sur la table, qui pourrait être très intéressante : l’Overhead du RX 7600 souffre-t-il, et l’architecture RDNA 3 a-t-elle un problème avec lui en général ?
Tout d’abord, deux petites remarques. La première est la confirmation qu’AMD ne vendra pas son modèle de référence connu sous le nom de MBA, et qu’il sera donc entièrement personnalisé. Le modèle en tant que tel existe, mais il n’était destiné qu’aux analystes. Le deuxième point est le plus intéressant, car il concerne l’architecture et les nouvelles données qui ont émergé et que nous utiliserons pour argumenter la théorie que nous avons formulée.
AMD RDNA 3 et RX 7600, avis vs benchmark vs API
Avant d’aller plus loin, sachez qu’il s’agit d’un sujet dont nous avons discuté à la rédaction suite à mes recherches dans les livres blancs et les fiches techniques d’AMD. Il n’y a pas de confirmation officielle, il n’y en aura peut-être jamais, mais nous allons essayer de faire la lumière sur le problème des performances de la RX 7600.
Ceci étant dit, passons aux données qui ont été montrées. Dans l’image en dessous de ce paragraphe, nous avons les données pour la RX 6650 XT par rapport à la RX 7600, toutes deux à 1 GHz. Comme vous pouvez le voir, toutes ces données ont été compilées dans la suite 3DMark, qui est assez fiable pour donner des moyennes de performances très approximatives.
A 1 GHz pour les deux cartes, vous pouvez voir comment la RX 7600 obtient dans presque tous les benchmarks, à l’exception de Fire Strike Extreme, une augmentation de performance à deux chiffres. De 8,88% à 21,05%. D’autre part, et pour contraster ces données, qui sont bien plus élevées que les 4% ou 5% de moyenne montrés dans les tests d’hier, nous avons les données de l’API concernant ce que l’on appelle l’Overhead.
C’est là que les choses changent, avec des pertes incroyables pour la RX 7600, entre -21 % et -45,09 % dans Vulkan, mais alors, que se passe-t-il ? Comment est-il possible que dans les benchmarks de performance, elle montre jusqu’à 4 fois plus de pourcentage d’écart que dans les tests, et dans les tests API, elle tombe à presque la moitié par rapport à la RX 6650 XT ? Je suis sûr que vous vous dites qu’il doit y avoir une explication plausible.
Processus lithographique, transistors, densité et taille
Il y a beaucoup de disparité entre les benchmarks et les tests, c’est-à-dire entre les tests synthétiques et les jeux, mais maintenant nous ajoutons les API à l’équation. Dans les tests, vous pouvez voir les deux premiers points, le troisième est en cours d’étude et nous pensons avoir la réponse, ou du moins une partie de la réponse, et je vais l’expliquer.
Pour ceux qui ne l’auraient pas remarqué, la RX 7600 n’est pas fabriquée en 5nm, mais en 6nm, c’est-à-dire en N6 de TSMC. La RX 6650 XT, qui a presque les mêmes caractéristiques, est fabriquée en 7nm, et a donc un désavantage au niveau du nœud. En termes de transistors, nous avons 11,06 milliards pour le plus petit et 13,3 milliards pour le plus grand, ce qui nous donne une différence de 20,25% pour 14% de taille physique en moins (237 mm2 contre 204 mm2).
Avec ces données, nous pouvons prendre les densités : 46,7 M/mm2 pour la RX 6650 XT contre 65,2 M/mm2, ce qui signifie en pourcentage que la RX 7600 est 39,61% plus dense. Cela n’explique en rien les données ci-dessus, mais cela nous apprend quelque chose d’important : grâce à cette densité plus élevée, AMD a opté pour un cœur monolithique avec le cache L3 à l’intérieur, parce que c’était économiquement rentable, et c’est pourquoi le design de l’architecture RDNA 3 a été adapté pour intégrer ce cache dans le die.
C’est là que les choses deviennent intéressantes, car grâce à cette densité, AMD a pu se passer du coûteux N5 et utiliser le N6 moins cher avec un gain plus élevé par puce, ce que recherchent à la fois l’utilisateur (des graphiques bon marché) et l’entreprise (plus de profit). Le problème est que les changements qu’elle a dû mettre en œuvre lui ont fait perdre les performances que nous avions prévues à l’ECI.
Un problème d’overhead ?
Passons à la diapositive officielle d’AMD, où nous allons travailler sur la théorie des mauvaises performances. En bas de la diapositive, les gars de Lisa Su disent que grâce aux améliorations des CU (nous en avons parlé dans l’article sur l’architecture RDNA 3, dont nous allons tirer quelques données maintenant et que nous vous conseillons vivement de lire) l’architecture aurait gagné une amélioration clock per clock de 17,4%, ce qui, après les pertes de cache L3 et de latence sur les GPU MCM, comme les RX 7900 XTX et RX 7900 XT, nous laisse avec une scalabilité réelle d’environ 15%, ce que nous avons estimé au moins pour le RX 7600 sur la base des données d’AMD et de nos prévisions.
Dans le cas de cette suite 3DMark, ces tests cherchent à mesurer dans différentes API le nombre d’appels de dessin qu’un GPU peut gérer et représenter avant de planter ou de saturer. La méthode est simple, parce qu’elle doit l’être pour mesurer avec précision, et elle est basée sur la représentation de nombreux objets à l’écran, et bien sûr, c’est là qu’arrivent les bonnes choses.
Il n’y a que deux façons de faire échouer le test :
- L’unité centrale ne peut plus gérer les appels de dessin.
- Le GPU est limité et ne peut pas gérer autant d’appels de dessin.
Dans le cas du CPU, ce n’est actuellement pas faisable, et encore moins avec Vulkan ou DX12, qui curieusement représentent les plus grosses baisses. Nous n’allons pas expliquer pourquoi, ce serait trop long et cela a déjà été abordé par le passé, gardez juste l’idée en tête.
Le Command Processor d’AMD entre en jeu
Pour que la suite 3DMark dans la section API Overhead donne de si mauvais résultats en comparant une architecture à une autre, à spécifications et vitesse égales, il n’y a qu’une seule possibilité et un seul coupable : le Command Processor du GPU impliqué, dans ce cas, le RX 7600, bien qu’en réalité il s’agisse du RDNA 3 dans son ensemble.
Nous revenons ici à la diapositive supérieure fournie par AMD dont nous avons déjà parlé. Compte tenu de tous les changements que les CU ont subis et qui, comme nous l’avons dit hier, ne sont rien d’autre qu’une évolution de l’architecture RDNA 2 axée sur l’atténuation des problèmes de latence dus aux MCD et à leur L3, il est clair que l’on peut s’attendre à ce qu’il y ait des problèmes de latence.
AMD a ajouté une nouvelle unité à chaque unité centrale et à chaque double, appelée Float/Matrix SIMD32 pour chaque vecteur GPR. En outre, AMD a amélioré son fonctionnement matriciel en implémentant la deuxième génération d’accélérateurs d’IA, ce qui signifie que les ordonnanceurs ont dû fonctionner à une fréquence plus élevée et que le L0 a dû être doublé pour maintenir les performances acquises dans de bonnes conditions sans entrer dans des dépendances externes avec d’autres CU.
Mais bien sûr, tout cela a été conçu pour sortir le L3 de la puce avec les MCD, alors que se passe-t-il lorsque vous le remettez dans la puce elle-même avec le RX 7600 ? Eh bien, les contrôleurs de mémoire et le processeur de commande doivent être adaptés. Le processeur de commande doit envoyer à l’hôte des interruptions générées par le matériel lorsqu’une commande est terminée, ce qui signifie que le contrôleur de mémoire, qui a accès à tous les périphériques GPU dotés de mémoire, qu’il s’agisse de cache ou de VRAM, doit compenser les adresses de mémoire en fonction des données demandées par l’hôte.
Une modification matérielle qui mélange RDNA 2 et RDNA 3 ?
Compte tenu de ce qui a été dit, et du fait que RDNA 3 est une évolution de RDNA 2, où AMD a cherché à réduire le temps total du Graphics Pipeline pour ne pas augmenter les fréquences, et donc être plus efficace en consommation, nous pensons que le Command Processor et les contrôleurs mémoire sont hérités de RDNA 2 dans cette RX 7600 (au moins).
Pourquoi pensons-nous cela ? Parce que les processeurs de commande ont un accès direct au GDS, au L2, au contrôleur de mémoire et au Dispatch en même temps. Par conséquent, il y a une coordination entre eux et peut-être en impliquant le L3 à l’intérieur du die, le diagramme ci-dessus ne reflète pas bien la réalité du RX 7600, bien qu’il le fasse pour le reste des GPUs MCM.
Ce que nous comprenons, c’est qu’étant donné l’augmentation de performance de l’inclusion du L3 dans le die, quel que soit le niveau d’intégration du MDIA RDNA 3, le fait que le nombre de Float Units ait été augmenté de deux pour obtenir une augmentation de performance de 50% pour un GPR signifie que le Command Processor peut être saturé lorsque trop de Draw Calls arrivent. En d’autres termes, le potentiel et l’amélioration de la réduction de la latence L3 sont là, le potentiel de l’architecture est palpable, mais il est “boiteux”, il n’est pas bien résolu dans une puce monolithique.
En fait, le schéma fonctionnel entre RDNA 3 et RDNA 2 est exactement le même, si l’on fait abstraction de tous les changements survenus dans l’architecture et qui sont plus axés sur la réduction de la latence et l’amélioration du Ray Tracing, ce que nous avons est presque la même architecture, avec peu de changements, un “rehash” comme nous l’avons souligné hier.
Pourquoi ne parvient-il pas à augmenter ses performances dans les jeux ?
Pour deux raisons. AMD a fait dépendre une grande partie de ses performances du pilote, tout comme NVIDIA. Plus précisément, RDNA 3 comprend deux parties :
- Un programme qui s’exécute sur l’hôte.
- Programmes, appelés programmes de shaders et noyaux, s’exécutant sur le GPU RDNA3 en particulier.
Les programmes de RDNA 3 sont contrôlés par un pilote fonctionnant sur l’hôte qui :
- Définit l’adresse interne et d’autres registres de configuration.
- Spécifie le domaine de données dans lequel le GPU fonctionnera.
- Invalide et vide les caches sur le GPU.
- Fait commencer l’exécution d’un programme par le GPU.
Le logiciel est modifiable, le matériel ne l’est pas, de nouveaux modèles de GPU devraient être publiés ultérieurement en tant que “mise à niveau” pour compenser les manques de performance. La dépendance à l’égard des pilotes pour toute la question de l’overhead a été abandonnée avec DX11, le CPU a été autorisé à travailler de manière plus lâche avec DX12, de sorte que les GPU prendraient en charge une grande partie de cette tâche.
NVIDIA a un overhead “reporté” de celui qui implique un overhead sur les anciens processeurs Intel et AMD, précisément en raison de la charge plus élevée de Draw Calls requise pour chaque architecture. En d’autres termes, les processeurs plus anciens souffrent davantage avec un GPU NVIDIA.
Les GPU Radeon sont très dépendants des logiciels AMD, qui, comme vous pouvez le voir dans de nombreuses diapositives, sont déjà très anciens. C’est pourquoi nous voyons dans certaines révisions de pilotes des améliorations à deux chiffres dans certains jeux. Ce n’est rien d’autre qu’une optimisation du pilote par rapport à l’API afin de réduire les frais généraux pour le processeur de commande des architectures RDNA.
Ceci étant expliqué et pour en revenir à la RX 7600, la différence de performance entre les jeux et les benchmarks, 3DMark en particulier, implique deux scénarios différents et opposés : les jeux qui surchargent l’API, c’est-à-dire qui imposent trop d’overhead au pilote, et les benchmarks qui ne le font pas.
C’est pourquoi nous pouvons voir dans toutes les critiques que dans Time Spy ou Fire Strike les différences entre RX 6650 XT et RX 7600 sont beaucoup plus importantes que dans un jeu avec beaucoup de Draw Calls pour le processeur de commande, en particulier dans DX12. Deux exemples : Days Gone, DOOM Eternal ou F1 22 contre Halo Infinite, Cyberpunk 2077 ou Red Dead Redemption 2.
Face à ces jeux, pour peu que le CPU soit suffisamment puissant (évident), on constate que la RX 6650 XT est très proche, voire supérieure à la RX 7600, ou à l’inverse, cette dernière et plus récente bat largement son homologue RDNA 2. Par ailleurs, toutes ces explications que nous vous avons données permettent également d’expliquer un autre phénomène que nous avons tous constaté : la mise à l’échelle des performances en fonction de la résolution.
Plus nous utilisons une résolution élevée, plus nous avons besoin de Draw Calls, en particulier dans Vulkan et DX12. Plus le processeur a de cœurs et de threads, plus il peut envoyer rapidement les appels de dessin au GPU. Par conséquent, plus le matériel est performant, plus le Command Processor d’AMD s’effondre, car la réduction de la latence du cache augmente les performances globales de chaque UC, laissant le CP en plan.
En d’autres termes, l’amélioration du CP pour RDNA 3 par rapport à RDNA 2 est inexistante (au moins sur le RX 7600). Les changements introduits dans le premier pallient la latence du MCD, mais lorsqu’il n’y a pas de MCD et que le jeu fait un usage intensif de l’API, le Command Processor s’effondre et les performances gagnées finissent par être largement perdues, et ce d’autant plus que la résolution augmente.
Les RX 7600, RX 7900 XTX et l’overhead
Bien sûr, vous vous demandez ce que la RX 7900 XTX a à voir avec cette équation ? Et bien, en fait, il y a beaucoup de choses à voir. Elle présente deux particularités par rapport à sa sœur RX 7600 qui sont en quelque sorte liées à tout ce qui précède. Tout d’abord, la puce monolithique contre la puce MCM, c’est-à-dire que le L3 est à l’extérieur dans le MCD, mais aussi, sur le papier et à l’exception de la vitesse VRAM qui est un peu plus élevée dans le plus grand, le RX 7900 XTX est exactement trois fois plus puissant que le RX 7600.
En d’autres termes, prenez une RX 7600 et multipliez toutes ses unités par trois : vous obtenez le triple du nombre de Shaders, le triple du nombre de ROPs, le triple du nombre de TMUs, de bus, de VRAM, de caches etc etc etc. Les principales différences se situent au niveau des fréquences : 20 Gbps contre 18 Gbps pour la VRAM, 2 499 MHz contre 2 625 MHz, et comme il s’agit de la même architecture, on obtient 61,42 TFLOPS contre 21,5 TFLOPS.
Le résultat est de +285% en comparant les TFLOPS, ce qui serait +300% si l’on fait correspondre les fréquences de shaders entre les cartes, curieux n’est-ce pas ? Pas vraiment, non. La RX 7600 est 33.33% d’une RX 7900 XTX, mais la différence de performance entre les deux est de presque 220% en moyenne à 1080p selon les données de TPU review. L’explication, très brève, va dans le sens de ce que nous avons vu ici :
- Overhead.
- Latences du cache L3
- Désactivation partielle des CU en nanosecondes lorsque le taux de FPS est élevé afin de maintenir une faible consommation d’énergie.
En ce qui concerne la consommation d’énergie, la RX 7900 XTX fait pâle figure par rapport à la RTX 4090 à des résolutions plus élevées, car la puissance est privilégiée par rapport aux performances et, en même temps, l’overhead du jeu et l’API du processeur de commande sont augmentés, ce qui commence à remplir le L3 dans une plus large mesure et de plus en plus d’informations sont transmises entre L2 et L3, avec tout ce que cela implique.
En gardant cela à l’esprit, vous pouvez parfaitement voir comment, à des résolutions plus élevées, la RX 7600 commence à chuter, et vous passez de 1080p, 2K et 4K par rapport à la RX 7900 XTX de +217% pour cette dernière à +256% et +311%. Ce n’est pas le cas lorsque l’on compare la RX 7900 XTX à la RX 7900 XT, où les différences sont de 10%, 14% et 18% selon les résolutions, ce qui est logique puisqu’elle a moins d’unités générales (Shaders, TMU, ROP, Cache, bus, etc.) et que plus la charge graphique est élevée, moins elle perd de puissance.
Donc, en résumé, RDNA 3 doit s’améliorer et c’est pourquoi, comme nous le savons maintenant, AMD a parlé en coulisses d’un problème qu’ils ne pouvaient pas résoudre avec le matériel et qui devrait être corrigé pour RDNA 4. Ce qu’ils peuvent faire, c’est s’améliorer avec les pilotes, avec les logiciels, avec les développeurs, où nous pourrions voir des gains intéressants s’ils parviennent à optimiser les Draw Calls.
Donc, dans les slides, AMD a précisé 32 CU RDNA 3 et non pas l’architecture RDNA 3 en tant que telle, ils ont été trop précis, et c’est très étrange étant donné que cela n’avait pas été vu dans le marketing de la RX 7900, pour le moins curieux. Dans tous les cas, les données observées entre DX11 et DX12 / Vulkan montrent une dégradation des performances assez importante et tout porte à croire que la RX 7600 souffre de l’overhead bien plus que ses consœurs.
Enfin, combien de performances la RX 7600 perd-elle à cause de cela ? Eh bien, si l’on considère que la fréquence de test a été abaissée à 1 GHz, à sa fréquence d’origine, nous devrions en fait constater une perte d’environ 10 %, peut-être même plus proche de 13 %. Combien les autres modèles MCM pourraient-ils gagner s’ils n’étaient pas affectés par l’overhead ? Probablement un chiffre à un chiffre, mais en l’absence de données, il est difficile de se rapprocher d’un chiffre. Quoi qu’il en soit, nous avons déjà une explication pour la faible performance de cette carte RX 7600.
