GeForce RTX 30 Series (Ampere) : NVIDIA précise comment il a doublé la performance FP32

Avec deux fois plus d'unités
GeForce RTX 30 Series (Ampere) : NVIDIA précise comment il a doublé la performance FP32

Quelques jours après l'annonce de ses nouvelles GeForce RTX, NVIDIA commence à en livrer les secrets. Alors que l'on attend toujours le document détaillant l'implémentation grand public de l'architecture Ampere, de premiers secrets commencent à être dévoilés. Notamment sur la puissance de calcul.

Nous l'avons vu lors de l'annonce des nouvelles GeForce RTX 3070, 3080 et 3090, malgré deux années de rumeurs continues et autres fuites, de nombreuses prédictions sont tombées à côté de la plaque. Du traversal coprocessor, aux 5 376 CUDA Cores (le produit de 21 par 256) en passant par la gravure en 7 nm, presque tout était faux.

Ampere cachait de nombreux mystères

Mais il y a un secret mieux gardé que les autres par le constructeur, à l'origine de la surprise de beaucoup sur le rapport performances/prix ou l'efficacité énergétique d'Ampere : c'est son aspect « bi-GPU by design ». Comprendre que le constructeur a presque doublé le nombre de CUDA Cores par rapport à la génération précédente.

GeForce RTX 30 Series Ampere

Certes, le passage de 12 nm à un process en 8 nm signé Samsung (préféré au 7 nm de TSMC en raison de son coût et de sa disponibilité) aide. Mais cela ne suffit pas à expliquer ce résultat. Certains ont même remis en cause ici ou là la véracité des chiffres annoncés, qui ont de quoi faire rêver : 20, 30 et 36 TFLOPS de puissance de calcul.

Comme nous le rappelions dans notre précédent article sur les performances en rendu 3D d'Ampere, la GeForce RTX 2080 annonçait 10,1 TFLOPs contre 13,6 TFLOPS pour la 2080 Ti et 16,3 TFLOPS pour la Quadro RTX 8000.

Doubler la puissance de calcul, mais pas toutes les unités

Pourtant, le discours de NVIDIA était clair pour qui sait tendre l'oreille : le nombre d'unités FP32 a été doublé. Celles en charge du calcul sur les flottants de 32 bits, essentielles dans le domaine des jeux vidéo. Moins que d'autres, en charge des calculs sur les entiers (INT) ou les fonctions mathématiques spéciales (SFU).

La solution était donc forcément là : une modification de l'équilibre au sein des Streaming Multiprocessors (SM). Notre pari était que NVIDIA avait trouvé un moyen de doubler le nombre de FP32, les fameux CUDA Cores, à moindres frais. Sans forcément faire de même avec le reste de l'architecture. C'était l'explication la plus logique.

TuringTuringTuring avait introduit l'exécution concurrentielle entre les unités FP32 et INT32, Ampere double les unités FP32

L'équipe de NVIDIA vient de le confirmer au sein d'un AMHA organisé sur Reddit :

« Les SM d'Ampere intègrent un nouveau design des datapaths pouvant gérer les opérations FP32 et INT32. L'un consiste en 16 CUDA Cores FP32 par partition capables de gérer 16 instructions FP32 par cycle d'horloge. L'autre 16 CUDA Cores FP32 et 16 Cores INT32.

Ainsi, chaque SM d'Ampere peut traiter 32 instructions FP32 par cycle ou 16 FP32 et 16 INT 32 par cycle. Chaque combinaison de 4 SM peut traiter 128 instructions FP32 par cycle, soit le double de Turing, ou 64 FP32 et 64 INT32. »

Ainsi, c'est bien le nombre d'unités FP32 qui a été doublé et seulement lui, sans qu'il en soit de même avec les INT32. On manque de détails sur la granularité de la chose. À quel point sera-t-il possible de mixer des instructions FP32 et INT32 dans le datapath capable de gérer les deux en complément de celui exclusivement FP32 ?

Il sera aussi intéressant de voir comment le reste de l'architecture a été adaptée. NVIDIA évoque un cache L1 doublé (passant de 116 Go/s de débit L1 à 219 Go/s). Chaque GPC a également droit à deux partitions de 8 ROP, le double de Turing. Ce malgré le fait que l'interface mémoire n'évolue pas.

Le constructeur devrait livrer toutes les clés de l'architecture avant le 14 septembre. On en saura plus alors.

Quantité de mémoire, DLSS 2.1, NVENC/NVDEC

Cet échange n'a pas été l'occasion que de parler de la puissance de calcul des nouvelles GeForce RTX. On apprend également que les 10 Go de GDDR6X ont été jugés largement suffisant pour la RTX 3080 et le jeu en 4K :

« Si vous regardez Shadow of the Tomb Raider, Assassin’s Creed Odyssey, Metro Exodus, Wolfenstein Youngblood, Gears of War 5, Borderlands 3 and Red Dead Redemption 2 sur cette définition avec cette carte, aux réglages à leur maximum (dont les packs de texture haute définition) avec RTX quand le jeu le supporte, vous êtes dans les 60 à 100 ips avec 4 à 6 Go de mémoire utilisée ».

De fait, les modèles avec 16 Go ou plus de mémoire sont en général pensés pour « attirer le larron » avec un argument marketing facile à afficher en gros sur la boite, qui trouve sa justification dans les applications professionnelles plus que dans les jeux, même de dernière génération. Mais c'est souvent assez efficace.

On s'attend d'ailleurs à ce qu'AMD propose son Big Navi (2X, RDNA2) avec 16 Go de mémoire. NVIDIA lui répondra-t-il alors avec une RTX 3080 Super 20 Go ? Nous verrons en temps voulu.

On apprend également que DLSS passe en version 2.1 avec le support de la 8K et une option de scaling x9, capable de gérer la VR. La définition de l'image calculée peut aussi être modifiée à la volée dans un mode adaptatif. Le SDK a été mis à jour, comme d'autres outils à destination des développeurs.

L'équipe confirme l'information donnée dans ses fiches techniques sur la partie multimédia : le moteur de compression vidéo NVENC (7e génération) est inchangé par rapport à Turing. Celui de décompression (NVDEC) passe à la 5e génération pour le support d'AV1. HDMI 2.1 (à 48 Gb/s) et DP 1.4a sont supportés.

57 commentaires
Avatar de antivirus Abonné
Avatar de antivirusantivirus- 03/09/20 à 12:02:34

Peut-être juste dommage que NVENC lui ne supporte pas AV1. 😔

Avatar de Iryngael Abonné
Avatar de IryngaelIryngael- 03/09/20 à 12:02:47

Curieux de voir le ratio de puissance DP/SP. Depuis le temps qu'ils le baissent à 1/16 voire 1/64.
Histoire de voir si le GPGPU pourra etre utile sur des projets comme F@H ou un des nombreux projets de Boinc.

Et bien sur les vrais tests in-game INdépendants !

Avatar de tazvld Abonné
Avatar de tazvldtazvld- 03/09/20 à 12:15:17

Donc en gros, si j'ai bien compris les unité "int32" sont maintenant des unité mixte "FP32/int32" au besoin. Mouai, pourquoi pas, je ne vois pas forcément toutes les conséquences que ça peu avoir (en bien, ok, ça augmente les TFLOPS, mais derrière ?).

Avatar de Magyar Abonné
Avatar de MagyarMagyar- 03/09/20 à 12:25:12

Donc si je comprends bien, maintenant les data peuvent emprunter 2 chemins : soit FP32 + INT32, soit FP32 + FP32.
Ma question, si on sait que les FP32 sont si important pour le JV, pourquoi ne pas avoir enlever des INT32 pour les remplacer par des FP32 avant ? C'était pas possible de faire des SM avec que des unités FP32 ?

Avatar de David_L Équipe
Avatar de David_LDavid_L- 03/09/20 à 12:49:08

(quote:49488:antivirus)
Peut-être juste dommage que NVENC lui ne supporte pas AV1. 😔

Chaque chose en son temps ;) C'est déjà pas mal de gérer AV1 en décompression (Intel le fait aussi avec Tiger Lake). Personne ne le fait en compression hardware à ma connaissance, à part des puces spécialisées.

(quote:49489:Iryngael)
Curieux de voir le ratio de puissance DP/SP. Depuis le temps qu'ils le baissent à 1/16 voire 1/64. Histoire de voir si le GPGPU pourra etre utile sur des projets comme F@H ou un des nombreux projets de Boinc.Et bien sur les vrais tests in-game INdépendants !

Le FP64 n'est pas la priorité sur le marché GeForce. Y'a Quadro et Ampere A100 (avec des unités dédiées) pour ça. Mais on verra ce qu'il en est ici :chinois:

(quote:49490:tazvld)
Donc en gros, si j'ai bien compris les unité "int32" sont maintenant des unité mixte "FP32/int32" au besoin. Mouai, pourquoi pas, je ne vois pas forcément toutes les conséquences que ça peu avoir (en bien, ok, ça augmente les TFLOPS, mais derrière ?).

Comme dit dans l'article, Turing c'était déjà INT32+FP32, l'une des nouveautés de l'archi c'était justement de pouvoir mixer les deux au sein d'un même cycle, là où Pascal faisait l'un ou l'autre. Ce qu'Ampere ajoute, c'est le fait de pouvoir traiter 16 instructions FP32 de plus dans un même cycle (par portion de SM).

Le INT32 est moins important mais toujours nécessaire. D'où le pari d'augmenter le déséquilibre entre les deux (qui semble payant, mais on verra lors des tests). Ce qui sera intéressant, au regard d'une question précédente, c'est que ce doublement des FP32 permettra pour les calculs de type FP64.

Avatar de game1337 Abonné
Avatar de game1337game1337- 03/09/20 à 13:29:29

Flight simulator utilise déjà plus de 9 Go de VRAM sans mod alors à mon avis leur raisonnement est un peu juste ... ( https://www.guru3d.com/articles_pages/microsoft_flight_simulator_(2020)_pc_graphics_performance_benchmark_review,4.html)

Avatar de tazvld Abonné
Avatar de tazvldtazvld- 03/09/20 à 13:29:30

(quote:49495:David_L)
Chaque chose en son temps ;) C'est déjà pas mal de gérer AV1 en décompression (Intel le fait aussi avec Tiger Lake). Personne ne le fait en compression hardware à ma connaissance, à part des puces spécialisées.Le FP64 n'est pas la priorité sur le marché GeForce. Y'a Quadro et Ampere A100 (avec des unités dédiées) pour ça. Mais on verra ce qu'il en est ici :chinois:Comme dit dans l'article, Turing c'était déjà INT32+FP32, l'une des nouveautés de l'archi c'était justement de pouvoir mixer les deux au sein d'un même cycle, là où Pascal faisait l'un ou l'autre. Ce qu'Ampere ajoute, c'est le fait de pouvoir traiter 16 instructions FP32 de plus dans un même cycle (par portion de SM).Le INT32 est moins important mais toujours nécessaire. D'où le pari d'augmenter le déséquilibre entre les deux (qui semble payant, mais on verra lors des tests). Ce qui sera intéressant, au regard d'une question précédente, c'est que ce doublement des FP32 permettra pour les calculs de type FP64.

Pour re-résumer de ce que je comprend (je me base sur le schéma de Turing) :

  • dans Pascal, un SM était composé de 2 "block" de 16 cores, un block avec 16 (cuda) cores FP32, et un autre avec 16 cores Int32. Mais seul l'un ou l'autre pouvait être utilisé à un instant donnée
  • dans Turing, il etait possible d'utiliser ces 2 blocks en même temps (concurrent exécution)
  • dans Ampère, le block avec 16 cores Int32 a été remplacer par un bloc 16 FP32+16 Int32 qui peux alors être utilisé soit en Int 32 soit en FP32 tout en gardant l'execution concurrent avec l'autre block de 16 cores FP32 (au final, ça ressemble à du Pascal dans du Turing)

FP64, est-ce que ça a une autre utilité que du calculs scientifiques sur GPU (et encore, faut-il avoir besoin d'une telle précision) ? Pour les usages pros, ça sera plus du coté des Quadro qu'il faudra je pense regarder. Il faut bien que cette gamme ait un intérêt pour pouvoir les vendre 2 à 4 fois plus cher.

Avatar de Paraplegix Abonné
Avatar de ParaplegixParaplegix- 03/09/20 à 13:36:17

Intéressant comme explication. Le GPU est donc capable de moduler les pipe INT32+FP32 en fonction de la charge. Ce qui explique le "doublement" des Cuda cores. Même si on pourrais plus parler de 5248 Cuda core "dédié" + 5248 Cuda core "convertible" étant donnée qu'en fonction du cas d'utilisation tu n'aura pas vraiment 10428 Cuda core de dispo. Si c'est bien ça, c'est un jolie boost de perf et d'utilisation maximum des capacités de la carte qui est fait !
Pour la granularité, je pense que ça sera au niveau d'un cycle. Dans le whitepaper de l'A100, il disent qu'ils sont capables de charger des opérations INT32 pendant que des opérations FP32 sont entrains d'être traitées (Page 34)

Du coup les workload purement FP32 ça doit dépoter :perv:

Édité par Paraplegix le 03/09/2020 à 13:37
Avatar de Traffy INpactien
Avatar de TraffyTraffy- 03/09/20 à 13:37:29

"FP64, est-ce que ça a une autre utilité que du calculs scientifiques sur GPU (et encore, faut-il avoir besoin d'une telle précision) ?"

Oui, on peut avoir besoin de ce genre de précision pour du calculs scientifiques. Par exemple, pour éviter l'adimensionnement des variables (qui ont une petite tendance à faire denormals) ou encore lors d'opération de réduction avec la sommation pour réduire faire en sorte que les erreurs d'arrondis reste loin loin des bits significatifs.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 03/09/20 à 13:43:51

(quote:49498:game1337)
Flight simulator utilise déjà plus de 9 Go de VRAM sans mod alors à mon avis leur raisonnement est un peu juste ...

Oui on a aussi des remarques du genre "Oui mais Windows il gère tant de RAM donc..." mais en réalité c'est plus complexe que ça (sans parler du fait que les relevés de consommation mémoire ne sont pas toujours très précis). Surtout dans le cas de FS 2020, qui a bien d'autres problèmes à régler en termes d'opti/perf que celle de la mémoire GPU.

Après tu peux penser qu'une carte avec 16 Go plutôt que 8 Go irait 2x plus vite. Comme dit dans l'article, c'est un argument faible du marketing, courant chez les constructeurs de GPU, qui marche bien auprès de leur public, quel que soit la réalité des choses. Regarde le positionnement perf de la Radeon VII pour le comprendre.

Mais s'il y a des cartes d'un niveau équivalent l'une avec plus de mémoire que l'autre, on testera dans FS2020 et quelque chose me dit que la différence de performances ne se fera pas sur la quantité de mémoire disponible.

(quote:49499:tazvld)
Pour re-résumer de ce que je comprend (je me base sur le schéma de Turing)...

Pas exactement, mais on en reparlera bientôt plus en détails. Ce qu'il faut retenir d'Ampere, c'est qu'il y a bien un doublement de la puissance de calcul FP32 (via deux datapath différents. Elle est juste décorrélée de celle en INT32, ce qui est l'une de ses nouveautés.

En ce sens, Ampere est la continuité de Turing qui a introduit la séparation INT32/FP32 pour permettre le concurrentiel. Il ne faut jamais oublié qu'il n'y a pas de vrai saut technologique dans le vide, il y a toujours un cheminement logique d'une architecture à l'autre. C'est le cas ici.

Pour la version A100 serveur, NVIDIA a misé sur le renforcement du calcul FP64, sur le grand public sur FP32. On verra ce que NV propose en ratio entre les deux dans les versions GeForce/Quadro, vu que ces produits visent pour une partie des usages où le calcul à grande précision est important.

(quote:49500:Paraplegix)
Intéressant comme explication. Le GPU est donc capable de moduler les pipe INT32+FP32 en fonction de la charge. Ce qui explique le "doublement" des Cuda cores.

Non le concurrentiel était une nouveauté de Turing. Ampere ajoute juste des unités pure FP32 en plus.

(quote:49500:Paraplegix)
Même si on pourrais plus parler de 5248 Cuda core "dédié" + 5248 Cuda core "convertible" étant donnée qu'en fonction du cas d'utilisation tu n'aura pas vraiment 10428 Cuda core de dispo.

Il faudra faire pareil sur Turing du coup et on en reviendrait donc au même : Ampere sait traiter deux fois plus de FP32 que Turing, au pire ils sont à niveau égal, mais il n'y a pas de parité INT32/FP32 dans les workloads typiques, ce que montrent bien les résultats des tests.

Édité par David_L le 03/09/2020 à 13:48
Il n'est plus possible de commenter cette actualité.
Page 1 / 6

2000 - 2020 INpact MediaGroup - SARL de presse, membre du SPIIL. N° de CPPAP 0321 Z 92244.

Marque déposée. Tous droits réservés. Mentions légales et contact