Sind 6GB VRAM zu wenig? Eine Analyse mit Pro / Kontra Betrachtung

[HisN]

Ist euch noch nie aufgefallen das ein Windows-Desktop im Leerlauf auch VRAM braucht? Wirklich jetzt?
Wie willst Du das aus der Gleichung rausnehmen? Natürlich hab ich mehr belegtes VRAM als das Tool alleine belegt. Nämlich das Tool + meinen Windows-Desktop. Mit Browser, ein Mediaplayer läuft da auch noch bei mir. Discord, TS ... Tools ..
Aber das hätte ich doch mit einer 6GB Graka genau so^^


Also ich würde es mal so formulieren:
Wenn ich ROTTR in FHD in MAX-OUT zocken möchte, und dabei gerne so viele FPS wie möglich hätte, dann würde bei MEINEM Desktop eine 6GB-Karte MEIN Ziel nicht erreichen, weil zu wenig VRAM die Leistungsentfaltung der Karte eventuell stören könnte. Und das lustigerweise sogar im CPU-Limit.


- - - Updated - - -

Auf dem Bild mit 24gb VRAM hast Du weniger FPS als auf dem mit 8gb VRAM.
Woher kommt die 8gb VRAM Anzeige, wenn Du 18gb allocatest mit dem Tool?

Ich habs Dir im Edit nochmal auseinanderklamüsert in #121. Ich verliere 10 FPS, weil zu wenig VRAM da ist. Da ich eine 6GB Graka simuliere. Ihr müsst schon ein bisschen über die Wirkungsweise vom Tool nachdenken^^

 

[Goderion]

Ohne Tool: 8GB VRAM in Gebrauch, 95 FPS, 13GB RAM
Mit Tool eine 6GB-Graka simuliert: 24GB VRAM in Gebrauch (18 +6), 86 FPS (minus10 im Vergleich zu ohne Tool), 16GB RAM (Plus 3GB im Vergleich zu ohne Tool)
Mit Tool eine 14GB-Graka-simuliert: 18 GB in Gebrauch (10+8 wie ohne Tool die 8GB) und wieder 13GB RAM (wie ohne Tool, allerdings läuft das Tool) und wieder 95 FPS wie ohne das Tool.

Vielen Dank für den Test. Jetzt wäre vielleicht noch ein direkter Vergleich zwischen "simulierten" 6 GB und 8 GB VRAM interessant, inklusive Frametimes.

Mit dem Tool sollte jetzt Jeder, der eine Grafikkarten mit mindestens 8 GB VRAM besitzt, feststellen können, ob ein Spiel mit 8 GB flüssiger läuft, als mit 6 GB. Von daher kann man sich alle Vermutungen schenken und die Sache nun endlich belegen.

 

[HicoN]

So nun zu meinen Benchmarks. Die Grafikkarte habe ich für diesen Test auf dem Standart Takt laufen lassen.

System:
i7-6700k
Evga GTX980ti Classified - 6gb Vram
32gb DDR3

Ausgangssituation: Im Metro Exodus Benchmark hatte ich bei den extreme Settings aufpoppende Texturen die ich auf den zu geringen Vram zurückführe. Besonders auffällig ist es bei der hängenden Leiche mit dem Schild am Anfang, hier ist das Schild unleserlich bis es nachgeladen wird. Ich konnte auf dem PC keinen Screenshot von der MatschTextur erstellen, da es auf den Screenshots immer nachgerendert wurde. Hierfür wird wohl leider ein Foto vom Bildschirm herhalten müssen. Die Benchmarks wurden sowohl unter der Treiber Version 391.01 als auch 419.17 durchgeführt. Überraschenderweise gab es KEINE Verbesserung, im extreme Setting sogar etwas langsamer.







Ob die aufploppenden Texturen am Vram liegen oder nicht kann ich nicht eindeutig sagen.

 

[HisN]

Mit dem Tool sollte jetzt Jeder, der eine Grafikkarten mit mindestens 8 GB VRAM besitzt, feststellen können, ob ein Spiel mit 8 GB flüssiger läuft, als mit 6 GB. Von daher kann man sich alle Vermutungen schenken und die Sache nun endlich belegen.

Jedenfalls die Leute mit Nvidia-Grakas. Aber laut dem Programmierer ist eine OpenCL-Variante in Arbeit.
Bin gespannt ob sich hier noch jemand mit einer 8GB-Graka die Mühe zum testen macht.

 

[Paddy92]

Und genau deshalb der Gegentest in dem ich aus meiner 24GB-Graka eine 14GB-Graka mache. Gleiche FPS, gleicher RAM-Gebrauch wie ohne das Tool. Du bist bestimmt nur beim Betrachten der Bilder durcheinander gekommen.

Ohne Tool: 8GB VRAM in Gebrauch, 95 FPS, 13GB RAM
Mit Tool eine 6GB-Graka simuliert: 24GB VRAM in Gebrauch (18 +6), 86 FPS (minus10 im Vergleich zu ohne Tool), 16GB RAM (Plus 3GB im Vergleich zu ohne Tool)
Mit Tool eine 14GB-Graka-simuliert: 18 GB in Gebrauch (10+8 wie ohne Tool die 8GB) und wieder 13GB RAM (wie ohne Tool, allerdings läuft das Tool) und wieder 95 FPS wie ohne das Tool.

Wurde das Spiel zwischendurch neu gestartet oder war es die ganze Zeit am Laufen und auf einmal wurde der VRAM geflutet?
Falls es nicht neugestartet wurde, könntest du mal testen, wie es sich verhält, wenn das Spiel von vornherein "weiß", dass nur 6 GB frei sind?

 

[HisN]

Wurde jedes mal neu gestartet. Und ich habe weder die Settings geändert, noch die Spielfigur bewegt. Das ist Sofort nach Level-Load.

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Die OpenCL-Version ist fertig. Download-Link reiche ich nach.

 

[Tech Enthusiast]

Mit dem Tool sollte jetzt Jeder, der eine Grafikkarten mit mindestens 8 GB VRAM besitzt, feststellen können, ob ein Spiel mit 8 GB flüssiger läuft, als mit 6 GB. Von daher kann man sich alle Vermutungen schenken und die Sache nun endlich belegen.

Vorsichtig damit.
Auch wenn das Tool eine MÖGLICHE Hilfe darstellt, added es doch ein paar neue unbekannte Variablen.
Wir wissen nicht wie Game Engines mit extern geflutetem VRAM umgehen, oder auf welche Art dies passiert.

Bevor wir das also als Lösung, bzw. Hilfe betiteln, sollten wir genau untersuchen, ob wir damit das bekommen was wir auch wirklich testen wollen und nicht etwas komplett anderes.
Bin aktuell nicht daheim für ein paar Tage, aber werde da sicher ein paar Testroutinen für aufbauen und versuchen zu verifizieren was das Tool bewirkt und wie Games damit interagieren.

 

[Powl]

Ich kann mit einer midrange Karte alles auf max stellen. Früher hätte ich dazu ne high end gebraucht.

Gesendet von meinem ANE-LX1 mit Tapatalk

Kannst du schon. Läuft dann halt nicht mehr flüssig. So wie früher auch schon.

- - - Updated - - -

Fehlende Rechenleistung um Texturen zu verarbeiten führt zu Downscaling der Texturen (was dann matschig wirkt), um sie verarbeiten zu können.

Quark. Die Texturen vor dem Sampling zu skalieren, würde ja noch mehr Rechenleistung brauchen. Wenn eine Texture matschig gesampled wurde, dann, weil noch keine höher aufgelöste Version der Textur geladen war.

 

[Dani79]

Kannst du schon. Läuft dann halt nicht mehr flüssig. So wie früher auch schon.

OK. Läuft alles flüssig hier. Vertrau mir.

Gesendet von meinem ANE-LX1 mit Tapatalk

 

[Powl]

OK. Läuft alles flüssig hier. Vertrau mir.

Gesendet von meinem ANE-LX1 mit Tapatalk

Jedes Spiel? Klar.

 

[Dani79]

Jedes Spiel? Klar.

Ja. Metro exodus und sottr sind die einzigen das ich in 1080p spiele.
Ich zähle jetzt nicht alle anderen auf.

Gesendet von meinem ANE-LX1 mit Tapatalk

 

[Tech Enthusiast]

Quark. Die Texturen vor dem Sampling zu skalieren, würde ja noch mehr Rechenleistung brauchen. Wenn eine Texture matschig gesampled wurde, dann, weil noch keine höher aufgelöste Version der Textur geladen war.

Habe evtl. unklare Begriffe benutzt.
ResolutionScale ist eine Technik die in manchen Games (Ark z.B.) als Option zur Verfügung steht.
Damit kann man in Prozent angeben wie viel Auflösung verwendet werden soll. Die Speicherbelegung sinkt damit indirekt, aber proportional.

Konsolen nutzen dies z.B. automatisch. Gab da mal ne ganze Reihe an Berichten welche Konsole in welchem Game mit welcher Auflösung agiert und wie oft / lange.
Die Auflösung wurde da relativ häufig angepasst, ganz automatisch und während des Spielens.

Eine sehr ähnliche, wenn nicht identische, Funktion gibt es in jeder mir bekannten Engine. Man muss sie halt aktivieren. Nicht jeder Nutzer am PC wäre damit happy, wenn sein Game selber entscheidet, welche Auflösung verwendet wird.
Der Teil, der entscheidet welche Texturen in welchem Umfang skaliert werden, ist hingegen stark verbreitet. Ein Texturscaling bekommt man meist kaum bis gar nicht mit. Ein Auflösungsscaling sieht direkt wie ekliger Matsch aus.
Wenn man in Ark z.B. 1440p einstellt und dann Scale auf 70% stellt, sieht das echt nicht schick aus. Einfach direkt 1080p zu nehmen wirkt angenehmer, obwohl es rechnerisch weniger Pixel sind als 70% von 1440p.

Ich hoffe wir müssen hier aber nicht wegen Begrifflichkeiten diskutieren und damit vom eigentlichen Punkt abkommen.
Diese Scalingdinger passen natürlich zwei Sachen an und sind so kaum auf PC zu finden, aber wir interessieren uns nur für den Teil der Texturen.

Relevant ist hier der Gedanke, dass Rechenleistung verloren gehen würde durch die Skalierung. Dem ist nicht so, da Texturen Pixel für Pixel berechnet werden.
Wenn man bei einem 50% Scaling einfach sagt, dass nur jeder zweite Pixel berechnet wird, kostet das keine Leistung, sondern halbiert den Aufwand. Die "Routine" nur jeden zweiten Pixel zu beachten kann als nichtiger Performanceaufwand abgetan werden. Wir reden hier über Bruchteile von Nanosekunden.
Die "mastchigen" Outputs entstehen genau dadurch, dass diese Skalierungsmethoden eben nicht berechnen was "die richtigen" Pixel sind, sondern stur agieren. Gerade bei ungeraden Werten wie 70% sind dann 7/10 Pixeln vorhanden, ohne zu wissen wie wichtig diese 3 fehlenden Pixel für das Ergebnis waren, bzw. welche der 10 Pixel wegfallen.

Das Ergebnis ist in den meisten Fällen also unschön.
Das man dem entgegenwirkt indem man die Texturen reduziert ist absolut kein Indiz für ein VRAM Problem, sondern ergibt sich aus der sinkenden Rechenpower die dann benötigt wird.
Das Ergebnis bei nativen 50% Texturen ist einfach besser als bei skalierten 50% Texturen. Die Rechenleistung ist dieselbe. Es ist aber verständlich, wieso der erste Gedanke auf den Speicher fällt, weil man ja die Texturen anpasst. Ohne Verständnis des Grundes liegt der Gedanke nahe, dass die Problematik im Speicher passiert.

- - - Updated - - -

Hier noch eine Grafik von Guru3d, da wir aktuell ja öfter von Metro sprechen.
Sie zeigt die VRAM Belegung zwischen 1080p und 4k.

Selbst auf 4k landen wir nur knapp über 5gb. Und weder low-end noch mid-range GPUs sind wohl für 4k@maxed Settings gedacht.
Und nochmal: Genau diese GPUs sind Bestandteil der Überlegungen dieses Topics. Bei echten 4k GPUs reden wir eh über Kunden, denen die Preise größtenteils egal sind.

- - - Updated - - -

Und hier der Teil zur 1080p Leistung in Metro.
Eine 980TI kommt auf 42FPS, eine 2060 auf 55fps.

Framespikes und FPS auf VRAM zu schieben, wenn die Rohleistung in diesem Titel nicht mal für solide FPS ausreichend ist, ist absolut nicht hilfreich.
Um eine Analyse von VRAM sinnvoll zu machen, müssen wir andere Faktoren ausgrenzen, nicht noch mehr Unbekannte zur Formel adden. Ich denke, da sind wir uns alle einig, oder?

 

[Goderion]

Vorsichtig damit.
Auch wenn das Tool eine MÖGLICHE Hilfe darstellt, added es doch ein paar neue unbekannte Variablen.
Wir wissen nicht wie Game Engines mit extern geflutetem VRAM umgehen, oder auf welche Art dies passiert.

Bevor wir das also als Lösung, bzw. Hilfe betiteln, sollten wir genau untersuchen, ob wir damit das bekommen was wir auch wirklich testen wollen und nicht etwas komplett anderes.
Bin aktuell nicht daheim für ein paar Tage, aber werde da sicher ein paar Testroutinen für aufbauen und versuchen zu verifizieren was das Tool bewirkt und wie Games damit interagieren.

Ja, da war ich etwas euphorisch und zu begeistert. ^^
Die Hoffnung ist auf jeden Fall größer, dass es bald "klarer" sein könnte, inwiefern sich 8 statt 6 GB auszahlen würden.

Habe evtl. unklare Begriffe benutzt.
ResolutionScale ist eine Technik die in manchen Games (Ark z.B.) als Option zur Verfügung steht.
Damit kann man in Prozent angeben wie viel Auflösung verwendet werden soll. Die Speicherbelegung sinkt damit indirekt, aber proportional.

Meinst Du "Dynamic Resolution"? Also wenn die "Luft ausgeht", wird im Hintergrund eine niedrigere Auflösung verwendet.

Der Teil, der entscheidet welche Texturen in welchem Umfang skaliert werden, ist hingegen stark verbreitet. Ein Texturscaling bekommt man meist kaum bis gar nicht mit. Ein Auflösungsscaling sieht direkt wie ekliger Matsch aus.

Ich bin mir nicht sicher, was oder wie Du das meinst. Texturen werden so gesehen nie skaliert, außer beim Laden in den Speicher (z.B. Mip Mapping). Ist die Textur erstmal im VRAM, bleibt die in der Regel so wie sie ist. Die Textur wird dann beim Rendern genutzt um sie "über" ein Dreieck zu "ziehen" (Rasterisation), dabei wird natürlich auch in gewisser weise skaliert.

Wenn man in Ark z.B. 1440p einstellt und dann Scale auf 70% stellt, sieht das echt nicht schick aus. Einfach direkt 1080p zu nehmen wirkt angenehmer, obwohl es rechnerisch weniger Pixel sind als 70% von 1440p.

2560x1440 wäre bei 70% 1792x1008. Ein gerenderter Pixel repräsentiert so 1,43 Pixel. Werden dann die gerenderten 1792x1008 Pixel auf 2560x1440 hochskaliert, braucht man schon eine sehr gute Interpolation, damit das nicht nach Grütze ausschaut. Nimmt man direkt 1920x1080, obwohl der Monitor nativ 2560x1440 Pixel hat, sieht das auch nur wirklich besser aus, wenn man im exklusiven Vollbildmodus ist, weil dann der Monitor die Interpolation vornimmt. So richtig verstanden habe ich das nicht, aber so habe ich es bis jetzt immer bei mir beobachtet.

Wenn man bei einem 50% Scaling einfach sagt, dass nur jeder zweite Pixel berechnet wird, kostet das keine Leistung, sondern halbiert den Aufwand. Die "Routine" nur jeden zweiten Pixel zu beachten kann als nichtiger Performanceaufwand abgetan werden. Wir reden hier über Bruchteile von Nanosekunden.

Was ist mit 50% gemeint? Die Auflösung in der gerendert wird? Wie gesagt, das läuft über die Rasterisation. Es ist nicht so entscheidend, wie groß die Textur ist, sondern wie viele Pixel ich von ihr benötige. Je größer das Polygon/Dreieck ist, und damit mehr Pixel ausfüllt, desto länger dauert es, es zu "füllen".

Framespikes und FPS auf VRAM zu schieben, wenn die Rohleistung in diesem Titel nicht mal für solide FPS ausreichend ist, ist absolut nicht hilfreich.
Um eine Analyse von VRAM sinnvoll zu machen, müssen wir andere Faktoren ausgrenzen, nicht noch mehr Unbekannte zur Formel adden. Ich denke, da sind wir uns alle einig, oder?

Ne! ;-) Gibt es andere Gründe von Spikes außer das Nachladen von Ressourcen? Nehmen wir mal an, ich gebe einer GTX 970 32 GB VRAM, warum sollte es dann aufgrund der GPU zu Spikes kommen? Ich bin mir da gerade auch nicht so ganz sicher, bzw. klar, daher meine Frage.

 

[Dani79]

Und hier der Teil zur 1080p Leistung in Metro.
Eine 980TI kommt auf 42FPS, eine 2060 auf 55fps.

Framespikes und FPS auf VRAM zu schieben, wenn die Rohleistung in diesem Titel nicht mal für solide FPS ausreichend ist, ist absolut nicht hilfreich.
Um eine Analyse von VRAM sinnvoll zu machen, müssen wir andere Faktoren ausgrenzen, nicht noch mehr Unbekannte zur Formel adden. Ich denke, da sind wir uns alle einig, oder?

Der Test zeigt aber eben auch das die 2070 mit 8GB nur 5 fps mehr macht. Ist das jetzt CPU Limit?

 

[Tech Enthusiast]

Was ist mit 50% gemeint?

Rein fiktives Beispiel wieviel von den texturen im Speicher benutzt wird.
Ist im Speicher eine 4k Textur, würde man bei 50% halt jeden zweiten Pixel für das eigentliche Bild benutzen und die anderen 50% einfach ignorieren um die benötigte Rechenleistung zu reduzieren.

Ne! ;-) Gibt es andere Gründe von Spikes außer das Nachladen von Ressourcen? Nehmen wir mal an, ich gebe einer GTX 970 32 GB VRAM, warum sollte es dann aufgrund der GPU zu Spikes kommen? Ich bin mir da gerade auch nicht so ganz sicher, bzw. klar, daher meine Frage.

Ja natürlich gibt es andere Gründe!
Vor allem die Rohleistung und Spikes in benötigter Leistung. Wenn die GPU 200 fps packt, aber nur 60fps anzeigen muss, dann bemerkt man spikes wohl nie. Wenn die GPU aber mit biegen und brechen 60fps packt, dann kurz die doppelte Leistung abgefragt wird, ergibt sich ein Spike auf 30fps.

Vergleiche dazu den Test von Don (oben verlinkt von mir, Seite 5 glaube).
Sowohl RTX 2080 als auch Radeon 7 haben in den Tests Framespikes. Und beide haben dies sowohl im VRAM Limit, als auch wenn sie NICHT im Limit sind.
Lustiger Weise hat die Radeon 7 sogar bis zu 50% mehr Spikes, obwohl sie 2x so viel Speicher hat und HBM2 eigentlich auch besser sein sollte als GDDR6.

Spikes kommen also mit Nichten nur wegen Grafikspeicher zustande.

 

[Goderion]

Wenn die GPU aber mit biegen und brechen 60fps packt, dann kurz die doppelte Leistung abgefragt wird, ergibt sich ein Spike auf 30fps.

Aber was führt zu dieser kurzzeitig doppelt benötigten Leistung? Wenn alle Ressourcen (Texturen und Modelle) bereits im VRAM sind, was verursacht die Spikes? Es geht ja auch nur um Spikes, nicht um Szenen, die generell aufgrund der Komplexität (hohe Anzahl Polygone, etc.) hohe Rechenleistung erfordern und damit durchgehend weniger Frames möglich machen. Ich habe darüber vorher noch nie so richtig nachgedacht, aber mir fällt echt nix anderes ein, außer das Laden von Ressourcen.

 

[Tech Enthusiast]

Diese Ressourcen müssen ja nicht nur geladen sein und im Speicher liegen. Sie müssen berechnet werden.
Genau da entsteht die benötigte Rechenleistung.

Eine Ressource im Speicher ist ja kein fertiges Objekt im Game, sondern nur eine Textur. Soweit mir bekannt sogar immer in 2D und oft einfach nur ein Viereck, wie ein Blatt mit Bildern / Texturen halt.
Die GPU berechnet dann, welcher Teil der Texturen auf ein 3D Objekt gezeichnet wird, wie das aussieht... und welchen Teil dieses 3D Objekts man überhaupt sieht.

Eine Leistungsspitze wird dann benötigt, wenn man in kurzer Zeit sehr viele neue Berechnungen machen muss.
z.B. schnelle Drehungen in einem RPG.
Die Texturen des ganzen Gebietes sind im VRAM, aber berechnet wird nur, was man sieht. Durch die schnelle Drehung ändert sich an den VRAM Daten gar nichts, aber es muss eine komplett neue Zusammenstellung aus diesen Texturen berechnet werden. Dadurch entsteht ein Spike.
Wenn genug Spielraum zur Verfügung steht, bemerkt das ein Spieler nicht. Wenn die GPU am Limit läuft, bemerkt man es dafür umso mehr.
Darum macht eine GPU die gerade so 60fps packt auch wenig Sinn für flüssiges Spielen. 80-90 sollten es je nach Game schon sein, damit man eben nicht unter 60fps dropped, wenn es zu einer schlagartigen Neuberechnung kommt.

VRAM ist wirklich nichts anderes als ein sehr schneller Zwischenspeicher, damit die GPU nicht auf langsamere SSDs, oder RAM warten muss.

 

[Dani79]

80 bis 90 fps halte ich für übertrieben, aber prinzipiell stimme ich dir zu. Mit ach und krach 60 reicht nicht.

Gesendet von meinem ANE-LX1 mit Tapatalk

 

[Goderion]

Eine Ressource im Speicher ist ja kein fertiges Objekt im Game, sondern nur eine Textur. Soweit mir bekannt sogar immer in 2D und oft einfach nur ein Viereck, wie ein Blatt mit Bildern / Texturen halt.

Korrekt, eine Textur ist im Prinzip ein Bild.

Die GPU berechnet dann, welcher Teil der Texturen auf ein 3D Objekt gezeichnet wird, wie das aussieht... und welchen Teil dieses 3D Objekts man überhaupt sieht.

Das passiert in jedem Frame immer und immer wieder.

Eine Leistungsspitze wird dann benötigt, wenn man in kurzer Zeit sehr viele neue Berechnungen machen muss.
z.B. schnelle Drehungen in einem RPG.
Die Texturen des ganzen Gebietes sind im VRAM, aber berechnet wird nur, was man sieht. Durch die schnelle Drehung ändert sich an den VRAM Daten gar nichts, aber es muss eine komplett neue Zusammenstellung aus diesen Texturen berechnet werden. Dadurch entsteht ein Spike.

Wenn alle Texturen und alle Modelle im VRAM sind, muss da nichts neues berechnet werden. Eine Engine verfügt immer über eine Technik, um aufgrund der Position und Ausrichtung des Spielers schnell festzustellen, was gezeichnet werden muss, und was nicht. (z.B. Binary Space Partitioning, Portal-Based Rendering, Octree)

Wenn ich per 3D-API etwas zeichnen möchte, gebe ich die Koordinaten und Ausrichtung der Kamera an, Modell und Textur wird nicht angetastet. Modelle und Texturen werden nur aufgrund der Kameraposition/Perspektive gerendert. Dieses Vorgehen ermöglicht z.B. das Zeichnen von hundert Panzern an unterschiedlichen stellen im Level, ohne das Panzer-Modell oder dessen Textur zu ändern.

Ich programmiere selber und habe mir auch schon einige 3D-Engines angesehen, da ich das aber nicht professionell mache, ist mein Wissen auch nicht entsprechend gut genug, um das wirklich vollständig zu verstehen. Damit will ich eigentlich nur sagen, dass ich hier bereits über meinen Horizont hinaus diskutiere. ;-)
Vielleicht recherchiere ich das mal genauer, was zu Spikes führt, die nicht auf das Nachladen von Ressourcen begründet sind.

 

[Tech Enthusiast]

Update mit dem VRAM Allocator Tool.

Disclaimer:
Die Ergebnisse sind mit einer stark undervolteten und underclocked 2080TI entstanden. Ich habe sie nicht ganz auf 2080 oder lower gebracht, wollte aber etwas Leistung raus nehmen um den Brute Force Gedanken zu reduzieren.
Des Weiteren sind die Ergebnisse auf meinem Rechner, gut 600 km entfernt per Remote Zugriff entstanden. Ich werde die Ergebnisse verifizieren, sobald ich Freitag nach Hause komme und ggf. updaten, wenn Abweichungen auftreten.

Getestet wurde mit dem Shadow of the Tomb Raider Benchmark, meist in 1440p auf Ultra Settings. Ultra ist nicht maxed. Man kann weitere Regler nach Rechts drehen, es handelt sich aber um das höchste Preset.
Für Vergleichbarkeit wollte ich nicht zu sehr von einem fest definierten Standard abweichen.
System Specs sind größtenteils auf den Benchmark Screens ersichtlich.
Die Screenshots beinhalten zwei Bildschirme, daher kann man rechts immer gut sehen, was mit VRAM Allocator eingestellt war und der Afterburner Hardware Monitor zeigt die Speicher und Ramkurven.

Getestet wurde mit 0 VRAM Allocation, 3000, 5000, 7000 und 7000 in 1080p. Jeweils 3 Testläufe. Gewertet wurde der jeweils "schlechteste", kein Mittel.


Hier die Ergebnisse:
Normal - 11gb

Frames: 11083
FPS: 74
VRAM: Max 6931
Ram: Max 9517

Minus 3000 - 8gb

Frames: 11427
FPS: 75
VRAM: Max 9722
Ram: Max 9546

Minus 5000 - 6gb

Frames: 10997
FPS: 74
VRAM: Max 11196
RAM: Max 9729

Minus 7000 - 4gb

Frames: 11756
FPS: 77
VRAM: Max 11243
RAM: Max 11605

Minus 7000 - 4gb / 1080p

Frames: 13451
FPS: 88
VRAM: Max 11246
Ram: Max 13702


Betrachtung der Daten:
1. Die FPS waren bei allen Settings, bis hin zu 7gb Allocation, im Rahmen von Messtoleranzen. Die 7gb belegt Variante hat sogar ein paar FPS mehr erzeugt lustigerweise.
2. Ab 5gb Allocation hat sich die RAM Belegung leicht erhöht. Es sind nur 180mb, also könnte das auch eine anders bedingte Schwankung sein. Es ist aber notiert.
3. Ab 7gb Allocation hat sich die RAM Belegung deutlich erhöht. Der belegte RAM ist um fast 2gb gestiegen.
4. Bei 7gb Allocation in 1080p ist überraschenderweise die RAM belegung um WEITERE 2gb gestiegen, gegenüber dem sonst identischen Test in 1440p. Eine Erklärung habe ich dafür auf die Schnelle nicht, die Tatsache habe ich aber 3x verifiziert.

Takeaways:

• Ich konnte keinen FPS Einbruch durch Auslagerung in den RAM feststellen und die Auslagerung schien verwirrend.
• Das bei 1080p mehr ausgelagert wird als bei 1440p lässt evtl. auf eine Wechselwirkung mit dem VRAM Allocator schließen, was schade wäre, da dann diese Tests hinfällig sind.
• Da die FPS konstant waren, bis hin zu simulierten 4GB VRAM, kann man wohl darauf schließen, dass belegter VRAM weit weg von benötigtem VRAM ist. Die Texturen im normalen Arbeitsspeicher haben die Leistung nicht mal im Ansatz reduziert, weshalb man davon ausgehen kann, dass sie nie benutzt worden sind. Die Speicherbandbreite und das Texturstreaming scheinen also die geringe VRAM-Menge perfekt kompensiert zu haben. So perfekt, dass das schlechteste 4GB Ergebnis sogar 3FPS mehr geliefert hat als das schlechteste 11GB Ergebnis.

Eine Analyse der Frametimes habe ich vorerst nicht gemacht, da das gefriemel über Remote Desktop nerfig ist.
Da die End FPS ein Durchschnitt sind, ist aber nicht davon auszugehen, dass es harte Spikes gab. Wenn dem so wäre, dürfte die 4GB Variante nicht so gute Durchschnittswerte liefern.
Dazu kommt, dass ich, wie in den Screenshots zu sehen, im Overlay die Frametimes beobachtet habe. Auch wenn das natürlich eine ungenügende Aussage ohne Nachweis ist: Es gab keine unnatürlichen Spikes zu sehen.
Den Beweis trete ich dann an, wenn ich wieder selber am PC sitze.

Aufgrund dieser Daten sehe ich also aktuell weiterhin keinen gesteigerten Bedarf an Unmengen von VRAM.
Shadow of the Tomb Raider gehört zu den wenigen Games die überhaupt 6gb belegen in 1440p, also wird die breite Masse an Games wohl weniger benötigen.
Ein User der durch irgendwelche versteckten Regler und ini-Dateien, Treibersettings und Extra Texturen die Games hochzüchtet, wird wohl keine 200 bis 300 Euro GPU anschaffen. Und selbst wenn: Warum sollte die breite Masse an Käufern deswegen draufzahlen bei dieser GPU, statt dieser Randgruppe?

- - - Updated - - -

Wenn alle Texturen und alle Modelle im VRAM sind, muss da nichts neues berechnet werden.

Gegenfrage:
Wenn das korrekt wäre, wofür gibt es dann die eigentliche GPU?
Wieso ist es dann nicht nur eine simple Hardware, die Daten in den VRAM schaufelt? Wieso gibs die GPU Cores?

Ich wüsste nicht, wie Speicher alleine irgendwas berechnen soll. VRAM hat keinen Controller, der groß genug wäre um komplexe Berechnungen durchzuführen.
Die Berechnungen werden natürlich im GPU Core gemacht. Darum steigen die FPS ja auch, wenn man die GPU Cores OCed. Bei Speicher OC entstehen deutlich weniger Vorteile für die FPS.
Genau genommen ist es bei meiner GPU egal ob ich 7000 oder 8000 einstelle beim Speicher. Die FPS bleiben innerhalb von Messtoleranz, leider. :-(


Edit:
Zu den Frametimes -> Man sieht in den Screenshots, dass es keine Spikes gab die über ~ 18ms gegangen sind. Nicht ein Ausreißer nach oben.
Die kleineren Spikes und das "zick-zack" bewegt sich in Bereichen von 6-9ms, was ca. 100-110 fps entsprich. 16,6ms entsprechen 60fps.

 

[fdsonne]

Texturen benötigen Rechenleistung, nicht "nur VRAM".
VRAM speichert die Testuren nur für einen schnelleren Zugriff, da er schneller ist als ne SSD, oder RAM.
Die Rohleistung der GPU muss diese Texturen dann aber in bewegte Bilder übersetzen. Das wird zu 100% durch die Rohleistung gemacht.

Das ist ziemlicher Unsinn.
Die absolute Datenmenge spielt (sofern genug Bandbreite vorhanden) eine untergeordnete Rolle. Man kann das klar messen, aber die Unterschiede sind extrem gering. Soll heißen, es ist hupe ob du nun 2GB oder 20GB VRAM belegst und diese Belegung rein durch höher aufgelöste Texturen kommt. An den FPS/der Leistung ändert sich quasi gar nichts... Nicht hoch und auch nicht runter. Runter gehts erst, wenn der Speicher zu knapp wird.

Also ich würde es mal so formulieren:
Wenn ich ROTTR in FHD in MAX-OUT zocken möchte, und dabei gerne so viele FPS wie möglich hätte, dann würde bei MEINEM Desktop eine 6GB-Karte MEIN Ziel nicht erreichen, weil zu wenig VRAM die Leistungsentfaltung der Karte eventuell stören könnte. Und das lustigerweise sogar im CPU-Limit.

Das hätte ich dir aber auch schon vorher sagen können. RotTR läuft nicht gut mit 6GB. Overall kann man das zwar damit spielen, aber Szenenweise/Phasenweise gibts üble Framedrops bis deutlich niedrigere FPS. Die Stelle im Spiel wo mir das zum aller ersten mal aufgefallen ist, ist die, wo man das erste mal auf einen Bär trifft -> unmittelbar dahinter gibts nen Ausguck mit dem Blick auf das Sowjet Lager. Die Stelle lief bei mir nicht mit 6GB VRAM. Drop auf um die 20FPS.

Und der Gegentest mit 10GB weniger VRAM, damit nicht jemand sagt, dass es das Tool ist, das die Rechenzeit klaut. Man sieht auch dass wieder weniger RAM genutzt wird (weil ja kein VRAM mehr fehlt).

...

Und jetzt muss man nur seine Definition von "reicht aus" überdenken, bzw. deutlich formulieren. Und zwar mit dem Gedanken im Hinterkopf, das meistens die Graka mit dem schmalen VRAM auch auf System laufen, die nicht gerade üppig mit Hauptspeicher ausgestattet sind.
Was sagt ihr?

Ich halte diese Art von Test (also das externe belegen von VRAM) nur für bedingt vergleichbar.
Denn die alles entscheidende Frage dabei ist, belegt das Spiel Speicher anhand der real freien Speichermenge oder belegt es Speicher anhand der eigentlich physisch vorhandenen Speichermenge?

Simples Beispiel. Sollte das Spiel davon ausgehen, dass bei dir 24GB vorhanden sind und dann entsprechend versuchen anhand dieser Erkenntnis keine Ahnung, sagen wir 10GB Menge an Daten da rein zu pumpen, die ja klar rein pumpen kann, wenn die 24GB Speicher ansatzweise frei wären, dann ist auch klar verständlich, dass es der Hardware schwer fallen wird, wenn du ihr dann nur noch 6GB oder so freien Speicher über lässt...

Wir wissen ja länger schon, dass die absolut belegte Menge häufig höher ausfallen wird, wenn mehr Speicher vorhanden ist. Interessant wäre jetzt die Antwort auf die Frage, ob ein Spiel auch mehr Speicher belegt, wenn zwar mehr Speicher physisch vorhanden, aber im Hintergrund irgendwo belegt ist??

PS: ein zweiter Grund, warum externe Speicherbelegung ggf. ungünstig ist, ist die Tatsache, dass VRAM auslagerbar ist -> Die Hardware ist in der Lage Daten auszulagern, wenn voll. Das geht in den RAM - klar. Aber das Problem dabei ist, dass dieses Auslagern ungeordnet passiert. Ich kann dir aus dem Hut jetzt nicht die Bedingungen dafür aufzählen, aber es sieht klar so aus, als schmeißt das System einfach wahllos Daten raus. Heist also, es kann gar passieren, dass Daten vom aktiven Spiel rausfliegen, weil die Software im Hintergrund irgendwie mehr die Finger drauf hat wie das Spiel/die Engine auf ihre Daten und sich der Negativeffekt sogar noch verschärft respektive stärker sichbar ist als bei Hardware, wo physisch nur so viel Speicher vorhanden wären...

Habe evtl. unklare Begriffe benutzt.
ResolutionScale ist eine Technik die in manchen Games (Ark z.B.) als Option zur Verfügung steht.
Damit kann man in Prozent angeben wie viel Auflösung verwendet werden soll. Die Speicherbelegung sinkt damit indirekt, aber proportional.

Wirf doch bitte nicht wahllos irgendwelche Themen in einen Topf.
Resolution Scale im Beispiel von Ark ist eine Feature, was es händisch zu aktivieren gilt.
Im Beispiel von Konsolen wird sowas benutzt um auf einer Ziel-Framerate recht genau anzukommen. Es wird also dynamisch Leistung eingespart.

Dabei geht es aber nicht um VRAM - dabei geht es um GPU Leistung. Das Thema ist auf dem PC auch alles andere als üblich - eher total unüblich, denn man sieht einem Spiel recht schnell an, wenn mit solchen Tricks versucht wird Leistung zu generieren. Das Bild ist nämlich nicht mehr aufs Pixel genau scharf. Bei Konsolen versucht man diesen Trick mit einem anderen Trick zu unterdrücken -> man legt massiv einen Weichzeichner drüber, der die Konturen (vor allem in der Weitsicht) deutlich unschwarf zeichnet. Konsolenports auf dem PC machen das idR auch - manchmal sieht man das auch bei zu krassen Sprüngen im LOD System.

 

[Goderion]

Gegenfrage:
Wenn das korrekt wäre, wofür gibt es dann die eigentliche GPU?
Wieso ist es dann nicht nur eine simple Hardware, die Daten in den VRAM schaufelt? Wieso gibs die GPU Cores?

Die GPU übernimmt die Rasterisation. Aufgrund von Kamera + Geometriedaten/Modell + Textur rendert die GPU das Modell. Diese Rasterisation wird für jedes Frame neu ausgeführt. In dem Panzer-Beispiel gibt es ein Panzer-Modell und eine Panzer-Textur. Ich sage per API wo die Kamera ist und wo sie hinguckt und dann soll sie den Panzer rendern. Der Panzer selber hat normalisierte Koordinaten, z.B. ist die Mitte/Zentrum vom Panzer der XYZ-Nullpunkt.

Man kann sich das so vorstellen, als hätte man einen Raum der komplett wie ein Greenscreen ist, und in der Mitte steht ein Panzer auf einem grünen Podest. Jetzt gehe ich mit einer Kamera in den Raum und mache aus unterschiedlichen Positionen ein Foto. Jetzt nehme ich mir eine Landschaft und lege alle Panzer-Bilder übereinander. Im fertigen Bild habe ich jetzt mehrere Panzer in unterschiedlichen Positionen und Ausrichtungen, obwohl es eigentlich immer der gleiche Panzer war, den ich abfotografiert habe.

Diese Berechnung kostet je nach Anzahl der Dreiecke/Polygone Performance. Je stärker die GPU, desto mehr Panzer kann sie in einer bestimmten Zeit rendern. Eine GPU erledigt dazu auch noch zahlreiche andere Dinge, wie z.B. Shader. Das passiert aber in jedem Frame immer und immer wieder.

Aber wie gesagt, mein Wissen ist erschöpft. Irgendwas muss es ja geben, wenn es Spikes gibt, obwohl genug VRAM vorhanden ist.

 

[HisN]

Da das VRAM inzwischen virtualisiert ist könnte ich mir gut vorstellen dass das Programm gar nicht weiß wie viel freier Speicher auf meiner Grafikkarte vorhanden ist. Aber da ich kein Game-Programmierer bin, ist das natürlich auch nur eine Vermutung. Und wir testen ja auch in anderen Foren, wenn z.b. sowieso zu wenig VRAM vorhanden ist, dann scheint das System "nicht benutzte" Daten (wie üblich) zuerst auszulagern, was natürlich auch auf das VRAM zutrifft. Da ist ja ein dicker Block der praktisch nur rumliegt, der wird als erstes ausgelagert.

 

[Goderion]

Simples Beispiel. Sollte das Spiel davon ausgehen, dass bei dir 24GB vorhanden sind und dann entsprechend versuchen anhand dieser Erkenntnis keine Ahnung, sagen wir 10GB Menge an Daten da rein zu pumpen, die ja klar rein pumpen kann, wenn die 24GB Speicher ansatzweise frei wären, dann ist auch klar verständlich, dass es der Hardware schwer fallen wird, wenn du ihr dann nur noch 6GB oder so freien Speicher über lässt...

Daran habe ich auch schon gedacht. Eigentlich wäre das ziemlich unklug, so vorzugehen und nicht einfach den frei verfügbaren Speicher abzufragen. Aber was ich alles schon für "Qualcode" gesehen habe, würde ich da nicht gegen wetten. ;-)

PS: ein zweiter Grund, warum externe Speicherbelegung ggf. ungünstig ist, ist die Tatsache, dass VRAM auslagerbar ist -> Die Hardware ist in der Lage Daten auszulagern, wenn voll. Das geht in den RAM - klar. Aber das Problem dabei ist, dass dieses Auslagern ungeordnet passiert. Ich kann dir aus dem Hut jetzt nicht die Bedingungen dafür aufzählen, aber es sieht klar so aus, als schmeißt das System einfach wahllos Daten raus. Heist also, es kann gar passieren, dass Daten vom aktiven Spiel rausfliegen, weil die Software im Hintergrund irgendwie mehr die Finger drauf hat wie das Spiel/die Engine auf ihre Daten und sich der Negativeffekt sogar noch verschärft respektive stärker sichbar ist als bei Hardware, wo physisch nur so viel Speicher vorhanden wären...

Also brauchen wir doch ein Programm, dass sich zwischen Anwendung und Treiber setzt und dem Spiel weniger VRAM vorgaukelt.

 

[Tech Enthusiast]

Das ist ziemlicher Unsinn.
Die absolute Datenmenge spielt (sofern genug Bandbreite vorhanden) eine untergeordnete Rolle. Man kann das klar messen, aber die Unterschiede sind extrem gering. Soll heißen, es ist hupe ob du nun 2GB oder 20GB VRAM belegst und diese Belegung rein durch höher aufgelöste Texturen kommt. An den FPS/der Leistung ändert sich quasi gar nichts... Nicht hoch und auch nicht runter. Runter gehts erst, wenn der Speicher zu knapp wird.

Ist das nicht genau das was ich die ganze Zeit sage?
[(Absolute Menge < Bandbreite) if (Absolute Menge > gleichzeitig benutzter Menge)]
Wo genau ist meine Beschreibung ziemlicher Unsinn, aber wenn Du es mit anderen Worten sagst ist es richtig?

RotTR läuft nicht gut mit 6GB. Overall kann man das zwar damit spielen, aber Szenenweise/Phasenweise gibts üble Framedrops bis deutlich niedrigere FPS. Die Stelle im Spiel wo mir das zum aller ersten mal aufgefallen ist, ist die, wo man das erste mal auf einen Bär trifft -> unmittelbar dahinter gibts nen Ausguck mit dem Blick auf das Sowjet Lager. Die Stelle lief bei mir nicht mit 6GB VRAM. Drop auf um die 20FPS.

Woher weißt Du so genau, dass diese Szene nicht einfach nur deutlich mehr Rechenleistung benötigt um den Frame zu erzeugen, weil in dem Moment schlagartig verdammt viele Texturen zu einem neuen Frame werden müssen und deswegen auf 20fps droppt?
Woran machst Du fest, dass die Rohleistung sich langweilt und auf den VRAM warten muss? Wird in diesem Moment die GPU Auslastung mit unter 97% angezeigt?
Woran erkennst Du, dass es kein Problem mit dem Speichermanagement ist, bei dem das Streaming fälschlicherweise davon ausgeht, dass die dort verwendeten Texturen nicht "nahe genug" am Toon sind um relevant zu sein und deswegen nicht preloaded werden?

Viele Fragezeichen um eine einzelne Situation auf einen einzelnen Faktor zu begrenzen. Da müssten wir schon erst mal alle anderen Faktoren ausschließen um das einfach so hinzunehmen.
Ziel soll ja sein das Ganze in sinnvollen Relationen zu betrachten und eben nicht mit dem alten "Mehr ist mehr!" daherzukommen.

Ich halte diese Art von Test (also das externe belegen von VRAM) nur für bedingt vergleichbar.
Denn die alles entscheidende Frage dabei ist, belegt das Spiel Speicher anhand der real freien Speichermenge oder belegt es Speicher anhand der eigentlich physisch vorhandenen Speichermenge?

Leider bedingt richtig.
Ich finde in Unreal keine Option das zu unterscheiden. Gehe also davon aus, dass man das als Entwickler nicht ändern kann und wir nicht einwandfrei prüfen können welche der zwei Varianten es ist.
In den Shadow of the Tomb Raider Tests wurden immer genau gleich viele Texturen geladen, egal wieviel ich vorher belegt habe. Daher wird wohl der absolute physisch vorhandene Speicher als Berechnungsgrundlage genommen.
Um das zu verifizieren müssen aber mehr Beispiele her.

Heist also, es kann gar passieren, dass Daten vom aktiven Spiel rausfliegen, weil die Software im Hintergrund irgendwie mehr die Finger drauf hat wie das Spiel/die Engine auf ihre Daten und sich der Negativeffekt sogar noch verschärft respektive stärker sichbar ist als bei Hardware, wo physisch nur so viel Speicher vorhanden wären...

Konnte ich bisher nicht so verifizieren.
Ausgelagerte Texturen haben die Game Performance nicht beeinflusst.
Nehme an, dass dies wie bei Punkt 1 auf die Bandbreite zurückzuführen ist. Sie sind zwar in den RAM verschoben, aber haben das Ergebnis nicht beeinflusst, weil sie vor Verwendung schon in den aktiven VRAM geladen waren.

- - - Updated - - -

Aber wie gesagt, mein Wissen ist erschöpft. Irgendwas muss es ja geben, wenn es Spikes gibt, obwohl genug VRAM vorhanden ist.

Da sind wir damit auf demselben "Endpunkt".
Es gibt genug Nachweise für Spikes ohne Limit, also können wir es nicht auf VRAM schieben.
Aber viel weiter in die Richtung müssen wir auch gar nicht. Es geht ja um den VRAM hier, nicht um andere Bereiche.
Solange wir aufhören jeden Spike stupide auf VRAM zu schieben, ist bereits einiges gewonnen.

Edit: Auch wichtig der Test von Don. Mehr Spikes, trotz mehr UND schnellerem VRAM. Starkes Indiz für ein nötiges Umdenken was potentiell idle Hardware auf budget GPUs angeht.

 

[fdsonne]

Getestet wurde mit dem Shadow of the Tomb Raider Benchmark, meist in 1440p auf Ultra Settings.

SotTR ist nicht sonderlich VRAM fressend. Im Gegensatz zum Vorgänger!
Ultra läuft auf einer 6GB Hardware, wie ich selbst schon getestet habe, sehr fluffig.

Da das VRAM inzwischen virtualisiert ist könnte ich mir gut vorstellen dass das Programm gar nicht weiß wie viel freier Speicher auf meiner Grafikkarte vorhanden ist. Aber da ich kein Game-Programmierer bin, ist das natürlich auch nur eine Vermutung. Und wir testen ja auch in anderen Foren, wenn z.b. sowieso zu wenig VRAM vorhanden ist, dann scheint das System "nicht benutzte" Daten (wie üblich) zuerst auszulagern, was natürlich auch auf das VRAM zutrifft. Da ist ja ein dicker Block der praktisch nur rumliegt, der wird als erstes ausgelagert.

Zum ersten, stimmt, aber es gibt nen Couter von non local und local Memory. Das lässt sich schon erkennen.
Aber frag mich nicht ob das wirklich getrackt wird. Ich würde behaupten mittlerweile haben die Entwickler das halbwegs im Griff - ich würde nichtmal ausschließen, dass die Hersteller da noch über den Treiber massiv drin rum fingern. Ich denke da bspw. an HBCC bei AMD. Auch wissen wir durch Berichte im Netz, dass bspw. AMD seinerzeit dediziert Personal vorgehalten hat um VRAM Mengenoptimierungen für den knappen Speicher der Fury Karten durchführen zu lassen. Anandtech hat das damals glaube ich seitens AMD erfahren. Wäre nicht verwunderlich, wenn NV das auch macht.
Ob das aber von Haus aus direkt und vollautomatisch passiert? -> ich bin skeptisch. Die Indizien sprechen eher dagehen. Das sieht man immer wieder mal bestätigt, wenn es Exotenhardware gibt. Siehe GTX 970. 4GB vorhanden, aber der Treiber versucht bei um die 3,5GB dicht zu machen. Im Resultat sieht man teilweise komische Phenomäne, wie dass ne 780TI mit 3GB bessere Frametimes raushaut als die 970, obwohl die 3GB Karte eigentlich schon eher ins VRAM Limit rennen sollte.
Das sind dann so Punkte wo ich mich frage ob da bei den Entwicklern/Engines nicht doch primär mit Targets gearbeitet wird -> 3,5GB gehörten damals da aber ganz sicher nicht dazu...


Was den zweiten Teil angeht, auch das stimmt wohl. Ich bin bei der Thematik allerdings vorsichtig, denn erfahrungsgemäß weis das Spiel nicht, was ich als Spieler als nächstes mache. Das heist, der Parameter "gewisse Zeit nicht angefasst" ist nur bedingt tauglich um Daten als gerade nicht notwendig zu deklarieren - das kann nämlich schon im nächsten Frame anders aussehen.
Hier kommt aber auch das Texturstreaming ins Thema rein. Es lässt sich zwar nicht vorher sagen wo der Spieler als nächstes hingeht/hinsieht/hinscrollt - aber durch halbwegs brauchbares Texturstreaming kann man die negativen Effekte stark abmildern. So ein System bringst du dann halt nur noch aus dem Tritt, wenn du wirklich weniger Speicher verfügbar hast, als das Streaming da als Cache vorhalten möchte.

Ist das nicht genau das was ich die ganze Zeit sage?

Nein, du behauptest: "Texturen benötigen Rechenleistung, nicht "nur VRAM"."
Das ist Unsinn. Texturen benötigen in der Form wie du es offensichtlich meinst, keine nennenswerte Rechenleistung. Oder sagen wir es anders, es ist völlig egal ob du da LowRes oder ne HighRes Texturen hast, der GPU Leistungsbedarf wird bis auf minimale Unterschied identisch bleiben.

Woher weißt Du so genau, dass diese Szene nicht einfach nur deutlich mehr Rechenleistung benötigt um den Frame zu erzeugen, weil in dem Moment schlagartig verdammt viele Texturen zu einem neuen Frame werden müssen und deswegen auf 20fps droppt?
Woran machst Du fest, dass die Rohleistung sich langweilt und auf den VRAM warten muss? Wird in diesem Moment die GPU Auslastung mit unter 97% angezeigt?
Woran erkennst Du, dass es kein Problem mit dem Speichermanagement ist, bei dem das Streaming fälschlicherweise davon ausgeht, dass die dort verwendeten Texturen nicht "nahe genug" am Toon sind um relevant zu sein und deswegen nicht preloaded werden?

Weil im selben Moment:
A) die VRAM Belegung anfängt rumzutanzen
B) die GPU Load auf weit unter 50% zusammen bricht
C) die selbe Szene/die selbe Stelle einzig mit dem Textur-BQ Regler High statt Ultra (hieß der Ultra? Könnte auch Extreme gewesen sein -> ich meine jedenfalls eine Stufe Textur-BQ runter) in weit über 60 FPS resultiert

Viele Fragezeichen um eine einzelne Situation auf einen einzelnen Faktor zu begrenzen. Da müssten wir schon erst mal alle anderen Faktoren ausschließen um das einfach so hinzunehmen.
Ziel soll ja sein das Ganze in sinnvollen Relationen zu betrachten und eben nicht mit dem alten "Mehr ist mehr!" daherzukommen.

Du hast vllt Fragezeichen, aber meine Ausführung an dieser Stelle galt ja auch nicht dir
Ich kann dir aber versichern, dass ich einer der jenigen Personen hier im Forum bin, der sich seit weit über 10 Jahren mit VRAM beschäftigt - du kannst mir durchaus glauben wenn ich sage, dass die beschriebene Stelle damals mit meinem Setup (es waren 2x 980TIs im SLI) nicht funktioniert hat und das dieses Verhalten auf VRAM Mangel zurückzuführen ist.

Konnte ich bisher nicht so verifizieren.
Ausgelagerte Texturen haben die Game Performance nicht beeinflusst.

Wenn das so wäre, dann würde es keine Nachladeruckler oder allgemein VRAM Probleme geben. In keiner Konstellation... Ich denke wir sind uns hier alle einig, dass dies auch Quatsch ist.
Ausgelagerte Texturen bedeuten dann ein Problem, wenn das Spiel/die Engine Zugirff auf diese benötigt, aber die Daten nicht im VRAM, sondern im non local Pool oder gar nicht mehr vorhanden sind.

Daran habe ich auch schon gedacht. Eigentlich wäre das ziemlich unklug, so vorzugehen und nicht einfach den frei verfügbaren Speicher abzufragen. Aber was ich alles schon für "Qualcode" gesehen habe, würde ich da nicht gegen wetten. ;-)


Also brauchen wir doch ein Programm, dass sich zwischen Anwendung und Treiber setzt und dem Spiel weniger VRAM vorgaukelt.

Zum ersten, naja kommt halt drauf an was man vorsieht. Im Gamerumfeld ist es mMn nicht gerade üblich groß Hintergrundtasks offen zu haben - vor allem keine, die die GPU noch benutzen. Das könnte ganz simpel unter "keine Notwendigkeit" fallen...

Zum zweiten, könnte mich irren, aber so ohne weiteres ist das nicht möglich.
Aber ggf. kann man tricksen? Ist zwar auch wieder nicht praxisnah, aber man könnte versuchen über sowas wie GPU Virtualisierung unterschiedliche Verhaltensweise aufzuzeigen. Ne VM mit virtuellen Ressourcen bspw. lässt sich im VRAM skalieren ohne dass man da im Hintergrund was belegen muss. Wenn mann physisch genug Speicher vorhanden ist, um all den Bedarf der vGPU abzufedern müsste das zumindest belastbare und nachvollziehbare Zahlen geben.

 

[HicoN]

So kleiner Nachtrag zu meinem Metro Exodus Benchmark. Ich habe jetzt auch angefangen das Spiel wirklich zu spielen und war von der Performance durchaus überrascht. Während ich im Extreme-Preset beim Benchmark nur 25 fps hatte mit der 980ti komme ich beim wirklichen Spielen (zumindest in der ersten Stunde) auf im Schnitt 55-80fps. Es scheint als ob der Metro Benchmark eher einem Stress Test nahe kommt. Wenn ich durch bin Berichte ich nochmal ob eventuell die 6gb vram doch noch Probleme machen.

 

[Phantomias88]

Da sind wir damit auf demselben "Endpunkt".
Es gibt genug Nachweise für Spikes ohne Limit, also können wir es nicht auf VRAM schieben.
Aber viel weiter in die Richtung müssen wir auch gar nicht. Es geht ja um den VRAM hier, nicht um andere Bereiche.
Solange wir aufhören jeden Spike stupide auf VRAM zu schieben, ist bereits einiges gewonnen.

Edit: Auch wichtig der Test von Don. Mehr Spikes, trotz mehr UND schnellerem VRAM. Starkes Indiz für ein nötiges Umdenken was potentiell idle Hardware auf budget GPUs angeht.

Wenn es bei mir an die VRAM Grenze geht und DX12 genutzt wird, geht die CPU in den Streaming Mode.
Bedeutet die CPU Auslastung geht auf 100% hoch, aber Ruckeln tut dann nichts.
Bei mir wird mit Crossfire Grundsätzlich mehr VRAM belegt als eine Single Karte.
Der Inhalt vom VRAM liegt auch in der selben größe im RAM (DDR3).

Allgemein gibt es hier noch ein paar Infos:
Frametime-Problematik gelst, Fazit - Dual Graphics und Frame Pacing im Test: Symbiose aus Kern und Karte - Golem.de
How Much VRAM Do I Need For Gaming In 2019? [Simple Guide]

Der zweite Link ist nur um es einfach zu halten, wenn man es richtig Analysieren wöllte, muss man Gigabyte weiße Daten Sammeln und das so synchron wie möglich, siehe z.B. auch hier:
THDE intern: So messen und bewerten wir die Grafik-Performance s Hardware Deutschland

Das ist genug Unwissenheit dabei um darüber eine Doktor Arbeit zu schreiben.
Nur blöd wenn ein Porgrammierer(in) schon längst den Durchblick hat, nur die Spieler / Massen noch nicht.