j'aimerai une explication c'est pourquoi le GPU étant exploité à 94 % la mémoire dédiée donc celle de la CG ( Nvidia 3090 ) ne représente que 11 .3 Go sur 24 Go de dispo
C'est amusant car les utilisateurs qui achètent une certaine quantité de VRAM veulent absolument voir le compteur de celle-ci bloqué près de ce chiffre...
Cela doit les rassurer!...
Une mémoire active est là pour permettre l'échange de données de manière "
temporaire" à l'unité de traitement associée.
Elle va donc se comporter comme un réservoir que l'on rempli d'un coté et que l'on vide de l'autre au grès des besoins de l'unité de traitement.
Plus l'unité de traitement est capable de réaliser des opérations, plus elle va avoir besoin de stocker de manière temporaire des données.
Lors de la conception d'une CG, les ingénieurs, en fonction des caractéristiques de la puce graphique, ont la possibilité de jouer sur :
- La quantité de VRAM,
- La vitesse des I/O de la VRAM (Fréquence, techno...),
- Ainsi que la taille du bus de données (design de celui-ci...).
Je passe volontairement sur le coté "Marketing"...
Eux, une fois que tout est borné, sont en charge de présenter les éléments techniques de façons chatouillantes à des consommateurs qui la plupart ne comprennent pas se qu'ils achètent.
Donc, revenons à la technique et plus spécifiquement à une utilisation réelle et non de bench.
Maintenant que tout cela a été fait... Il y a un éminent utilisateur connu, all over the World, sur les principaux forums de simulation aérienne et qui emmerde ses petits camarades alors qu'ils sont en retraite et tranquillement en train de prendre leur petit café du matin...
Le gus s'appelle : RORO!...
Donc, maintenant que nous avons une CG qui a un territoire borné au travers de ses caractéristiques et qui est correctement montée sur une machine qui dispose de beaucoup de
mémoire partagée, il n'y a donc pas de ralentissement à ce niveau.
Les
VRAIS textures (Pas les fichiers BitMap que tous le monde appelle 'textures'...
) crées par le programme au travers de ses API graphiques (DirectX, OpenGL/Vulkan) seront transférées à la CG de façons optimale.
Il y a également les fichiers programmables (Shaders) qui sont transférés afin d'être exécutés pas le CGU et qui utilisent de l'espace VRAM.
Le CGU lui-même (Au travers de chacune des unités CUDA pour NVidia... Pour AMD, c'est Idem, mais je ne me rappelle plus du nom!...) va utiliser pour son activité de rendu de l'espace mémoire à un instant 'T'.
Le CGU va également utiliser de l'espace mémoire pour sa propre gestion et notamment pour la gestion des tables d'adressage mémoire. Ne pas oublier que celle-ci est virtualisée comme la RAM par le CPU.
Maintenant, qui s'occupe de cette gestion d'activité de quantité de VRAM disponible à un instant 'T'?...
Deux réponses...
- Le programme est écrit avec un niveau d'API
DirectX 11/OpenGL ou antérieur... Et, dans ce cas ce sont les Runtimes
DirectX/OpenGL qui ont en charge cette gestion active de la VRAM.
Le développeur de l'applicatif ne se préoccupe pas de cela.
- Le programme est écrit avec un niveau d'API
DirectX 12/Vulkan... Dans ce cas, c'est différent car la gestion de
l'activité VRAM est maintenant sous la responsabilité du développeur. Il a notamment une instruction de "
Budgétisation" de celle-ci lors de l'initialisation de son API et doit écrire les routines de gestion.
De plus, comme il faut bien 'simplifier' les choses...
Dans les deux cas de figures ci-dessus, le choix d'utiliser dans les API, tel ou tel type de 'Buffers' va avoir une influence sur l'activé de cette VRAM puisque leurs portées sont différentes.
Donc, pour être plus concret, avant c'était le Driver du Runtime qui gérait l'activité de la VRAM, maintenant c'est le développeur.
Mais dans les deux cas de figures, il ne faut pas que celle-ci se retrouve en utilisation maximale car elle serait, dans ce cas, le point de rétention du Pipeline graphique.
