COMPTOIR
register

×

Exécution concomitante flottants et entiers

Test • NVIDIA GeFORCE RTX 2060 & 2070 SUPER
Exécution concomitante flottants et entiers
Turing en chiffres
TU106 configuration RTX 2060 SUPER
TU104 configuration RTX 2070 SUPER
GPU Boost 3.0
GPU Boost 4.0

• Turing

Pour ceux intéressés par l'architecture Turing, nous vous invitons à lire ou relire le dossier que nous lui avons consacré il y a quelque temps. Résumée en quelques lignes, cette dernière ressemble beaucoup à Volta avec quelques ajouts. Par rapport à Pascal (gaming) : des caches plus gros et plus rapides, des SM "plus petits" mais plus nombreux et capables de traiter en parallèle les calculs sur entiers ou en virgule flottante (y compris en demi-précision (FP16) à double vitesse).

 

Exécution concomitante flottants et entiers [cliquer pour agrandir]

 

Voilà pour la partie "classique" de l'architecture, NVIDIA a complété cette dernière par des Tensor Cores, accélérant significativement les calculs liés à l'intelligence artificielle, en particulier l'inférence, ainsi que les RT Cores, dédiés à l'accélération matérielle (des calculs d'intersection rayons / triangles) du Ray Tracing, utilisable en temps réel dans les jeux via un rendu hybride, mixant cette technique à une base rastérisation.  

 

Turing en chiffres [cliquer pour agrandir]

Turing en chiffres dans sa déclinaison dédiée à la RTX 2080 Ti

 

Mais ces nouvelles fonctionnalités sont loin d'être gratuites en termes de "coût transistors", avec pour conséquence des dies pour le moins imposants du fait de la stagnation du procédé de gravure utilisé, et donc onéreux à produire, vu la réduction du nombre de GPU par Wafer (disques en silicium sur lesquels sont gravés les puces).

 

 

• TU104 & TU106

NVIDIA a conçu à partir de sa dernière architecture, cinq GPU, dont 2 privés des fonctionnalités d'accélération RT et IA, qui se retrouvent au sein des GTX 16xx, le préfixe rappelant l'absence des nouvelles fonctionnalités. Vous retrouverez ci-dessous un résumé des différents GPU utilisés sur les GeForce série 10, 16 et 20, nous avons abrégé la série SUPER avec un S .

 

Cartes
GPUNombre de transistorsSuperficie Die

Densité (Millions de transistors / mm²)

GeForce RTX 2080 Ti TU102 18,6 Milliards 754 mm² 24,7
GeForce RTX 2070S/80/80S TU104 13,6 Milliards 545 mm² 24,9
GeForce RTX 2070/60/60S TU106 10,8 Milliards 445 mm² 24,3
GeForce GTX 1660 (Ti) TU116 6,6 Milliards 286 mm² 23,1
GeForce GTX 1650 TU117 4,7 Milliards 200 mm² 23,5
GeForce GTX 1080 Ti GP102 12 Milliards 471 mm² 25,5
GeForce GTX 1080/70 (Ti) GP104 7,2 Milliards 314 mm² 22,9
GeForce GTX 1060 GP106 4,4 Milliards 200 mm² 22
GeForce GTX 1050 (Ti) GP107 3,3 Milliards 132 mm² 25

 

Quid de la RTX 2060 SUPER plus précisément ? Le modèle d'origine s'appuyait sur un TU106 dont 2 contrôleurs mémoire 32-bit avaient été désactivés (entraînant la désactivation d'un Mo de cache L2 et 16 ROP) ainsi que 6 SM. Ci-dessous, vous retrouverez une représentation schématique du TU106 "version" RTX 2060 SUPER :

 

TU106 configuration RTX 2060 SUPER [cliquer pour agrandir]

 

Elle hérite cette fois d'un GPU ne souffrant que de la désactivation de 2 SM, le bus  mémoire étant de son côté intégral (256-bit). De quoi proposer une carte très proche de la RTX 2070 originelle, cette dernière ne conservant que 2 SM supplémentaires. Voici résumées les principales caractéristiques de son GPU dans le tableau ci-dessous et les désactivations opérées.

 

GeForce GTX 2060 SUPERQuantité activéeQuantité Présente
GPC 3 3
TPC / SM 17 / 34 18 / 36
CUDA Cores 2176 2304
TMU 136 144
Tensor Cores 272 288
RT Cores 34 36
ROP 64 64
L2 (Mo) 4 4
Bus mémoire (bits) 256 256

 

A présent, attardons-nous sur sa grande sœur, la RTX 2070 SUPER. La version lancée fin 2018 utilisait un TU106 intégral, il n'était donc pas possible de faire beaucoup mieux à process inchangé (une version disposant de fréquences plus élevées aurait du mal à justifier un tel suffixe). Qu'à cela ne tienne, NVIDIA utilise à présent un TU104 que l'on retrouvait uniquement sur la RTX 2080, mais dans une configuration moins performante toutefois. On obtient donc une série 70 plus "traditionnelle", partageant son GPU avec la série 80, cela lui ouvre d'ailleurs la porte du multiGPU. Quid des détails ? 

 

TU104 configuration RTX 2070 SUPER [cliquer pour agrandir]

 

En fait, ce sont pas moins de 8 SM (4 TPC) qui sont désactivés. Cette quantité correspond à un GPC, tel que nous l'avons représenté schématiquement en modifiant le diagramme de TU104. NVIDIA précise toutefois que cette configuration ne sera pas forcément celle retenue, selon les parties défectueuses au sein du die, les 6 GPC peuvent ainsi être conservés avec plus ou moins de SM actifs en leur sein. Si un GPC est toutefois désactivé, cela entraînera la perte d'un moteur de rastérisation, toutefois, l'impact au niveau des performances devrait être très mesuré (comme nous l'avions constaté sur les GTX 780 pouvant disposer elles-aussi d'un nombre variable de GPC actifs). Résumées ci-dessous, les caractéristiques principales de cette RTX 2070 SUPER. 

 

GEFORCE RTX 2070 SUPERQUANTITÉ ACTIVÉEQUANTITÉ PRÉSENTE
GPC 5 ou 6 6
TPC / SM 20 / 40 24 / 48
CUDA Cores 2560 3072
TMU 160 192
Tensor Cores 320 384
RT Cores 40 48
ROP 64 64
L2 (Mo) 4 4
Bus mémoire (bits) 256 256

 

A noter que la RTX 2080 n'utilisant pas un TU104 complet (2 SM désactivés), il est plus que probable que la version SUPER qui sera détaillée ultérieurement, le fasse cette fois. Couplé à des fréquences plus élevées du GPU et de la mémoire (NVIDIA annonce 15 Gbps), ainsi qu'une enveloppe thermique en hausse pour laisser tout cela s'exprimer, on peut imaginer un gain d'une dizaine de pourcents par rapport à la première édition (ou "non SUPER" si vous préférez).

 

 

• GPU Boost

Ce mécanisme a pour objectif de pousser chaque puce au plus près de ses limites, en s'affranchissant de tests trop sélectifs en sortie de production. C'est en effet GPU Boost qui est chargé par la suite, de s'assurer que les conditions environnementales permettent au GPU de fonctionner de manière stable et sans risque. Pour ce faire, il impose un double carcan constitué d'une limite de consommation et de température selon l'itération. Avec la version 3 introduite lors du lancement de Pascal, à partir de 37°C et tous les 5°C supplémentaires, le GPU perd 1 bin (~13 MHz) et ce jusqu'à la consigne de température maximale. Il perd alors autant de bins que nécessaire pour rester sous celle-ci.

 

La fréquence progressant de concert avec la tension d'alimentation du GPU, c'est un moyen très efficace pour contrôler la consommation (qui évolue au carré de la tension et dispose aussi de sa propre limite), évitant ainsi une envolée des nuisances sonores, avec un refroidisseur pas forcément dimensionné pour la dissiper discrètement à fréquence maximale durant une charge soutenue, ce qui est le cas des Founders Edition à turbine. Le souci d'une telle approche, est la pénalisation de toutes les cartes Pascal, y compris les customs des constructeurs tiers, avec des refroidisseurs surdimensionnés. En effet, NVIDIA autorise la modification du TDP max. des cartes, mais en aucun cas des paliers de température par défaut de GPU Boost 3.0. Ci-dessous une représentation graphique de ce fonctionnement.

 

GPU Boost 3.0 [cliquer pour agrandir]

 

Avec Turing version RTX, NVIDIA a annoncé GPU Boost 4.0. En gros, ce dernier fonctionnerait de manière similaire, mais avec un ajustement qui fait toute la différence. En effet, les valeurs de températures sont à présent exposées, il est donc possible de les modifier. Bien sûr, il est nécessaire de rester dans la plage autorisée par le caméléon, mais le seuil à 37°C qui marquait le "début de la baisse" des fréquences, n'est plus imposé. Cela coïncide avec l’utilisation d'un refroidisseur plus performant sur les Founders Edition, qui ne perdent donc plus de fréquence du fait de la température. Toujours est-il, qu'il était très difficile de s'approcher du TDP max sur ces dernières en version Pascal, à part lors des premiers instants de forte sollicitation. Ce ne sera plus le cas avec les versions Turing RTX, qui seront davantage limitées par leur enveloppe thermique. Ci-dessous, la représentation schématique de GPU Boost 4.0. Notons également qu'un bin, prend à présent la valeur de 15 MHz, contre 13 MHz auparavant.

 

GPU Boost 4.0 [cliquer pour agrandir]

 

Nous avons précisé RTX car il semble bien que la série 16 ne soit pas gouvernée par la dernière itération de GPU Boost, mais bien la précédente ou plutôt un mix des deux, plus de détails à ce sujet dans nos dossiers dédiés à la série 16 de NVIDIA. Voilà pour les rappels, passons page suivante à la description des cartes de test que nous avons reçues.



Les 70 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur du 26 en Auvergne-Rhône-Alpes, le Samedi 06 Juillet 2019 à 09h55  
Merci beaucoup pour ce test.

Hâte de voir les Navi avec le correctif de prix s'intercaler dans tout cela.
par Reflections, le Mercredi 03 Juillet 2019 à 21h51  
Merci pour le test , toujours autant de pertinence de votre part
par BloodBrother, le Mercredi 03 Juillet 2019 à 20h17  
Et Merci pour ce dossier.
Maintenant, vous êtes les tauliers du Hardware Français alors j'espère qu'AMD, Intel, Nvidia etc. vont faire un effort pour vous fournir du matériel de prêt A temps pour des tests le plus exhaustifs possibles avec indice FPS Mini, des courbes de FPS a la "hardocp" serait le graal pour moi
En tout cas Merci.
On compte sur vous !
par Un ragoteur sans nom en Auvergne-Rhône-Alpes, le Mercredi 03 Juillet 2019 à 20h06  
c'est chaud pour AMD, Nvidia trop facile niveau gaming?
par Un ragoteur de transit en Île-de-France, le Mercredi 03 Juillet 2019 à 19h25  
Je m'attendais à un boost de fréquence ridicule histoire de faire parler et de relancer les ventes, mais Nvidia ne s'est pas moqué du monde là, le gap avec les modèles non-super est clairement pas négligeable !!
par Laitauriz, le Mercredi 03 Juillet 2019 à 18h51  
La position personnelle ne dépend pas d'une éventuelle préférence pour AMD ou Nvidia, mais de savoir si il est préférable de différencier une librairie " privée " d'un moteur optimisé pour un des concurrents. Pour moi , oui. Mais c'est une préférence. Eric a la sienne, que je comprends. Il m'a en effet informé sur l'utilisation des shaders intrinsic sur WWZ, que je ne pensais pas optimisés juste pour GCN. Quand je lis le reste de ton message, j'ai pourtant bien l'impression qu'on est d'accord sur l'essentiel, puisque tu fais bien toi même une distinction entre les deux, en disant que la librairie est désactivable, ce qui était l'objet de mon premier post.

Pour la fin, si la librairie est optimisée pour tirer parti de certaines spécifités d'une architecture, mais que tu ne peux en modifier le code source à cause d'un EULA,cela complique les choses.
par Un champion du monde en Bourgogne-Franche-Comté, le Mercredi 03 Juillet 2019 à 18h19  
par Laitauriz le Mercredi 03 Juillet 2019 à 17h57
Le contexte actuel de la discussion met en jeu une différence de position personnelle vis à vis d'une librairie. Je préfère simplement créer une distinction supplémentaire entre l'optimisation d'un moteur pour certaines cartes, et l'ajout d'une librairie d'effets qui en avantage d'autres. Selon moi , cette distinction permet un peu plus de précision quant à l'appréciation des différences de performance :
Moteur optimisé Nvidia ( jeux UE 4), moteur optimisé AMD ( WWZ ), moteur optimisé Nvidia+effets gameworks, moteur "neutre" + effets gameworks etc..
Donc je serai bien curieux de savoir où je me trompe, vu qu'il s'agit d'une discussion où l'enjeu est simplement de permettre un meilleur confort de "tri " ( subjectif), et non d'établir une vérité universelle. Mais je suis certain que tu vas m'éclairer .

Concernant la fin du message, il y a une grande différence entre être Open Source, et " Public Source" . Je te laisse chercher.
Non, ce n'est pas une différence de position personnelle car je ne suis pas plus fan d'amd que d'nvidia. Je déplore toutes les différentes pratiques destinées à tirer dans les pattes du concurrent en emmerdant l'utilisateur final.
En effet l'optimisation d'un moteur est plus dommageable pour l'utilisateur final qui ne pourra pas espérer jouer dans de bonnes conditions, contrairement à une librairie destinée à améliorer le visuel mais qui n'empêche pas de profiter du jeu si désactivée.
Je n'ai rien à éclairer, si tu n'es pas capable d'assimiler ce qu'Eric t'as expliqué, je ne vois pas pourquoi je perdrai du temps à ça
Pour ce qui est du "public source", c'est bien ce dont je parle. Et je fais bien la différence avec l'open source.
par Laitauriz, le Mercredi 03 Juillet 2019 à 17h57  
par Un hardeur des ragots en Bourgogne-Franche-Comté le Mercredi 03 Juillet 2019 à 17h15
Et pourtant on vient de t'expliquer que tu te trompes.
Par ailleurs nvidia a rendu public le code source de Gameworks. Donc c'est tout à fait la même situation que pour les shaders Intrinsic, amd pouvant optimiser pour gameworks via ses pilotes.
Le contexte actuel de la discussion met en jeu une différence de position personnelle vis à vis d'une librairie. Je préfère simplement créer une distinction supplémentaire entre l'optimisation d'un moteur pour certaines cartes, et l'ajout d'une librairie d'effets qui en avantage d'autres. Selon moi , cette distinction permet un peu plus de précision quant à l'appréciation des différences de performance :
Moteur optimisé Nvidia ( jeux UE 4), moteur optimisé AMD ( WWZ ), moteur optimisé Nvidia+effets gameworks, moteur "neutre" + effets gameworks etc..
Donc je serai bien curieux de savoir où je me trompe, vu qu'il s'agit d'une discussion où l'enjeu est simplement de permettre un meilleur confort de "tri " ( subjectif), et non d'établir une vérité universelle. Mais je suis certain que tu vas m'éclairer .

Concernant la fin du message, il y a une grande différence entre être Open Source, et " Public Source" . Je te laisse chercher.
par Un ragoteur RGB de Bretagne, le Mercredi 03 Juillet 2019 à 17h31  
par Un rat goth à l'heure en Île-de-France le Mardi 02 Juillet 2019 à 19h29
Utiliser gpubenchmark te fait perdre l'argument d'emblée
Je comprends pas que des gens utilisent ça alors qu'on a de vrais tests dispos..
moi je comprend pas que des gens utilisent QUE des test pour choisir !
nan mais ta raison les benchmark ca sert a rien!!

cette génération a des carte correcte mais y a rien de folichon a peine égaler ne suffit pas !
le gamme gtx 1xxx a + de 2 ans!
les rtx2070s sont facile 100/150€ trop chère.
par Un hardeur des ragots en Bourgogne-Franche-Comté, le Mercredi 03 Juillet 2019 à 17h15  
par Laitauriz le Mercredi 03 Juillet 2019 à 16h14
Je vois ce que tu veux dire. J'associe plutôt les optimisations Radeon de WWZ à celles des GPU Nvidia sur l'UE4 . Mais je place Gameworks dans une case à part encore .
Et pourtant on vient de t'expliquer que tu te trompes.
Par ailleurs nvidia a rendu public le code source de Gameworks. Donc c'est tout à fait la même situation que pour les shaders Intrinsic, amd pouvant optimiser pour gameworks via ses pilotes.
par Laitauriz, le Mercredi 03 Juillet 2019 à 16h14  
Je vois ce que tu veux dire. J'associe plutôt les optimisations Radeon de WWZ à celles des GPU Nvidia sur l'UE4 . Mais je place Gameworks dans une case à part encore .
par Eric B., le Mercredi 03 Juillet 2019 à 12h54  
Les cas des Rapid Packed Maths et des Shaders Intrinsics sont bien différents pour moi. Si pour le premier, c'est effectivement une feature qui est adaptable par mise à niveau hardware (c'est d'ailleurs le cas avec Turing qui gère les FP16 bien plus rapidement que Pascal), pour le second ce n'est pas la même histoire. Les instructions à traiter sont spécifiquement optimisées pour le hardware GCN (close to metal comme disent les anglophones) du fait de la proximité entre le studio et AMD, il est donc impossible de se mettre à niveau d'un point de vue hardware (sauf à copier la dite architecture).

La seule optimisation possible est software, c'est d'ailleurs ce qu'a du probablement faire NVIDIA pour limiter la casse, en interceptant les instructions au niveau du pilote pour les réagencer afin de les rendre plus adaptées/rapides sur son propre hardware. Du coup je ne vois pas bien en quoi ce serait plus sain que Gameworks, mais cela ne reste bien entendu que mon avis. A titre personnel, je trouve cela détestable d'un côté comme de l'autre, cependant ce ne sont pas des enfants de cœur, mais bel et bien 2 sociétés commerciales et tous les coups sont permis, malheureusement pour les utilisateurs des deux bords.