44 Go de mémoire vidéo sur une GeForce RTX 2080 Ti ? Parce que pourquoi pas !

Nerces
Spécialiste Hardware et Gaming
13 juin 2023 à 18h49
22
© VideoCardz
© VideoCardz

Ajouter de la mémoire vidéo à sa carte graphique est « à la mode » et peut pousser à faire un peu n'importe quoi !

Sortie très exactement le 27 septembre 2018, la GeForce RTX 2080 Ti était, en son temps, un modèle de puissance dont le GPU – un TU102-300 – pouvait compter sur un total de 11 Go de mémoire vidéo. Considérable à l'époque.

44 Go de GDDR6, rien que ça !

Depuis, pas mal d'eau a coulé sous les ponts. Non seulement NVIDIA a lancé les générations RTX 3000/RTX 4000, mais la société et sa concurrente AMD ont aussi augmenté la quantité de mémoire vidéo embarquée.

© VideoCardz
© VideoCardz

AMD titille d'ailleurs souvent NVIDIA sur ce sujet. De multiples Radeon RX 6000 pouvaient ainsi compter sur 16 Go de VRAM quand pas mal de GeForce devaient se contenter de 8, 10 ou 12 Go. Il a souvent été reproché à NVIDIA de négliger cet aspect des modèles de référence.

NVIDIA a répondu que l'optimisation des moteurs graphiques est préférable à l'inflation du côté de la quantité de VRAM. Cela dit, quelques doux dingues, possesseurs d'une GeForce RTX 2080 Ti, ne semblent pas de cet avis.

Aucun jeu ne peut être lancé

Les modders ont effectivement publié les photos d'une carte graphique dont les puces mémoires présentes originellement ont été remplacées par des composants d'une capacité quatre fois plus grande.

© VideoCardz
© VideoCardz

De fait, la GeForce RTX 2080 Ti, qui disposait de 11 Go de VRAM, est passée à 44 Go, toujours en GDDR6 bien sûr. La bande passante est inchangée et, grâce à l'utilisation d'une interface 352 bits, elle est de 616 Go/s, une valeur qui n'a rien de déshonorant en 2023.

Les modders ont précisé qu'ils ont utilisé une carte Leadtek RTX, mais qu'ils ont dû s'y reprendre à sept fois pour valider leur opération. Le logiciel GPU-Z a validé leur dernière tentative, indiquant une VRAM totale de 45 056 Mo (44 Go) avec maintien de la bande passante à 616 Go/s.

Attention cependant, même si la transformation est amusante et que l'on aurait aimé voir le résultat sur des jeux récents, les modders ajoutent que la carte refuse de fonctionner sur des jeux ou des benchmarks. En effet, pour fonctionner, une GeForce ainsi modifiée a besoin d'un BIOS ajusté.

Source : VideoCardz

Nerces

Spécialiste Hardware et Gaming

Spécialiste Hardware et Gaming

Tombé dans le jeu vidéo à une époque où il fallait une belle imagination pour voir ici un match de foot, là un combat de tanks dans ces quelques barres représentées à l'écran, j'ai suivi toutes les év...

Lire d'autres articles

Tombé dans le jeu vidéo à une époque où il fallait une belle imagination pour voir ici un match de foot, là un combat de tanks dans ces quelques barres représentées à l'écran, j'ai suivi toutes les évolutions depuis quarante ans. Fidèle du PC, mais adepte de tous les genres, je n'ai du mal qu'avec les JRPG. Sinon, de la stratégie tour par tour la plus aride au FPS le plus spectaculaire en passant par les simulations sportives ou les jeux musicaux, je me fais à tout... avec une préférence pour la gestion et les jeux combinant plusieurs styles. Mon panthéon du jeu vidéo se composerait de trois séries : Elite, Civilization et Max Payne.

Lire d'autres articles
Vous êtes un utilisateur de Google Actualités ou de WhatsApp ? Suivez-nous pour ne rien rater de l'actu tech !
google-news

A découvrir en vidéo

Rejoignez la communauté Clubic S'inscrire

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

S'inscrire

Commentaires (22)

Pernel
Je vois 45Go plutôt. En tout cas, même si ça ne sert a rien, c’est toujours cool de voir ce que les gens peuvent faire.
jvachez
Non car il faut diviser par 1024, ça fait bien 44.
Mister_Georges
Pas de PhysX sur cette RTX 2080Ti?
Blap
Il faut bien diviser par 1000. Tu confonds Go et Gio (qui n’est pas forcement en multiple de 1024 en plus)
MattS32
C’est vrai, en théorie.<br /> En pratique, la RAM est un des domaine où la division par 1024 a toujours été de rigueur (sans doute parce que pour des raisons techniques la capacité des puces de RAM tombe toujours rond en divisant par 1024, et donc jamais en divisant par 1000), contrairement aux disques durs où les fabricants sont vite passés de 1024 à 1000 quand ils se sont rendus compte que ça les arrangeait bien.<br /> Et en l’occurrence, si on divise par 1000, c’est pas 45 Go non plus, c’est 47.2 Go. 45 Go, c’est en faisant un calcul bâtard, en divisant par 1024 pour les Ko et les Mo puis par 1000 pour les Go.
Pernel
45 056 / 1 000 = 47.2 ?
MattS32
47244640256 / 1024 / 1024 / 1024 ~ 47.2<br /> Parce que les 45 056 MB affichés par GPU-Z, c’est déjà en divisant la capacité en octets deux fois par 1024 qu’ils sont obtenus.
Pernel
Tu le sors d’où ton 47244640256 ?
MattS32
45 056 * 1024 * 1024 <br /> Et c’est facile à vérifier que ça colle : 47 244 640 256 est bien un multiple de 11 (le nombre de canaux de 32 bits pour arriver à 352 bits).<br /> Avec 2 puces par canal, ça ferait 2 147 483 648 bits par puce.<br /> Et là encore, c’est cohérent, puisque sur 32 bits ça fait 67 108 864 mots par puce. Soit exactement 2^20 (rappel : la capacité d’une puce mémoire est toujours une puissance de 2, car elle est simplement caractérisée par le nombre de bits significatifs dans l’adresse, donc ici, 20 bits).<br /> Alors que si c’était 45 056 000 000 octets, ça ferait 64 000 000 mots par puce. Pas une puissance de 2.<br /> Autre moyen de vérifier simplement que les « MB » de GPU-Z sont en fait bien obtenus en divisant par 1024, il suffit de comparer ce qu’affiche GPU-Z et ce qu’affiche Windows pour une même carte graphique, en sachant que Windows a toujours divisé par 1024.<br /> Par exemple, pour ma 3080, GPU-Z indique 10240 Mo, Windows affiche 10 Go tout rond. C’est donc bien que les 10240 Mo affichés par GPU-Z correspondent à 10 737 418 240 octets. Si c’était 10 240 000 000 octets, Windows n’afficherait alors plus 10 Go, mais 9.5.
testeur2003
Peu utile pour les jeux, ce serait en revanche un sacré mod pour la génération d’images comme avec Stable Diffusion ou la gestion de LLM avec oobabooga. Mes « pauvres » 8GB de VRAM sont bien à la peine dès qu’on arrive sur des modèles non « quantisés ».
Pernel
Sauf que Windows mélange depuis toujours la base 1000 et la base 1024. C’est pour ça qu’un SSD de 1To sera indiqué comme faisant environ 0.9To. C’est plutôt 0.9Tio donc 1To.
MattS32
Non. Windows ne mélange pas. Il se trompe sur l’unité, mais il est cohérent, il se trompe tout le temps, en divisant par 1024 à chaque étape, pas en mélangeant division par 1000 et division par 1024.<br /> Petit exemple :<br /> On voit bien que pour passer de 3 012 895 662 080 octets à 2.73T il faut diviser 4 fois par 1024.<br /> S’il divisait par 1000 jusqu’au M puis par 1024 au-delà, il donnerait 2.87T, pas 2.73T.<br /> Et je t’assure, pour tout ce qui est RAM, les constructeurs ont toujours compté en 1024, comme le fait Microsoft.<br /> Met 2 barrettes de 16 Go de mémoire dans un PC, tu verras que ta quantité de RAM sera 32 768 Mio. Parce qu’en fait elles font 16 Gio les barrettes, pas 16 Go.<br /> C’est une conséquence technique du fonctionnement des puces de RAM, qui fait que leur capacité en nombre de mots tombe toujours rond en divisant par 1024 pas en divisant par 1000. Parce que la capacité d’une puce mémoire est toujours une puissance de 2.
Pernel
Bah justement: 3 012 895 662 080 c’est en base 1000, 2.73To (enfin Tio normalement) c’est en 1024, ça n’a pas de sens. Il devrait dire 3 012 895 662 080 octets, 3.01To.<br /> Oui la RAM est en base 1024, mais ça ne change pas le fait qu’il a toujours des mélanges d’unités.<br /> Par exemple 16Go de RAM, c’est pas 16Go mais 16Gio, ça ne fait pas 16 000 000 000 octets.<br /> Dans le cas de la 2080Ti, c’est pas 44Go justement. 44Gio à la limite.
MattS32
Bah justement: 3 012 895 662 080 c’est en base 1000<br /> Ben non, c’est en « base » rien du tout. C’est le nombre exact d’octets, sans qu’aucune division n’ait encore été effectuée…<br /> Et le nombre exact d’octet, Windows le divise ensuite à chaque « saut » d’unité par 1024. Jamais par 1000.<br /> Donc si il dit que ma carte graphique fait 10G, c’est qu’elle fait 10x1024x1024x1024 = 10 737 418 240.<br /> Et donc si à côté GPU-Z dit qu’elle fait 10 240M, c’est que, comme Windows, GPU-Z divise par 1024.<br /> Et donc, les 45 056M affichés par GPU-Z pour cette 2080 Ti trafiquée correspondent à 47 244 640 256 octets.<br /> Pernel:<br /> Par exemple 16Go de RAM, c’est pas 16Go mais 16Gio, ça ne fait pas 16 000 000 000 octets.<br /> Oui, c’est exactement ce que j’ai dit : « Parce qu’en fait elles font 16 Gio les barrettes, pas 16 Go. ».<br /> Pernel:<br /> Dans le cas de la 2080Ti, c’est pas 44Go justement. 44Gio à la limite.<br /> Oui, c’est 44 Gio, soit 47.2 Go. Ce n’est ni 44 Go, ni 45 Go.
Pernel
MattS32:<br /> Ben non, c’est en « base » rien du tout. C’est le nombre exact d’octets, sans qu’aucune division n’ait encore été effectuée…<br /> Et le nombre exact d’octet, Windows le divise ensuite à chaque « saut » d’unité par 1024. Jamais par 1000.<br /> Donc si il dit que ma carte graphique fait 10G, c’est qu’elle fait 10x1024x1024x1024 = 10 737 418 240.<br /> Et donc si à côté GPU-Z dit qu’elle fait 10 240M, c’est que, comme Windows, GPU-Z divise par 1024.<br /> Et donc, les 45 056M affichés par GPU-Z pour cette 2080 Ti trafiquée correspondent à 47 244 640 256 octets.<br /> Ce qui n’est pas correct, comme je le dit depuis tout à l’heure…<br /> 10Go ne fait pas 10 737 418 240, enfin ne devrait pas, c’est incorrect même si c’est affiché comme ça. Il devrait afficher 10Gio justement.
MattS32
Pernel:<br /> Ce qui n’est pas correct, comme je le dit depuis tout à l’heure…<br /> Je ne dis pas le contraire hein… L’unité est fausse.<br /> Mais elle est fausse à tous les niveaux. Pas juste en passant de M à G.<br /> Donc pour calculer selon les règles SI le nombre de Go de cette 2080 Ti, tu ne peux pas prendre 45 056M et diviser par 1000. Parce que ces 45 056M, ce sont eux même déjà des Mio, pas des Mo. 45G, c’est le résultat d’un calcul bâtard, en divisant par 1024 aux 2 premiers niveaux puis par 1000 au dernier.<br /> Il faut d’abord remonter à l’unité de base, l’octet, en multipliant par 1024 à chaque étape, ce qui donne 47 244 640 256, et ensuite, tu divises 3 fois par 1000. Et ça donne ~47.2 Go pour 44 Gio.
Pernel
MattS32:<br /> Mais elle est fausse à tous les niveaux. Pas juste en passant de M à G.<br /> J’ai pas dit le contraire.
MattS32
Pernel:<br /> J’ai pas dit le contraire.<br /> Ben en disant que c’est 45 Go, de fait, si, tu as bien considéré que le calcul était « juste » jusqu’aux Mo et que seule la conversion Mo → Go était fausse…<br /> Sinon, tu aurais dit 47.2 Go, en corrigeant l’intégralité du calcul, et pas juste la dernière étape.<br /> Désolé, t’as voulu chipoter en ressortant une nième fois ce débat. Fallait le faire correctement. Surtout quand de ton côté tu te prives pas de dire « Go » au lieu de « Gio » quand tu parles de capacité mémoire, donc c’est un peu ridicule de reprocher à Clubic de le faire…
Pernel
MattS32:<br /> c’est un peu ridicule de reprocher à Clubic de le faire…<br /> Premièrement c’est pas un reproche, juste une notification d’une erreur, faut arrêter de voir le débat partout, c’est pas parce qu’on trouve une erreur que la personne reproche quoi que ce soit, hein…<br /> C’est pas ridicule de voir des « nièmes débats » comme tu dis quand ce n’est pas le cas ? Vouloir rectifier quelque chose n’est pas un débat, ni même un reproche. Dès qu’on dit quelque chose, c’est un débat, c’est un reproche, c’est une attaque, c’est machin, c’est truc. Faut arrêter la parano et voir le mal partout…
Blap
Ce n’est pas vraiment que ca arrangeait les constructeurs de disques dur, mais c’est Windows qui a un bug: Sur les autres OS on a bien les bonnes données constructeurs d’affiches.<br /> Ah ben bug de cache du forum et grilled 50 fois
MattS32
Boup:<br /> Ce n’est pas que ca arrangeait les constructeurs de disques dur, mais c’est Windows qui a un bug: Sur les autres OS on a bien les bonnes données constructeurs d’affiches.<br /> C’est facile à dire à posteriori aujourd’hui. Mais c’est pas du tout comme ça que ça c’est passé en réalité.<br /> Historiquement dans le monde informatique, TOUT LE MONDE comptait par 1024. Et ce bien avant Windows. Parce que les capacités étaient naturellement des multiples de 1024, parce que ça nécessitait aussi moins de puissance pour diviser par 1024 que par 1000 (on parle d’une époque où certains CPU n’avaient même pas d’instruction pour faire une division, alors que diviser par 1024 c’est juste un shift de 10 bits) et parce que sur des petites capacités, l’écart entre diviser par 1000 ou 1024 était pas bien grand.<br /> Même les fabricants de disques durs et de disquettes comptaient comme ça (oui oui, reprend des vieux disques durs de l’époque où ça se comptait en Ko, tu verras…). Et TOUS les OS comptaient comme ça.<br /> Ensuite, dans les années 80-90 les fabricants de stockage de masse se sont mis à diviser par 1000 pour le passage des Ko aux Mo (et initialement uniquement pour lui… les Ko étaient au début toujours comptés à 1024 octets, parce que ça faisait 2 secteurs =&gt; ils divisaient le nombre de secteurs par 2000 pour donner la capacité en Mo°), parce que ça donnait des chiffres plus gros. Pour les disques optiques, le passage à une division par 1000 est arrivé encore plus tard, avec les DVD, alors que les CD avaient bien une capacité calculée en divisant par 1024 (sauf quelques fabricants rusés qui affichaient 680/730 Mo contre 650/700 Mo chez les concurrents).<br /> Puis le CEI s’en est mêlé en introduisant les préfixes binaires, en 1999, parce qu’avec les capacités qui se comptaient désormais en Go, l’écart entre les deux modes de calcul n’était plus du tout négligeable. Mais c’est relativement récent donc…<br /> Jusqu’à l’arrivée des préfixes binaires, TOUS les OS calculaient en 1024 et étaient donc «&nbsp;faux&nbsp;» au sens des préfixes SI (mais pour rappel, l’octet n’est pas une unité du SI…). Et ils ont encore mis une décennie avant de changer.<br /> Ce n’est qu’une dizaine d’années après l’intervention du CEI que les OS ont commencé à changer. Sur macOS, c’est en 2009 (10.6) que le changement a été fait, en gardant les préfixes SI et en calculant avec un facteur 1000 au lieu de 1024. Ce qui a perturbé pas mal de monde (j’ai bien suivi la transition, j’étais sur Mac à l’époque), parce que du jour au lendemain, en mettant simplement à jour l’OS, toutes les tailles de fichiers ont «&nbsp;augmenté&nbsp;»… Mais ce changement ne concerne que le stockage de masse. Pour la RAM, les informations système de macOS continuent à calculer en divisant par 1024 et à afficher le préfixe SI, pas le préfixe binaire… Apple a encore eu besoin de 7 ans de plus pour passer à la division par 1000 sur iOS (iOS 10, 2016) et utilise encore la division par 1024 sur watchOS (cf le site d’Apple).<br /> Et côté Linux, c’est aussi à peu près à cette période que ça a été modifié… Sauf que là c’est le bordel, parce que multiplicité des communautés encadrant les différents composants oblige, il n’y a plus aucune cohérence… Tu en as qui sont allés au plus simple, ils ont gardé les divisions par 1024 et mis les préfixes binaires (par exemple, les commandes top, free, lscpu…), tu en as qui sont restés sur l’ancien mode par souci de compatibilité (par exemple, sur mon Ubuntu 20.04, du -h, df -h ou ls -l --block-size=K font des divisions par 1024), tu en as, plus rares, qui sont passés à une division par 1000 (pas d’exemple qui me vienne directement…). Bref, c’est un joyeux bordel, finalement bien pire que le statu quo de Microsoft…<br /> 4 commandes de base de l’OS, 3 affichages différents (une qui affiche l’unité «&nbsp;complète&nbsp;» avec préfixe binaire, une qui affiche uniquement le préfixe binaire sans l’unité, sauf quand il n’y a pas de préfixe, deux qui affichent uniquement le préfixe non binaire, mais qui calculent quand même en divisant par 1024).<br /> C’est là qu’on se rend compte qu’il n’y a pas de solution idéale, et que tout changement, qu’il soit dans le mode de calcul ou dans les unités affichées risque de perturber l’utilisateur, mais aussi de provoquer des dysfonctionnement (imagine un script qui parse la sortie d’une commande pour récupérer une info… si la commande de base change son mode de calcul ou l’unité, ça peut foutre en l’air le script). Ce qui peut expliquer la décision de Microsoft de ne toucher à rien…<br /> Alors résumer ça à «&nbsp;Windows qui a un bug&nbsp;», c’est vraiment excessivement réducteur, c’est oublier tout ce qu’il s’est passé des années 60 aux années 2000, mais aussi oublier les incohérences qu’on trouve sur les autres OS : certes Windows n’affiche pas les bons préfixes, mais c’est le seul à utiliser TOUJOURS le même mode de calcul, et pas l’un ou l’autre selon le type d’espace de stockage qu’on mesure ou selon l’humeur de celui qui a développé tel ou tel composant du système.<br /> ° exemple flagrant avec les disquettes 3.5" : les disquettes «&nbsp;double densité&nbsp;» avaient 2 faces de 80 pistes de 9 secteurs de 512 octets, soit 737 280 octets, vendus par les constructeurs comme faisant 720 Ko, donc en divisant par 1024, tandis que les «&nbsp;haute densité&nbsp;» exactement le double, en passant à 18 secteurs par piste, mais étaient vendus comme faisant 1.44 Mo, donc en divisant par 1024 puis par 1000…
Voir tous les messages sur le forum
Haut de page

Sur le même sujet