Reprise du message précédent :
Moi ce qui m'a fait marrer c'est arizonadream qui dit

Alors que c'est lui à l'origine du topic et du lien de l'article

Bah outrancier, pas tellement à mon avis.
Payer une carte graphique plus de 800 € et se contenter de 8 ou 10 Go de VRAM, même si pour l'instant ça n'est gênant que dans un cas particulier, c'est quand même limite
M'enfin ça plait à beaucoup de gamers, nombreux sont ceux qui sont anti-RAM, tant pour le CPU que pour le GPU

Bonjour,
 
Est-ce que la future utilisation de la techno DirectStorage ne va pas induire une utilisation plus élevée de la VRAM par les développeurs ?
 
Si j'ai bien compris (merci de corriger si ce n'est pas le cas), le principe du DirectStorage est de permettre d'envoyer des textures (ou autres données ?) directement du disque SSD vers la VRAM sans passer par le CPU.
 
Du coup, dans des jeux, style monde ouvert, une quantité élevée de VRAM disponible pourrait permettre d'améliorer certes la qualité via des textures 4K, mais pourrait éviter des chargements visibles (léger freeze par ex) lors des déplacements dans le monde du jeu grâce à DirectStorage ? (question pas une affirmation).
 
Ok, les jeux avec DirectStorage, ce n'est peut-être pas pour l'année prochaine, mais potentiellement dans un avenir assez proche qui ne rendrait pas une RTX 3080 trop faiblarde en puissance GPU.

Ce que j'en ai compris (ça vaut ce que ça vaut j'suis pas ingénieur ) c'est que ça sert surtout à réduire les échanges CPU-RAM-Disque en dehors du GPU qui fera le même boulot (charge les textures dans la vram quand c'est nécessaire).

En gros ça diminue la latence et permet également d'augmenter les débits, mais c'est surtout la latence qui est visée, le bon point du direct storage c'est également de soulager le CPU et la ram, qui n'auront plus besoin de faire des accès à foison pour charger les textures.

Fonctionnement sans DS :

Avec DS :

Ok, mais du coup, comme cela réduit la latence, augmente indirectement les débits car les données sont envoyées compressées puis décompressées par le GPU, très tentant d'utiliser la VRAM comme stockage de l'ensemble des textures d'un jeu, ou du moins un maximum par ex.  
 
Du coup, une grosse quantité de VRAM pourrait permettre cela. Et le jeu n'aurait plus qu'à "piocher" dans la VRAM pour afficher les textures. Plus aucun accès au disque par la suite. En fait, comme une sorte de cache de textures.
 
Et si en plus les textures sont envoyées compressées, il va falloir encore plus de VRAM pour les avoir en décompressées (surtout si la VRAM doit aussi stocker provisoirement la texture compressée reçue, ce qui semble être le cas quand on voit ton 2ième schéma, indice 3 GPU Decompress, pas de passage via la RAM, mais tout depuis la VRAM. Et surtout d'après ce schéma, le jeu ne pourra pas utiliser directement la texture compressée reçue visiblement puisqu'on voit une flèche dans le sens GPU vers VRAM dans l'indice 3, sous entendant que la texture décompressée sera bien copiée dans la VRAM également. Conséquence il faudra plus de VRAM pour stocker à la fois la texture compressée et celle décompressée, du moins, pendant un laps de temps).
 
C'est pourquoi je m'interroge sur la techno DirectStorage vs Quantité de VRAM nécessaire.

Je dirais plutôt que ça a l'effet inverse.
Si le transit des données est plus direct et rapide avec le DS, tu n'as pas besoin d'augmenter la Vram. Tu auras toujours la même quantité de données à charger en vram sauf qu'elle ne sera plus traitée par le CPU et ram en amont pour la décompression.
J'imagine qu'un GPU est plus à même de décompresser des données de ce genre qu'un CPU dont c'est finalement pas le boulot.

Finalement ce sera assez transparent pour l'utilisateur, sauf qu'il verra son CPU et sa ram bien moins sollicités qu'auparavant.

Le fait que ce soit le GPU qui se charge de la décompression n'empêche rien, c'est simplement un aller-retour vram <-> GPU pour que les textures soient décompressées.

Excuses, j'ai réédité plusieurs fois ma remarque.
Mais pour la problématique Texture reçue compressée + décompression le tout dans la VRAM, cela va forcément demander plus de VRAM, non ?

Peut-être, je ne me rends pas bien compte.
Vu que sans DS la vram accueille les textures décompressées, elle accueillera les textures compressées à l'avenir (donc moins de place prise dans la vram), et le GPU décompressera à la volée les textures selon les besoins, du coup le poids total des textures sera toujours moindre tant qu'il restera des textures compressées.
Et à terme l'espace utilisé sera le même qu'avant vu que les textures seront décompressées.

Après c'est le processus complet qui m'échappe un peu, ce que tu veux dire c'est que l'espace pris par les textures compressées dans la vram ne se "vide pas" en passant dans le CPU pour être décompressées, et ça j'avoue je n'en sais strictement rien

Justement, d'après ton schéma, cela ne semble pas être à la volée car il y a une flèche dans le sens GPU vers VRAM pour la phase 3 (GPU decompress). Sous entendant donc que la texture décompressée est bien stockée en VRAM (ainsi que la texture compressée).
 
Donc, si je suis logiquement le schéma, le GPU prend la texture compressée reçue stockée dans la VRAM (flèche sens VRAM vers GPU), la décompresse et stocke la version décompressée dans la VRAM (flèche GPU vers VRAM). A aucun moment on passe par la RAM du PC. Et je ne pense pas que le GPU a de la "RAM" intégrée quelque part.
 
En fait, avant, visiblement la décompression de la texture se faisait en RAM (PC), occupant donc aussi le CPU et la VRAM stockait QUE la texture décompressée.
Alors qu'avec DirectStorage, c'est le GPU qui fait tout. Donc il va forcément utiliser sa VRAM pour faire l'ensemble de son opération réception (compressée) + décompression. Non ?
 
Après, si en effet la version décompressée ne reste, en VRAM, que provisoirement selon la scène à afficher et permet de n'avoir QUE les textures compressées en VRAM, on pourrait ne pas avoir besoin de plus de VRAM. C'est la question également...
 
Et sinon, une texture cela se compresse bien ? (pas style JPG quoi, car déjà compressée).

Les flèches vram <--> GPU sont dans les deux sens. Mais oui en effet le GPU utilisera sa vram pour traiter les textures.

Perso j'en déduis que les textures compressées sont accueillies en vram, traitées par le GPU puis retournent en vram une fois décompressées. Mais peut-être qu'elles sont stockées temporairement dans la vram et décompressées selon l'utilisation.
Peut-être que ça dépend aussi de la façon dont le dev va coder son jeu, et qu'on pourra aussi voir des différences de perfs apparaitre selon ce que les dev feront.

Dans les deux cas je ne vois pas pourquoi on aurait besoin de plus de vram. Au final la texture compressée pèse moins lourd que celle qui est décompressée, et celle qui n'est plus utile est supprimée. C'est le cas de la texture compressée qui vient d'être décompressée, à priori, car pourquoi conserver une texture compressée alors que son homologue décompressée est repassée en vram ?
Mais je passe peut-être à côté d'un détail je te l'accorde.

Mais tu es bien d'accord, qu'un moment tu as à la fois la version compressée et la version décompressée en cours d'utilisation?
Donc il y a un "pic" de consommation de VRAM. Pic d'autant plus violent si la texture est fortement compressée et en haute résolution.
 
Enfin, bref, trop tôt pour le dire. Mais je m'interroge (et vous interroge également   )
 
Mais l'augmentation de la VRAM est quand même observable (surtout chez AMD).
Et même sur des modèles bas/moyen de gamme chez les verts. Mais plutôt dû sûrement à la problématique de la taille du bus (sauf utilisation d'une ruse (très mal vue) comme on a pu voir sur la GTX 970, une partie de la VRAM était moins rapide). Car 6 Go, cela fait trop short, et du coup on se retrouve avec du 12 Go sur des cartes bas/moyen de gamme alors que la haut de gamme (RTX 3080) n'en possède "QUE" 10 Go. Un peu ballot quand même.

C'est ce point qui peut m'échapper, je n'ai pas la réponse à vrai dire.
Est-ce que ça fonctionne comme des vases communiquant ou est-ce que l'allocation de vram est fixe, et du coup en effet tant que la texture n'est pas décompressée en entier sa version compressée ne doit pas être supprimée, mais on peut imaginer que tout se fait tellement rapidement que le pic de conso de vram est imperceptible, j'avoue que c'est un point d'interrogation, peut-être faudra-t-il un tampon de vram pour palier à ce genre de questions.

Oui ça nous oblige à s'interroger.

Je verrais plus d'intérêt à garder la version compressée (du moins le plus longtemps possible selon la taille de la VRAM) et supprimer de la VRAM la version décompressée quand elle n'est plus utilisée. Surtout qu'elle occupe plus de place.
Le GPU pouvant, à tout moment, redécompresser la version compressée sans faire appel au SSD pour la récupérer.

Oui, de ce point de vue tu as totalement raison, ça pourrait impliquer une augmentation du besoin en vram, éventuellement rajouter un bout de vram moins rapide, mais là ça devient couillon

 
Ah, j'aurais pas du prendre mon temps de bien le lire ^^. Bref y a bien un soucis de VRAM donc, après ça doit dépendre de certaines locations etc, ce qui veut dire que certains joueurs n'ayant pas encore atteints ces lieux, ne reportent pas de problème ... ou sinon des gens qui ont juste testé 5 min pour dire, non y a pas de soucis avec FC 6 .
 
Mais si c'est bien un soucis de vram et bien faut se dire qu'à l'avenir ce genre cas va petit à petit augmenter etc. A confirmer cela dit oui.

D'un côté le besoin de vram augmente à cause de l'augmentation de la définition des écrans, le passage à la 4K n'a rien arrangé de ce côté là, et celui de la 8K à venir ne va surement pas nous faire revenir en arrière à ce niveau.

Après ce "bug" en lui même ne concerne qu'un jeu, tout juste sorti et qui n'a pas encore de patch correctif (sauf erreur de ma part bien sûr)
Il y a en effet des chances pour que dans le futur il y ait également un ou deux jeux qui soient dans le même cas, mais ça ne concernera pas l'ensemble de la ludothèque à priori.

Ce qui n'empêche pas une augmentation de vram nécessairement liée à celle de la définition de nos futurs écrans.

 
La 4K c'est plus tout jeune quand même quelques années déjà que les moniteurs 4K ont commencé à être abordable niveau tarification. Par contre contrairement au 1080p, le tau d'adoption du 4K ou 1440p etc est toujours au ralentie.  
Mais oui y a cette tendance de fond d'augmentation de la consommation de vram suivant l'augmentation de la résolution des écrans.  
 
Mais c'est intéressant de voir si c'est un bug isolé, ou le début d'une tendance oui ^^, un jeu qui vient de sortir, patchs / pilotes. A surveiller.  
 
Sinon oui la quantité de VRAM n'a pas vraiment augmenté depuis Pascal, il y a de cela 5 ans, donc qu'on reparte à la hausse ça parait normal (et la nouvelle génération de console aussi ).

Les écrans oui, pas l'adoption côté GPU comme tu le précises, même si ça commence (pour le haut de gamme en tout cas).
Déjà le passage de la SD à la HD a été long, faudra sans doute un peu plus longtemps pour que l'adoption de la 4K soit pleine à cause du gap de perf que demande la 4K par rapport au FHD, sans doute d'ici à ce que les écrans 8K commencent à devenir la norme, même s'il n'y a quasi pas de contenu dans ce format.
Je disais "passage" mais c'était pas à prendre au sens "du jour au lendemain", l'adoption d'une techno prend du temps, ne serait-ce que par manque de moyen motivé ou pas par l'envie ou le besoin de changer.

 
Intéressant les graphs et vos questionnements (avec wgromit) sur les futures besoin en vram (où pas) avec direct storage.
 
Perso, au delà d'un besoin "peut être" plus important en vram avec cette techno, moi je me questionne sur l'impact en perf du décodage/réencodage des textures compressées/décompressées par le gpu

Je me suis posé la même question pendant notre discussion avec mrdoug, il y aura forcément une utilisation plus importante du GPU, mais dans quelle mesure celà se ressentira c'est un autre délire.
 
Ce que je me demande aussi par rapport à notre discussion c'est comment sont intégrées les textures actuellement, vu qu'on prend forcément en compte une latence et un débit particulier.  
A priori le débit de référence est proche de celui d'un disque dur mécanique vu qu'on sait qu'il n'y a pas de différence à ce niveau entre un jeu sur SSD nvme et un jeu sur HDD méca ou alors c'est prévu dans le code du jeu que les textures soient tout simplement chargées en ram ?
Peut-être que déjà aujourd'hui faute d'un débit/latence idéaux il y a une partie des textures déjà décompressées qui sont stockées dans la vram, peut-être justement est-ce cette fameuse différence entre vram allouée et vram réellement utilisée ?
 
Ce ne sont que des peut-être car clairement nous ne sommes pas dans les petits papiers des fabricants de cartes ou des développeurs de jeux, car là aussi il y a nécessairement des différences dans l'exploitation d'un GPU selon ses possibilités.

 
En effet, pour avoir déjà fait le test, hormis les chargements plus long, un jeu tourne quasi de manière identique sur un nvme et un hdd classique (sauf cybperpunk qui a une option pour les hdd).
 
Je me suis dit la même chose pour cette diff entre vram allouée et vram réellement utilisée.
Vu que les jeux sont majoritairement des portages consoles qui tournaient sur des hdd, ce n'est pas déconnant de penser ça (avec tout les problèmes de latence et de saccade que ça engendre dans un open world).
 
Après à voir l'impact que ça aura sur les perfs gpu et si on va enfin avoir un streaming/chargement complètement transparent dans un open world.
Peut être la réponse en 2022, quand les développeurs abandonneront les versions ps4/one.

Pardonne ma culture console proche de zéro (ma seule console a été la NES ), mais les one et ps4 pro par exemple n'avaient/n'ont pas de SSD ?

 
Non one x et ps4 pro, c'est du HDD classique...
 
Après, il me semble que tu peux accéder à la baie et mettre un ssd sata à la place mais comme sur pc, tu ne gagnes qu'en temps de chargement et encore..(on parle d'un cpu jaguar...)

En temps de chargement, en bruit et en chauffe, dans une console ça peut avoir son intérêt. Et aussi, tu peux donner un coup de pied à ta console sans faire exprès en plein jeu et à priori t'auras pas de problème.
Ca se clone facilement ou c'est la merde un disque de console ?

 
Je ne peux pas te dire, je n'ai jamais essayé.
J'ai une ps4 pour les exclus mais j'y joue rarement et je ne me suis jamais intéressé à un changement de lecteur.

J'me dis ça parce que le prix d'une console avec un gros disque de mémoire c'était vachement élevé par rapport à un disque plus faible (pas de rapport avec la diff de prix entre deux disques de capacités correspondante il me semble).
Du coup je subodore le tatouage ou autre connerie du genre interdisant de faire évoluer le disque de sa console à moindre frais.

 
Pour les tarifs, ne suivant pas l'actualité console, je ne sais pas; après je pensais que les modèles étaient remplacé à iso tarif pour un disque de plus grande capacité.
 
De ce que j'avais lu à l'époque, tu peux mettre n'importe quel disque dur classique dedans et ça fonctionnera (après je n'affirme rien, n'étant pas un spécialiste console; peut être qu'il y a une limite en capacité).

Il ne me semblait pas mais je peux totalement me gourrer là dessus, technique du doigt mouillé si tu vois

J'ai installé un SSD dans ma PS4 pro sans souci. Il faut penser a faire un backup sur disque externe USB (FAT32 ou exFAT) des sauvegardes et trophées (pas besoin si abonnement PSN), il est possible de sauvegarder aussi les donnees des jeux.
 
Ensuite tu remplaces le disque de la console; puis tu suis la procédure pour installer le système sur le nouveau disque
https://www.playstation.com/fr-fr/s [...] safe-mode/
Finalement tu peux restaurer les données du backup