Avec la standardisation du ray tracing au sein de Vulkan, les jeux spécifiquement développés pour les GeForce RTX de NVIDIA s'ouvrent peu à peu aux nouvelles Radeon d'AMD.
Chaque année, AMD met en ligne une nouvelle version majeure de ses pilotes, riche en nouveautés. Tout du moins, c'était le cas jusqu'en 2019. Cela n'a pas eu lieu en 2020, la société s'étant concentrée sur l'arrivée de ses Radeon RX 6000. Hier, une nouvelle mouture a été mise en ligne, là encore avec peu de changements.
En effet, il est surtout question de corrections de bugs. Les notes de version évoquent également des gains de performances dans Hitman 3. Mais on retiendra surtout le support de Quake II RTX. La version retravaillée du jeu peut désormais fonctionner sur les dernières Radeon en profitant du ray tracing via Vulkan.
S'agissant d'un rendu exploitant complètement cette technologie, plutôt que pour certains éléments (ombres, lumières), il sera intéressant de comparer les performances et la qualité d'images avec les dernières GeForce.
Commentaires (12)
#1
Comme dit dans l’article, il sera vraiment intéressant de voir la différence avec les GeForce. De ce que j’ai entendu, l’implémentation d’AMD serait moins bonne, mais cela demande confirmation.
#2
Prérequis : avoir une radeon rx6000 …
j’dis ça, j’dis rien (LDLC ne faisant plus parti de ma liste de fournisseurs)
#3
En performance pure (benchmark) en full raytracing les carte AMD sont plus proches d’une série 20 que d’une série 30 à priori selon différent tests.
Ca a été observé sur Quake II RTX là , mais ça ne fait que confirmer ce qui avait déjà été remarqué sur Minecraft RTX .
Cependant, dans des rendus hybrides, tessellation+raytracing, tant que les effets de raytracing sont légers, les cartes AMD s’en sorte bien mais dès que ça tire un peu plus, ça s’effondre (ici Dirt 5 contre Ghostrunner)
Cependant, j’aimerai voir une comparaison visuelle. En effet le raytracing nécessite en particulier une phase de dé-bruitage. Chez NVidia, il me semble que c’est réalisé par des réseaux de neurones via les tensor core, or NVidia a quelques années de compétence dans ce domaine. De l’autre, je ne sais pas trop comment fait AMD (surement aussi du réseau de neurone, et directement sur les core qui servent aussi à la tessellation).
#4
pas sûr que ce soit possible de faire tourner le réseau de neurone sur les cores de tesselation je dirais que c’est fait purement en soft donc il faudrait surveiller l’utilisation cpu pour savoir.
#5
Tu peux faire tourner des réseaux de neurone sur des carte graphique sans passer par les tensor core.
Aujourd’hui, les cartes graphiques possèdent une capacité de calculs générique. Tu peut l’utiliser via la bibliothèque générique OpenCL, ou par les bibliothèques spécifique à chaque carte : CUDA (et toutes la famille) pour NVidia, et ROCm pour AMD.
Pour comprendre l’intérêt d’une carte graphique, il faut voir comment ça fonctionne. Le but d’une carte graphique, c’est que pour pouvoir générer un rendu, il faut appliquer la même série d’opération à chaque pixel du rendu. Une carte graphique est donc capable de faire la même opération un grand nombre de fois en parallèle. En gros, elle est construite pour faire des opération sur des tableaux. Mais il y a des mecs qui ont trouver ça bien, si on arrive à représenter des données sous la forme de tableaux, bingo, c’est plus rapide que sur CPU. C’est le début du GPGPU, du calcule sur GPU. (par exemple, le minage de bitcoin, ça consiste à générer nombre, d’appliquer le hashage et de tester si la valeur hash correspond au critère pour que le bloc soit valide : une carte graphique permet de faire ça mais par paquet en parallèle)
De l’autre coté, un réseau de neurone, c’est pratiquement uniquement des opérations sur des matrices (plus exactement des des tenseur : en gros des tableau à N dimension). C’est exactement le type de calcul qu’une carte graphique est doué. C’est justement car les cartes graphiques avait cette capacité générique de programmation, que les réseaux de neurones ont émergé, sur CPU, ça aurait été beaucoup trop long. Les tensor core (et autre TPU) sont apparu que bien plus tard et généralement, ce genre d’unité est généralement un circuit ultra spécialisé pour un calcul (l’opération “Fused multiply–add” D<=A.B+C) qui est la principale opération dans les réseaux de neurones, mais pas la seul. Il y a donc toujours besoin d’un peu de puissance de calculs en plus.
#6
merci pour ta réponse détaillée j’en demandais pas tant
Question subsidiaire je croyais que les calcul cpu avaient une meilleure précision de calcul c’est pour ça qu’il y a encore des calculs fait sur cpu uniquement n’est ce pas l’intérêt des tensors cores d’avoir plus de précisions justement pour ces calculs d’ia ou je mélange tout ?
#7
Bonjour à tous,
je comprends pas bien à quoi ça sert de supporter un jeu qui à plus de vingt ans ?
Ou j’ai raté quelque chose là.
Merci par avance de vous éclaircissements, car pour moi quake date d’un autre âge non ?
Cdt.
#8
Ce n’est pas le Quake 2 d’époque mais une réécriture pour mettre en avant la techno du ray-tracing. Quake 2 était à l’époque déjà une sorte de mètre étalon de la technologie 3D, c’est un clin d’oeil à ça que d’avoir choisi à nouveau ce jeu.
Bref c’est juste une “démo” pour le RT.
#9
Les tensor core ne sont pas fait pour être plus précis. Le CPU a plein d’avantage par rapport au GPU.
l’intérêt d’un tensor core, c’est de faire un type de calcul (le “Fused multiply–add”) central dans les réseaux de neurones très très vite. C’est un circuit qui fait matériellement du parallélisme.
Dans le cadre des réseaux de neurone, de nombreuse études ont montrer que la précision n’était pas important. Il est au contraire très souvent intéressant de travailler avec des représentation numérique moins précise : on arrive à des résultats assez proche, en prenant moins de temps. Des représentations spécifiques comme le TF32 et le bfloat16 ont été même crée pour l’occasion.
A la base, le boulot pour la 3D ne nécessite pas une grande précision au pire ça fera une petit glich visuel qui n’a pas beaucoup d’impact. Les cartes graphique grand public ne sont pas taillé pour ce genre de boulot, et les capacité des cartes graphique à faire du FP64 sont généralement assez faible par rapport à la puissance qu’elles ont en FP32. Sans compter que sur ces cartes là, il n’y a aucun système de correction d’erreur de la mémoire (ce qui arrive de temps en temps)
Donc, les tensor core, même s’il est possible de faire du FP64 sur la dernière génération (Ampère/série 30), ne sont pas adapté pour faire du calcule précis.
Le CPU, c’est un directeur de thèse avec son doctorant, le directeur de thèse donnes ses instructions au doctorant, ce dernier réalise l’opération demander, un CPU multi-core c’est une équipe de recherche, avec plusieurs couple directeur/doctorant chacun étant indépendant. Un GPU, c’est une école primaire, chaque professeur va donner la même instruction à une classe d’élève, tout au plus, on peut demander aux élèves de travailler sur une ligne différente de son voisin.
Un CPU est beaucoup plus performant lorsque l’on souhaite faire une seul suite d’opération. Cependant, si cette suite d’opération doit être répété un grand nombre de fois pour plusieurs valeurs différentes, le GPU peut se montrer comme intéressant. Un CPU est bien meilleurs pour tout ce qui est “embranchement” dans le code (conditionnelle et boucle) là ou sur un GPU, il faut considérer que toutes les opérations doivent être faites dans toutes les branche parallèle. Ensuite, il faut comprendre que pour faire une opération sur un GPU, il faut beaucoup de communication :
Codé sur GPU nécessite des bibliothèque externe, c’est donc bien plus difficile. A ceci il faut voir que c’est souvent assez brut et le GPU nécessite de faire beaucoup d’opération à la main (comme la gestion de la mémoire). Il y a plein d’autre raison de ne pas codé sur GPU. Si ce que tu veux faire ressemble à un document Excel de milliers de lignes, colonnes, autre dimension… il est possible d’envisager d’utiliser un GPU.
Le CPU est bien meilleurs sur de nombreux point par rapport au GPU. De manière général, le CPU est plus puissant pour effectuer une série de calculs sur une seul seule valeur, là où le GPU va être plus adapté sur un tableau de valeur. Il est aussi plus facile à programmer, par exemple faire une boucle, une conditionnelle… pour l’instant, Il y a aussi tout ce qui est accès mémoire et le fait que le GPU a besoin du CPU pour lui donner les instructions.
#10
merci beaucoup c’est plus clair maintenant
#11
Je rejoins l’avis de ashlol, c’était très intéressant, merci.
#12
Merci beaucoup.
Je reviens sur des points où j’ai été assez rapide.
Il est possible de classer les “processeurs” selon la taxonomie de Flynn.
Maintenant je reviens sur mon histoire de couple directeur de thèse/doctorant, professeurs/élèves. C’est une références à l’architecture de Von Neumann et en particulier au couple Unité de contrôle/Unité arithmétique et logique. L’idée est que dans un cœur de CPU, il y ait une partie du circuit qui est le chef d’orchestre, il sait lire une instruction et sait comment la faire exécute, qui doit faire quoi dans la bonne séquences (quel bus ouvrir, quelle sous-instructions à donnée à chaque composant et dans quel ordre) : c’est l’unité de contrôle. A coté, il y a une partie du circuit qui est capable d’exécuter tout un tas d’opération mathématique et qui sera commandé par l’unité de contrôle : cette calculatrice c’est l’unité arithmétique et logique.
Dans le cas d’un CPU mono-cœur, c’est directement cette architecture qui est utilisé. Dans le cas d’un CPU multi-cœur, on duplique juste ça pour chaque cœur. Cependant, dans le cas d’un GPU,l’idée est plutôt d’avoir plusieurs blocs (Streaming Multriprocessor/SM chez Nvidia) contenant qu’une seule unité de contrôle, mais plusieurs unité arithmétique et logique (en grande partie représenté par les CUDA core chez NVidia). Généralement, sur les GPU, les Unité arithmétique et logique sont assez limité en terme d’opération possible (les CUDA core sont ainsi épauler d’autre unité pour certaine instruction plus complexe comme les opérations trigonométriques ou la racine carrée inverse et le “Fused multiply–add” des tensor core). Un GPU est donc plus un assemblage de multiple architecture SIMD (d’où la similarité avec une école primaire : il y a plusieurs classes).
Mais on n’a pas fini et il reste un point : le SIMD sur les CPU. En effet, vous avez peut-être entendu parler des instruction SSE et AVX (et toutes les évolutions) des processeur X64 (il existe a priori des équivalent sur ARM) ? Ce sont des instructions spéciales qui permettent de faire en une seul fois la même opérations sur plusieurs valeurs. C’est certes moins efficaces (en terme de calculs à la seconde) que ce qu’est capable de faire un GPU, mais sans le coût des transferts entre les mémoires. C’est pour cette raison que CPU n’est pas en reste lorsqu’il faut faire des calculs sur des tableaux de tailles raisonnables.