COMPTOIR
  
register

×

rdna2 gains t

Test • AMD Radeon RX 6800 & RX 6800 XT
rdna2 gains t
rdna2 cu t
rdna2 cu capacity t
rdna2 cache hierarchy t
rdna2 infinitycache t
hc t
rdna2 infinitycache2 t

• RDNA2 : Une architecture améliorée

Pour vous aider dans la compréhension des pages à venir, nous vous invitons vivement à lire ou relire, si ce n'est pas déjà fait, celles que nous avions dédiées à RDNA au sein de ce dossier. Cette dernière architecture, est une refonte profonde de la précédente (GCN), avec pour objectif d'améliorer drastiquement les performances par watt. Pour ce faire, AMD a sérieusement revu l'organisation de ses unités de calculs, mais aussi le sous-système mémoire, en particulier la hiérarchie des caches. Pour la seconde itération de cette architecture, les rouges poursuivent dans ce sens avec 3 contributeurs principaux à l'amélioration. Le premier est l'augmentation significative de l'IPC, le second est la réduction de la puissance nécessaire pour atteindre une fréquence donnée ou exécuter certaines tâches, et enfin le dernier consiste à améliorer la capacité à monter en fréquence de l'architecture. Le tout combiné permettrait un gain de 54% au niveau du rapport performances par watt.

 

rdna2 gains t [cliquer pour agrandir]

 

Des unités de calcul boostées

Du côté des unités de calculs, ces dernières sont toujours à l'instar de celles en charge du texturing, organisées au sein de Compute Unit. Ces CU fonctionnent par paire au sein d'un Work Group Processor (WGP), partageant un seul et même accès à la mémoire. La nouveauté par rapport à RDNA première du nom, est l'adjonction d'une unité dédiée à accélérer le traitement du Ray Tracing au sein de chaque CU, et que nous détaillerons un peu plus bas. AMD a également réussi avec RDNA 2, le tour de force d'améliorer de 30% la fréquence de fonctionnement de ses unités de calcul, et ce pour une même puissance absorbée. Il y est parvenu par le biais d'un pipeline graphique optimisé, mais aussi en réduisant les déplacements de données au minimum via une nouvelle hiérarchie des caches que nous détaillerons un peu plus bas, et en adoptant un équilibrage agressif du pipeline graphique. Enfin, la granularité appliquée à l'arbre des fréquences est affinée, conduisant à économiser encore davantage de puissance, en visant des groupes de transistors non sollicités durant certaines opérations et qui conservaient leur fréquence maximale sur RDNA.  

 

rdna2 cu t [cliquer pour agrandir]

 

Les CU progressent également au niveau du jeu d'instructions et fonctionnalités. En sus du Ray Tracing, les Sampler Feedback, Variable Rate Shading et Texture Space Shading font leur apparition (indispensable pour le support complet de DX12 Ultimate), rattrapant ainsi Nvidia qui les supporte depuis Turing. Nous détaillerons tout ceci page suivante. On notera également la prise en charge de précisions de calcul mixtes autorisant des opérations sur tenseurs, appréciées en inférence et donc potentiellement utiles pour un équivalent au DLSS par exemple. Toutefois, contrairement aux verts, AMD opte ici pour l'accroissement des capacités de calcul des unités traditionnelles. Si cette approche est plus économe en transistors, elle risque de se montrer moins performante à l'usage que des unités dédiées proposant des débits plus importants pour des formats particuliers, mais surtout utilisables de concert avec les unités traditionnelles.

 

rdna2 cu capacity t [cliquer pour agrandir]

  

Infinity Cache

Les modifications précédentes remettent à niveau le côté fonctionnel, pour faire de même au niveau des performances, RDNA2 s'appuie en sus de l'augmentation de la fréquence de fonctionnement, sur l'adoption d'une nouvelle hiérarchie des caches, avec l'adjonction d'un troisième niveau, nommé commercialement Infinity Cache. Il dispose d'une capacité totale de 128 Mo et s'intercale logiquement entre le cache L2 et les contrôleurs mémoire. Cet espace supplémentaire très conséquent (32 fois plus que le précédent dernier niveau que constituait le L2 à 4 Mo sur RDNA), va permettre de conserver en mémoire bien plus de données, tant spatiales que temporelles, induisant les avantages que nous détaillerons un peu plus bas. 

 

rdna2 cache hierarchy t [cliquer pour agrandir]

 

AMD explique avoir puisé au sein des équipes ayant développé le cache L3 des CPU Zen, pour travailler de concert avec les architectes GPU et ainsi mettre au point cet Infinity Cache, répondant aux contraintes des GPU modernes. Le premier avantage est l'effet multiplicateur au niveau de la bande passante mémoire. En effet, les données présentes dans l'Infinity Cache, peuvent profiter d'une bande passante jusqu'à 4 fois supérieure aux mêmes données qui ne seraient présentes qu'en mémoire vidéo. Les GPU étant des machines à paralléliser, alimenter efficacement leurs unités de calcul en données est un casse tête sans fin pour les concepteurs. La réponse d'AMD semble donc pour le moins pertinente.

 

rdna2 infinitycache t [cliquer pour agrandir]

 

Mais les avantages de ce généreux cache ne se limitent pas à juste amplifier la bande passante mémoire, lorsque les données stockés sont présentes au sein de ce dernier. Les effets se font aussi sentir au niveau de la latence d'accès, significativement moindre. A cela s'ajoute le gain énergétique, puisqu'une requête au sein de l'Infinity Cache, permet de réduire drastiquement la consommation nécessaire par rapport à la même nécessitant un accès mémoire (rapport de 5 à 6). Qui plus est, la fréquence de l'IC est variable, permettant donc des économies d'énergie lorsque le besoin en bande passante est réduit. AMD indique enfin que son implémentation du Ray Tracing profiterait lui aussi de ce cache de dernier niveau. Quoi qu'il en soit, touts les gains annoncés dépendent grandement de la présence ou non des données requises en cache. AMD précise que d'après ses mesures sur de nombreux jeux en UHD, 58 % des requêtes obtiennent un résultat positif (l'information est présente) au sein de l'IC.  

 

hc t [cliquer pour agrandir]

 

Donc pour exprimer plus clairement l'assertion précédente, dans 6 cas sur 10 lors d'un jeu en UHD (cette proportion est plus élevée avec les définitions moindres), RDNA 2 profitera des avantages de bande passante, latence et consommation correspondant aux accès à l'Infinity Cache. A contrario, dans 4 cas sur 10, il devra faire avec les caractéristiques d'un accès mémoire traditionnel (et probablement d'une petite pénalité en latence du fait d'un niveau de cache supplémentaire, les GPU arrivent cependant à relativement bien à masquer ces latences). Le calcul d'AMD est donc le suivant : utiliser un bus mémoire normalement dévolu pour les séries de cartes inférieures au haut de gamme, économisant ainsi au niveau des budgets transistors et puissance de ce dernier, pour les réaffecter à cet Infinity Cache et générer ainsi un bilan global positif, tant au niveau des performances que de la consommation. Cela permet aussi d'éviter l'association du GPU avec de la mémoire très rapide et donc onéreuse/énergivore, tout en ne bridant pas pour autant le GPU, du fait d'une bande passante insuffisante.

 

rdna2 infinitycache2 t [cliquer pour agrandir]

 

Voilà ce que nous pouvions détailler concernant les évolutions architecturales de RDNA 2, destinées à accroitre les performances. Voyons page suivante ce qu'il en est des fonctionnalités à présent. 




Sur le comptoir, au ~même sujet

 
 
 
 
 
 
 
 
 
 
 
 

Les 168 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
Message de Un #ragoteur connecté en Île-de-France supprimé par un modérateur : C'est sûr qu'avec ce genre de message on va prendre le temps de te satisfaire...
par Ping, le Mercredi 30 Décembre 2020 à 12h47  
Merci pour la màj
par Sarge, le Dimanche 20 Décembre 2020 à 22h41  
par Eric B., le Dimanche 20 Décembre 2020 à 15h33
En fait bien avant, c'est déjà possible sur des architectures comme GCN 1 ou Maxwell. Par contre il faut que la partie logicielle suive tant côté pilotes que de l'API. C'est pourquoi le Multi Engine qu'AMD a nommé commercialement Async Compute, n'a vraiment été utilisé qu'à partir de DX12 / Vulkan. Ensuite, le processeur de commande (assisté des ACE) s'est avéré beaucoup plus efficace sur les architectures AMD que son équivalent chez Nvidia jusqu'à Turing, nécessitant plus de travail des développeurs pour tirer parti de cette fonctionnalité sous peine de perte de performance. On peut ajouter aussi que les gains dépendent des ressources disponibles pour exécuter en parallèle d'autres tâches, donc plus une architecture est efficace (plus elle parvient à solliciter ses ressources en parallélisant l'exécution des instructions demandées) et moins elle aura de gains potentiels à en attendre. Enfin, les API bas niveau étant fortement inspirées par Mantle, elles étaient naturellement enclines à privilégier l'architecture des rouges (GCN) ayant servi de base à ce dernier.
Merci infiniment, pour toutes ces précisions !!!
par Eric B., le Dimanche 20 Décembre 2020 à 15h33  
En fait bien avant, c'est déjà possible sur des architectures comme GCN 1 ou Maxwell. Par contre il faut que la partie logicielle suive tant côté pilotes que de l'API. C'est pourquoi le Multi Engine qu'AMD a nommé commercialement Async Compute, n'a vraiment été utilisé qu'à partir de DX12 / Vulkan. Ensuite, le processeur de commande (assisté des ACE) s'est avéré beaucoup plus efficace sur les architectures AMD que son équivalent chez Nvidia jusqu'à Turing, nécessitant plus de travail des développeurs pour tirer parti de cette fonctionnalité sous peine de perte de performance. On peut ajouter aussi que les gains dépendent des ressources disponibles pour exécuter en parallèle d'autres tâches, donc plus une architecture est efficace (plus elle parvient à solliciter ses ressources en parallélisant l'exécution des instructions demandées) et moins elle aura de gains potentiels à en attendre. Enfin, les API bas niveau étant fortement inspirées par Mantle, elles étaient naturellement enclines à privilégier l'architecture des rouges (GCN) ayant servi de base à ce dernier.
par Sarge, le Dimanche 20 Décembre 2020 à 13h08  
par Eric B., le Dimanche 20 Décembre 2020 à 10h13
Désolé si ça a été un peu long à venir, mais l'accumulation de lancements a dépassé ma capacité de travail pour CDH.
Aucuns soucis, cela me dérange en rien.. de plus, tout le travail que tu fais est juste nickel !!
Cela dit, j'avais juste une question purement informative.. (j'en profite) ) le calcul asynchrone est possible depuis "Pascal" chez Nvidia et "Polaris" chez AMD (je parle des GPUs "tout public" ) ?! Ou j'me trompe ??
par Eric B., le Dimanche 20 Décembre 2020 à 10h13  
par Sarge, le Jeudi 17 Décembre 2020 à 23h01
C'est toujours ce que j'attends le plus ds les dossiers, merci !!
Désolé si ça a été un peu long à venir, mais l'accumulation de lancements a dépassé ma capacité de travail pour CDH.
par Sarge, le Jeudi 17 Décembre 2020 à 23h01  
par Eric B., le Jeudi 17 Décembre 2020 à 17h06
Mise à jour du dossier avec la description de l'architecture.
C'est toujours ce que j'attends le plus ds les dossiers, merci !!
par Eric B., le Jeudi 17 Décembre 2020 à 17h06  
Mise à jour du dossier avec la description de l'architecture.
par Eric B., le Jeudi 10 Décembre 2020 à 09h37  
Infineon XDPE132G5D
par Un #ragoteur sigma delta d'Occitanie, le Mardi 08 Décembre 2020 à 23h19  
Bonjour, est-ce que quelqu'un connaitrait la reference du composant qui fait la gestion des phases d'alimentation sur ces cartes ?
D'avance merci.
par cabou83, le Samedi 28 Novembre 2020 à 20h39  
par Eric B., le Samedi 28 Novembre 2020 à 18h57
Ca n'a pas de sens de comparer des consommations à la prise de configurations différentes. Selon la consommation et la charge induite sur le CPU, tu vas générer un delta plus ou moins important qui t'empêchera toute lecture sérieuse de la consommation GPU.
Sur ses vieille génération effectivement il n'y a pas de capteur de la puissance consommer. Donc on peut juste éventuellement déduire la consommation de la plateforme hors GPU (surtout qu'avec la Vega j'avais la valeur) et environs la plateforme consomme ryzen consomme 100/120w en jeux (ça du à la utilisation de la v64, forcement avec une 280x la charge du 3600 est moindre). Donc c'est pour ça que j'en déduit un tdp de 175w(pour la 280X) pour arrivé au 250w total (prise).
Mais je me souviens très bien qu'a l'époque effectivement à la prise j'arrivais vers les 400w quand les jeux chargeaient bien sur la carte et sur mon vieux FX.
C'est juste un constat, les pilotes ont du faire une opti depuis 2011 vu qu'on a bouffé du GCN pendant presque 8 ans.

Edit: après c'est peut être du justement au faite qu'aujourd'hui les 3Go de VRAM sont saturé donc certaines unités serait "en attente" et donc la carte n'exploite pas son tdp maximum malgré une charge à100%, ça pourrait peut être jouer.
par Eric B., le Samedi 28 Novembre 2020 à 18h57  
Ca n'a pas de sens de comparer des consommations à la prise de configurations différentes. Selon la consommation et la charge induite sur le CPU, tu vas générer un delta plus ou moins important qui t'empêchera toute lecture sérieuse de la consommation GPU.