Diskussion zu: News des 4. Juli 2024 [Archiv]

Platos

2024-07-05, 12:46:02

Der tatsächliche Speicherverbauch ist doch auch völlig egal. Es zählt nur, wie viel Speicher reserviert wird. Wenn 15.9GB Speicher reserviert ist und das Spiel fordert nun noch mehr an, dann kann es sein, dass es eben zu Problemen führt, wenn man nur 16GB hat. Ob das Spiel nun wirklich so viel braucht, spielt keine Rolle. Es entscheidet, wie viel reserviert ist, obs Ruckler/Matachtexturen gibt und nicht, wie viel tatsächlich gebraucht wird. Das ist wie in nem Hotel. Da entscheidet auch nicht, wie viele Zimmer tatsächlich genutzt werden im Moment, ob du als Neukunde ein Zimmer kriegst. Es entscheided, obs noch freie Zimmer hat, also unreserevierte/ungebuchte. Der Hotellier weiss nicht, ob gerade das Zimmer "tatsächlich" in Gebrauch ist und das interessiert ihn auch gar nicht. So ist es auch bei VRAM. Spielt keine Rolle, ob da wirklich was belegt ist, nur obs reserviert ist.

Was soll immer diese Fixation auf tatsächlicher Verbrauch? Das interessiert nicht bei der Frage, ob man zu wenig Speicher hat.

Raff

2024-07-05, 12:51:08

Die Diskussion ist so müßig. Es wird immer mehr gebraucht, als das in einer idealen Welt der Fall wäre. Es bringt nichts, auf Effizienz und Möglichkeiten zu pochen, wenn die Realität das eben nicht hergibt. Insofern ist gerade Nvidias Speichergeiz sehr kontraproduktiv (außer für die Aktionäre). Warum das ständig kleingeredet wird, obwohl es genug Evidenz für Speichermangel gibt, die weit über Indizien hinausgeht, erschließt sich mir einfach nicht.

MfG
Raff

Platos

2024-07-05, 13:31:57

Ich weiss nicht, ob die Antwort an mich gerichtet ist, aber in meiner Antwort geht es nirgendswo darum, dass es keinen Speichermangel gäbe. Im Gegenteil.

Raff

2024-07-05, 13:42:29

Nee, allgemein an die Mitlesenden. Es gibt ja trotz der klaren Ergebnisse noch Leugner - auch wenn Medien wie die PCGH seit etwa zehn Jahren zeigen, was passiert, wenn man an diesem falschen Ende spart. Ich raff's nicht (pun intended).

MfG
Raff

MiamiNice

2024-07-05, 13:53:09

Nunja, nicht für jeden spielt die Optik so eine große Rolle, wie z.b. für Dich. Ich vermute die meisten haben maximal den FPS Counter im Auge und arrangieren sich mit der Optik. Bzw. finden sie den dargeboten Content supi, weil sie nicht wissen, dass es besser aussehen könnte.
Für mich ist das selektive auslassen von „Qualität“ ein Cheat und ggf. ärgerlich in MP Titeln, wenn es der Ortung des Gegners erschwert.

Gast

2024-07-05, 13:55:55

Also mir wäre es wichtig zu wissen ob die Grafikartentreiber bei zu wenig VRAM "mogeln" und eigenmächtig anfangen Sachen wegzulassen oder kleinere Texturen zu nutzen.

Das sind nicht Grafiktreiber, das sind die Gameengines.
Früher hat man ein ganzes Level (oder Levelteile) geladen und damit auch am Anfang alle Texturen, und am Ende hat man das nächste Level geladen.

Heute hat man ein Streaming-Budget für Texturen und andere Assets und füllt dieses auf. Wie groß dieses ist hängt einerseits von der Engine, aber auch vom verfügbaren VRAM ab. Wieviele und welche Texturen dann geladen werden wird dynamisch zur Laufzeit entschieden, und wenn das Streaming-Budget erschöpft ist, ergibt sich automatisch dass zur Laufzeit weniger Texturen im VRAM liegen.

Das ist auch die wesentlich bessere Lösung früher hat man einfach die maximale Texturauflösung limitiert, was man sofort überall gesehen hat, wo eigentlich höher aufgelöste Texturen vorgesehen waren. Heute bleiben dynamisch die nahen Texturen trotzdem hoch aufgelöst während die entfernten reduziert werden. So lange sich das außerhalb des sichtbaren Bereichs abspielt ist das auch ziemlich egal.

Und es ist trotzdem sinnvoll, bei vorhandenem großen VRAM diesen auch zu nutzen, wenn man sich durch die Spielwelt bewegt müssen dann weniger oft Assets ausgetauscht werden, was einerseits energieeffizienter ist und andererseits potentielle Slowdowns reduziert.

Raff

2024-07-05, 13:59:20

Ich muss Dinge weder wertschätzen noch brauchen, um sie zu verstehen. :)

MfG
Raff

Gast

2024-07-05, 14:01:13

Warum das ständig kleingeredet wird, obwohl es genug Evidenz für Speichermangel gibt, die weit über Indizien hinausgeht, erschließt sich mir einfach nicht.

Ich weiß jetzt wo du irgendwas von kleinreden siehst, es geht einzig um die Aussage dass es so schwer sein soll Speichermangel zu dokumentieren, was einfach nicht stimmt.

Frametime-Spikes lassens sich sowieso leicht dokumentieren, und für mögliche Qualitästseinbußen muss man eben nicht stundenlang suchen, weil wenn man dies muss sind diese einfach irrelevant.

Lehdro

2024-07-05, 14:44:26

Frametime-Spikes lassens sich sowieso leicht dokumentieren, und für mögliche Qualitästseinbußen muss man eben nicht stundenlang suchen, weil wenn man dies muss sind diese einfach irrelevant.
Stimmt halt nicht. Es geht um die Dokumentation dieser Qualitätseinbußen. Denn auch da gibt es Abstufungen. Lädt die Textur extra langsam rein? Wie lang dauert das? Lädt die Textur überhaupt rein? Oder lädt sie nur in reduzierter Auflösung rein? Bleibt die dann so? Oder ändert sich das erneut?

Wie soll man da objektiv hinterherkommen? Von daher finde ich die Herangehensweise von PCGH deutlich besser: Man moniert den nicht perfekten Zustand auf jeden Fall und disqualifiziert das entsprechende Ergebnis oder weißt zumindest deutlich(!) darauf hin.

Ätznatron

2024-07-05, 14:46:08

Vor (fast) zehn Jahren brachte die PCGH diesen netten Artikel:

Benchmarks zur Geforce GTX 970 und dem 3,5-GiByte-"Modus" (https://www.pcgameshardware.de/Geforce-GTX-970-Grafikkarte-259503/Specials/zu-wenig-VRAM-1149056/)

Darin werden u.a. die Auswirkungen von Speichermangel unter die Lupe genommen.

Und es wird auch gezeigt, welche Möglichkeiten der Manipulation allein schon durch den Grafiktreiber möglich sind, in dem Fall sogar eine krasse Manipulation, die vollkommen hinter dem Rücken des Anwenders abgelaufen ist.

Gast

2024-07-05, 14:48:17

Und wieder kein Wort dazu, dass und warum man für eine GB207 keine 24GB VRAM für UHD mit RT braucht.

Zossel

2024-07-05, 15:28:06

Jedenfalls ist es armselig wie wenig moderne Technik zum nachladen von Texturen bei Spielen im PC-Bereich ankommt und stattdessen Ressourcen verballert werden.

Zossel

2024-07-05, 15:29:16

Stimmt halt nicht. Es geht um die Dokumentation dieser Qualitätseinbußen. Denn auch da gibt es Abstufungen. Lädt die Textur extra langsam rein? Wie lang dauert das? Lädt die Textur überhaupt rein? Oder lädt sie nur in reduzierter Auflösung rein? Bleibt die dann so? Oder ändert sich das erneut?

Zur Hölle mit *.jpg, *.png rulez!

Lehdro

2024-07-05, 15:35:01

Jedenfalls ist es armselig wie wenig moderne Technik zum nachladen von Texturen bei Spielen im PC-Bereich ankommt und stattdessen Ressourcen verballert werden.
Noch schlimmer: Selbst wenn man die Ressourcen hat, kann es vorkommen dass man streamende Texturen im Sichtfeld hat, weil die Allokation unnötig klein ist oder nicht progressiv genug vorgeladen wird.

Gast

2024-07-05, 16:00:10

Der tatsächliche Speicherverbauch ist doch auch völlig egal. Es zählt nur, wie viel Speicher reserviert wird.
Es entscheided, obs noch freie Zimmer hat, also unreserevierte/ungebuchte. Der Hotellier weiss nicht, ob gerade das Zimmer "tatsächlich" in Gebrauch ist und das interessiert ihn auch gar nicht. So ist es auch bei VRAM. Spielt keine Rolle, ob da wirklich was belegt ist, nur obs reserviert ist.

Sorry, aber du hast keine Ahnung wie ein Computer funktioniert. Als studierter Wirtschaftsinformatiker weiss ich das zumindest teilweise.

Wenn man ein Game mit RTX 4090 startet, und 10 GB VRAM belegt sind, kann es sein, dass
a) die 10GB tatsächlich nötig sind
b) das Game einfach Texturen lädt, die noch gar nicht gebraucht werden aber proaktiv der Speicher genutzt wird
c) nicht mehr relevante Texturen nicht aufgeräumt wurden

Bei gleichen Settings kann es eben deshalb sein. dass auf einer RTX 3070 dann vielleicht 8 GB VRAM belegt sind und das Game läuft auch flüssig und ohne Qualitätseinbussen.

Klassiker sind in der Hinsicht auch immer Java Programme gewesen, die immer brutal Speicher belegt haben und wenn es eng wurde, hat die Garbage Collection mal wieder aufgeräumt und gut war es wieder.

Am Ende des Tages einfach ausprobieren und schauen wie das Game läuft und sich nicht verrückt machen lassen.

Gestern lief auf meiner Quest 2 Surv1v3 beschissen nach 30 Minuten. Ich war mir sicher, dass es am VRAM lag meiner RTX 3070.....der war aber nur zu 7,3GB belegt...VRAM ist nicht immer der einzige Grund, wenn ein Game unrund läuft....

Raff

2024-07-05, 16:46:51

Gestern lief auf meiner Quest 2 Surv1v3 beschissen nach 30 Minuten. Ich war mir sicher, dass es am VRAM lag meiner RTX 3070.....der war aber nur zu 7,3GB belegt...VRAM ist nicht immer der einzige Grund, wenn ein Game unrund läuft....

Es war ziemlich sicher trotzdem der VRAM, wenn Tools eine solche Belegung melden. Weil: Es wird schon deutlich vor den "magischen" 8.xxx MiByte in den RAM ausgelagert. Einfach mal parallel zur VRAM-Belegung die RAM-Belegung im Auge behalten. Grafikkarten mit wenig Speicher nötigen das System, schon frühzeitig Gerümpel im RAM zu parken, der mit steigender Laufzeit immer voller wird, bis es "knallt".

MfG
Raff

Leonidas

2024-07-05, 17:13:19

Und wieder kein Wort dazu, dass und warum man für eine GB207 keine 24GB VRAM für UHD mit RT braucht.

Ich verstehe den Sinn dieser Aussage leider nicht.

Wolltest Du darauf hinaus, dass ich mir einen GB207 mit 24 GB VRAM wünsche? Denn das ist nicht der Fall. Der Chip ist nix für 4K mit RT, ergo sind 12-16 GB gut genug. Eventuell kann man nur im Fall des (mageren) GB207 sogar mit 8 GB leben - aber darüber (ab GB206) sollte der VRAM realistisch bemessen sein.

Gast

2024-07-05, 17:17:55

Es war ziemlich sicher trotzdem der VRAM, wenn Tools eine solche Belegung melden. Weil: Es wird schon deutlich vor den "magischen" 8.xxx MiByte in den RAM ausgelagert. Einfach mal parallel zur VRAM-Belegung die RAM-Belegung im Auge behalten. Grafikkarten mit wenig Speicher nötigen das System, schon frühzeitig Gerümpel im RAM zu parken, der mit steigender Laufzeit immer voller wird, bis es "knallt".

MfG
Raff
Das kann theoretisch sein, wobei im RAM noch mehr Dinge passieren müssten und das wird dann schwer sein zu prüfen was da genau passiert. Ich glaube irgendwo gibt es auch Messwert für das Swapping aber ich wüsste nicht wo.

Bei der Quest 2 gibt es noch die Besonderheit mit dem Encoding/Decoding der Ausgabe und hier kann es auch Probleme verursachen, unabhängig vom VRAM.
Ein User hat einen Konflikt mit den Default Sound Devices in Windows und Oculus Software gefunden, da gab unterschiedliche Settings beim verwendeten Device und deshalb gab es auch immer wieder Ruckler. Bei der Quest 2 sind diese Ruckler eine Wissenschaft für sich...

Gast

2024-07-05, 17:57:05

Stimmt halt nicht. Es geht um die Dokumentation dieser Qualitätseinbußen.

Vollkommen wurscht, wenn sie leicht sichtbar sind sind sie auch leicht zu dokumentieren, wenn nicht sind sie auch nicht relevant.

Platos

2024-07-05, 20:11:59

Sorry, aber du hast keine Ahnung wie ein Computer funktioniert. Als studierter Wirtschaftsinformatiker weiss ich das zumindest teilweise.

Wenn man ein Game mit RTX 4090 startet, und 10 GB VRAM belegt sind, kann es sein, dass
a) die 10GB tatsächlich nötig sind
b) das Game einfach Texturen lädt, die noch gar nicht gebraucht werden aber proaktiv der Speicher genutzt wird
c) nicht mehr relevante Texturen nicht aufgeräumt wurden

Bei gleichen Settings kann es eben deshalb sein. dass auf einer RTX 3070 dann vielleicht 8 GB VRAM belegt sind und das Game läuft auch flüssig und ohne Qualitätseinbussen.

Klassiker sind in der Hinsicht auch immer Java Programme gewesen, die immer brutal Speicher belegt haben und wenn es eng wurde, hat die Garbage Collection mal wieder aufgeräumt und gut war es wieder.

Am Ende des Tages einfach ausprobieren und schauen wie das Game läuft und sich nicht verrückt machen lassen.

Gestern lief auf meiner Quest 2 Surv1v3 beschissen nach 30 Minuten. Ich war mir sicher, dass es am VRAM lag meiner RTX 3070.....der war aber nur zu 7,3GB belegt...VRAM ist nicht immer der einzige Grund, wenn ein Game unrund läuft....

Schön und gut, nur habe ich gar nie was anderes behauptet ^^

Ich habe gesagt, dass es egal ist, wie viel ein Spiel wirklich braucht. Es spielt nur eine Rolle, wie viel Speicher reserviert ist. Der Speicher läuft dann voll (aus Sicht des OS/der Software), wenn der zugesicherte Speicher voll ist und NICHT dann, wenn der physisch tatsächliche Speicher voll ist.

Es geht also darum, warum ruckelt es. Und die Antwort darauf ist NIENALS, weil der Speicher physisch voll ist, sondern IMMER, dass nicht mehr Speicher zugewiesen werden kann. Nach "tatsächlicher" Belegung fragen, ist also völlig irrelevant für die Frage, ob man unter Beeinträchtigungen leiden wird oder nicht.

Du hingegen redest eigentlich darüber, OB ein Spiel so viel Speicher zuweisen sollte. Das war aber nie die Frage...

Abgesehen davon: Raff hats ja schon gesagt, dass schon lange bevors voll ist, ausgelagert wird.

1ch0

2024-07-05, 22:36:09

Ich war mir sicher, dass es am VRAM lag meiner RTX 3070.....der war aber nur zu 7,3GB belegt...VRAM ist nicht immer der einzige Grund, wenn ein Game unrund läuft....

Das heißt doch gar nichts. Da hat die GPU schon lange angefangen, in den RAM auszulagern. Ich bin sicher, das lässt sich auch einfach nachvollziehen, dass der RAM-Verbrauch bei dir steigen wird. Dieses “Der VRAM ist aber nicht komplett voll, also braucht das Spiel scheinbar nicht mehr” ist einfach falsch und eine sehr simple Betrachtungsweise.

Das wird sicher auch eher der Grund sein. Eben weil in den RAM ausgelagert wird, hast du Performanceprobleme.

Der tatsächliche Speicherverbauch ist doch auch völlig egal. Es zählt nur, wie viel Speicher reserviert wird. Wenn 15.9GB Speicher reserviert ist und das Spiel fordert nun noch mehr an, dann kann es sein, dass es eben zu Problemen führt, wenn man nur 16GB hat. Ob das Spiel nun wirklich so viel braucht, spielt keine Rolle.

Was soll immer diese Fixation auf tatsächlicher Verbrauch? Das interessiert nicht bei der Frage, ob man zu wenig Speicher hat.

Genau das!

Ich raff's nicht (pun intended).

MfG
Raff

Ich kann dir sagen, warum das so ist. Weil die meisten überhaupt keine Vorstellung davon haben, was VRAM macht und wozu er überhaupt gebraucht wird. Das ganze Marketing ist schon seit Urzeiten auf FPS und lange Balken fixiert. Alles andere interessiert keinen oder man versucht es erst gar nicht zu vermitteln. Das hat sich so eingebrannt. Ist doch überall so. “VRAM? Brauch ich den? Was macht der?” Das ist doch der Wissensstand bei sehr vielen. Ist ja auch legitim, als Consumer kann auch nicht jeder alles verstehen und wissen. Aber dann sollte man als Produktanbieter wenigstens ein rundes Produkt anbieten. Und da benimmt sich Nvidia einfach aus Konsumentensicht stark daneben.

Ätznatron

2024-07-05, 23:21:40

Es geht also darum, warum ruckelt es. Und die Antwort darauf ist NIENALS, weil der Speicher physisch voll ist, sondern IMMER, dass nicht mehr Speicher zugewiesen werden kann. Nach "tatsächlicher" Belegung fragen, ist also völlig irrelevant für die Frage, ob man unter Beeinträchtigungen leiden wird oder nicht.

Und genau deswegen vermeiden die Entwickler, mehr anzufordern, als sie für nötig erachten.

Stattdessen gibt's ja Menüs, in denen man die Settings für die eigene Grafikkarte selbst wählen kann. Man muss sie nur zu nutzen wissen.

Iscaran

2024-07-06, 01:08:48

Und genau deswegen vermeiden die Entwickler, mehr anzufordern, als sie für nötig erachten.

Das würde ja bedeuten es gibt keine schlecht programmierten Spiele(-Engines)...:eek:

Ich glaube jeder kennt mind. ein Beispiel das dem nicht so ist.

EDIT: Ab hier allgemein zur Topic-Diskussion VRAM-Belegung/Verbrauch messen.

Wie oft wurde in der Vergangenheit über schlecht optimiertes Game XY gelästert?

Das gleiche beim VRAM-Verbrauch - früher gab es mal tests, da wurde ECHTER VRAM-Mangel dadurch belegt, dass z.B:
die gleichgetaktete 3GB Version eben 50% weniger FPS rüberbrachte als die gleichgetaktete 6GB Version.

Diese ganzen Counter die VRAM-Belegung messen, messen ausschliesslich den "allokierten" Speicherbereich das ist bekanntlich deutlich ungleich dem tatsächlich benötigten.

VRAM-Caching wird vom Treiber/Game je nach Bedarf einfach soviel gemacht wie die Engine vorgibt oder der Treiber zulässt...

Erst wenn das VRAM-Caching zu einem Performance-Problem wird ODER das Game "ungefragt" Details reduziert, weil das VRAM-Caching ein Problem hat weil zu wenig VRAM da ist...ist es relevant hier von VRAM-Limit zu sprechen.

Der angezeigte VRAM-Belegungs Counter zeigt nur an wieviel VRAM-gerade von Applikation XY "vorgehalten" wird - wieviel davon aber tatsächlich für die (stabile) Darstellung meiner 60 FPS gebraucht wird kann dieser Wert schlicht nicht beantworten.

Nur ein Beispiel um das obige zu Belegen folgende Aussage eines pyTorch Entwicklers
https://stackoverflow.com/questions/49529372/force-gpu-memory-limit-in-pytorch
Moreover, it is not true that pytorch only reserves as much GPU memory as it needs. Pytorch keeps GPU memory that is not used anymore (e.g. by a tensor variable going out of scope) around for future allocations, instead of releasing it to the OS. This means that two processes using the same GPU experience out-of-memory errors, even if at any specific time the sum of the GPU memory actually used by the two processes remains below the capacity.

Und das macht so ziemlich jede GameEngine da draussen auch so.

=> VRAM-Belegung trifft nahezu NULL Aussage darüber was das "Minimum" an VRAM ist für stabile XX-FPS.

Gast

2024-07-06, 01:11:06

Schön und gut, nur habe ich gar nie was anderes behauptet ^^

Ich habe gesagt, dass es egal ist, wie viel ein Spiel wirklich braucht. Es spielt nur eine Rolle, wie viel Speicher reserviert ist. Der Speicher läuft dann voll (aus Sicht des OS/der Software), wenn der zugesicherte Speicher voll ist und NICHT dann, wenn der physisch tatsächliche Speicher voll ist.

Es geht also darum, warum ruckelt es. Und die Antwort darauf ist NIENALS, weil der Speicher physisch voll ist, sondern IMMER, dass nicht mehr Speicher zugewiesen werden kann. Nach "tatsächlicher" Belegung fragen, ist also völlig irrelevant für die Frage, ob man unter Beeinträchtigungen leiden wird oder nicht.

Du hingegen redest eigentlich darüber, OB ein Spiel so viel Speicher zuweisen sollte. Das war aber nie die Frage...

Abgesehen davon: Raff hats ja schon gesagt, dass schon lange bevors voll ist, ausgelagert wird.

Das eine hängt doch mit dem anderen zusammen. Falls der physische Speicher voll ist, sollte ein Spiel nicht mehr Speicher reservieren, der nicht unbedingt benötigt wird. Gleichzeitig sollte der Speicher auch immer wieder aufgeräumt werden.
Ich denke ein Spiel und die Treiber passen sich der verfügbaren Menge an VRAM auch immer an.

Platos

2024-07-06, 02:25:18

Und genau deswegen vermeiden die Entwickler, mehr anzufordern, als sie für nötig erachten.

Stattdessen gibt's ja Menüs, in denen man die Settings für die eigene Grafikkarte selbst wählen kann. Man muss sie nur zu nutzen wissen.

Ja, aber die ursprüngliche Kritik war ja an dem letzten Artikel von Leonidas, dass ja diese Speichertests eig. alle unbrauchbar wären, weil sie ja eig. "nur" den zugewiesenen Speicher messen und nicht den "tatsächlich" gebrauchten Speicher.

Und diese Kritik ist eben falsch, da es sogar explizit NICHT darauf ankommt, wie viel das Spiel wirklich braucht, sondern nur darauf, wie viel Speicher noch zugewiesen werden kann bzw. wie viel Speicher schon zugewiesen wurde.

Man kann natürlich jetzt sich bei den Engine-Entwickler oder Spieleentwickler beschweren usw. Aber das hat am Ende alles nichts mit der Frage zu tun, ob ich als Gamer mit X GB VRAM bei Spiel XYZ genug oder nicht genug Speicher habe.

Man kann natürlich jetzt in Frage stellen, ob bei einer 24GB Karte wirklich der ganze zugesicherte Speicher zugesichert bleiben würde, hätte sie weniger (also ohne zu wenig Speicher zu haben). Das ist ein Argument, ok. Es kann natürlich sein, dass bei mehr als genug Speicher nicht mehr benötigte Dateien nicht rausgeworfen werden (weil ja genug da ist) und somit mehr zugesichert wird, als es sonst würde. Aber dazu hat ja Raff schon was gesagt, dass man in solchen Fällen den RAM Verbrauch im Auge behalten kann (neben frametimes/percentilen) und so feststellen kann, ob wirklich genug da ist.

So oder so: Auszulesen, wie viel RAM physisch im Speicher ist, ist auf jeden Fall nutzlos.

Das eine hängt doch mit dem anderen zusammen. Falls der physische Speicher voll ist, sollte ein Spiel nicht mehr Speicher reservieren, der nicht unbedingt benötigt wird. Gleichzeitig sollte der Speicher auch immer wieder aufgeräumt werden.
Ich denke ein Spiel und die Treiber passen sich der verfügbaren Menge an VRAM auch immer an.

Es ging aber darum, wie viel Speicher ich als Gamer brauche. Ich kann noch so sagen, es sollte nicht so sein, dass so viel zugewiesen wird. Das bringt mir als Gamer aber nix, denn am Ende entscheidet, wie viel zugewiesen wird, nicht wie viel zugewiesen werden sollte.

Edit: Also was genau willst du damit sagen? Willst du sagen, eine Grafikkarte mit weniger Speicher würde ohne Ruckler und Qualitätsminderung weniger Speicher zuweisen als eine mit viel Speicher (also auch ohne, dass potentiell eher gesehen wird, wenn z.B Texturen nachgeladen werden usw)?

Wenn ja, kannst du hier auch irgendwelche Tests verlinken?

Und das macht so ziemlich jede GameEngine da draussen auch so.

=> VRAM-Belegung trifft nahezu NULL Aussage darüber was das "Minimum" an VRAM ist für stabile XX-FPS.

Tatsächlich gebrauchter Speicher (also physisch im Speicher) sagt aber null aus darüber, ob man genug Speicher hat oder nicht.

Was nehmen wir jetzt also :D ?

Wie soll man denn deiner Meinung nach Grafikspeicherbedarf testen? Am besten wäre natürlich, man hätte eine GPU mit verschiedenem Speicher, aber es gibt ja meist keine solchen Ausführunge und wenn doch, dann sind es solche extremen Unterschiede wie bei z.B der 8GB/16GB RTX 4060. Und da kann man nur sagen ob 8GB zu wenig sind oder nicht, aber nicht wirklich, wie viel es nun braucht.

Also was ist dein Vorschlag, wie man das testen soll?

MiamiNice

2024-07-06, 05:45:51

Keine Grafikkarte mit unter 24 Gb Speicher kaufen. Drops gelutscht.

Iscaran

2024-07-06, 10:22:29

Tatsächlich gebrauchter Speicher (also physisch im Speicher) sagt aber null aus darüber, ob man genug Speicher hat oder nicht.

Was nehmen wir jetzt also :D ?

Ja - genau. Der VRAM-Belegungsmesswert sagt NULL aus darüber ob die FPS flüssig bleiben.

Wie soll man denn deiner Meinung nach Grafikspeicherbedarf testen? Am besten wäre natürlich, man hätte eine GPU mit verschiedenem Speicher, aber es gibt ja meist keine solchen Ausführunge und wenn doch, dann sind es solche extremen Unterschiede wie bei z.B der 8GB/16GB RTX 4060. Und da kann man nur sagen ob 8GB zu wenig sind oder nicht, aber nicht wirklich, wie viel es nun braucht.

JA - das ist das Grundproblem. Nur das MESSEN von VRAM-Belegung löst dieses Problem noch weniger als das Umständlichere Vergleichstesten der wenigen Modelle wo man genau solche Speicherunterschiede hat!.

Also was ist dein Vorschlag, wie man das testen soll?

X-GB Karte vs Y-GB Karte (gleichen Typs oder zumindest "gleich stark kastriert/eingstellt" - FPS messen, Frametimes messen. BQ-Checken (ob es versteckte Detailreduktionen gab oder nicht => Falls ja Game-Engine ist nicht "testbar" weil sie sich nicht an die Testvorgaben hält.

Nur um das mal noch ein bisschen auszuarbeiten warum VRAM-Belegung != VRAM-Bedarf ist.

Eine RX6600 hat 224 GB/s Speicherbandbreite und 8 GB VRAM.

=> Im Grunde könnte man also 28x mal pro Sekunde den Speicher komplett leeren und wieder beschreiben. (OK minus overhead weil man ja nicht nur BQ sondern auch andere Dinge im Speicher hat - aber nur zur Verdeutlichung).

=> Wenn also 1 FRAME 8 GB VRAM bräuchte um alles darzustellen und die "inkrementelle" Änderung zum Nächsten FRAME eine komplettes Austauschen ALLER im Speicher liegenden Bereiche erfordern würde.
Selbst in DIESEM EXTREMFALL, könnte ich erwarten dass die RX6600 mit 8GB VRAM also ~28 FPS liefert.

Denk mal drüber nach.

Nehmen wir mal an ich möchte also 144 FPS "stabil" packen, was die RX6600 schon eher in den wenigsten games packt, heisst das ich darf PRO FRAME nicht mehr als ~1.58 GB VRAM SWAPPING benötigen (=> Dann passen nämlich 144 Frames / Sekunde durch die Speicherbandbreite).

Genau HIER kommt der VRAM zum tragen. Passen sagen wir mal die "Konstanten Teile" Aller in einem Spiel vorkommenden Bildbestandteil in den VRAM gibt es einfach kein Swapping man hat stabile FPS da alles aus dem Kurzzeitspeicher geladen wird.

Siehe auch das pyTorch Beispiel und die "Garbage Collection" genau das machen Game Engines und der Video Treiber auch. Man belegt solange VRAM, wie man Dinge ablegen kann um ggf. "nachstreamen" zu vermeiden.

Bei Dynamischen Berechnungen wie FPS in riesigen Spielwelten, bräuchte man dazu aber unendlich viel VRAM.
Da wird sowieso immer und überall "nachgestreamt" und VRAM-geswapped.

Die Frage ist also grundsätzlich wie hoch ist das Minimum an VRAM das ich im Grunde für JEDES FPS brauche / Speicherbandbreite um ein nachstreamen von Frame zu frame zu vermeiden.

Das ist eine schwer zu bestimmende Größe aber MESSEN kann man das sicherlich NICHT in dem man den Counter für VRAM-Cache-Belegung ausliest.

Ätznatron

2024-07-06, 11:40:39

Das würde ja bedeuten es gibt keine schlecht programmierten Spiele(-Engines)...:eek:

Ich glaube jeder kennt mind. ein Beispiel das dem nicht so ist.

Natürlich gibt es schlecht programmierte Engines, aber das bedeutet nicht automatisch, dass deren Probleme ausschließlich an fehlerhafter VRAM-Allokation bzw. Freigabe liegen müssen (Gothic III fällt mir da gerade ein).

Ich gehe davon aus, dass 99% der Probleme durch die zu optimistische Einschätzung der Fähigkeiten der eigenen (teuren) Grafikkarte vom Anwender selbst verursacht werden, weil ungeignete Settings gewählt werden.

1ch0

2024-07-06, 11:53:27

Ich gehe davon aus, dass 99% der Probleme durch die zu optimistische Einschätzung der Fähigkeiten der eigenen (teuren) Grafikkarte vom Anwender selbst verursacht werden, weil ungeignete Settings gewählt werden.

Das denke ich auch. ^^

Platos

2024-07-06, 13:31:52

Die Frage ist also grundsätzlich wie hoch ist das Minimum an VRAM das ich im Grunde für JEDES FPS brauche / Speicherbandbreite um ein nachstreamen von Frame zu frame zu vermeiden.

Das ist eine schwer zu bestimmende Größe aber MESSEN kann man das sicherlich NICHT in dem man den Counter für VRAM-Cache-Belegung ausliest.

Sorry, aber das ist ja mal wirklich total an der Realität vorbei. Es entscheidet doch nicht die Speicherbandbreite des VRAM, wie schnell gestreamed werden kann, sondern ganz klar die der SSD/HDD (bzw. System-RAM). Deine ganze Ausführung und Berechnung funktioniert so ganz sicher nicht.

Und wir wissen ja, dass abseits von ein paar Ausnahmen am PC immer noch auf HDD optimiert wird.

Also kurz gesagt: Nein, das wird so nicht gemacht, denn es ist immer am Ende das schwächste Glied das, worauf es ankommt und das wäre maximal die SSD bzw. der RAM, aber man lädt natürlich nicht das ganze Spiel in den RAM, deswegen ist es de Facto die SSD/HDD, die entscheided, wie schnell gestreamed werden kann bzw. wie viel vorgeladen werden muss ins RAM (ist ja am Ende ein Kompromiss aus vorladen und Speicherbedarf). Wobei auf Frame-Ebene ist es natürlich der RAM, der aber viel, viel langsamer wie der VRAM ist.

In der Realität wird vorgeladen und das ganz lange bevor du die Dateien brauchst. Und selbst dann, wenn in ferner Zukunft am PC endlich mal direkt aus der SSD gestreamed wird, ist a) die Speicherbandbreite einer SSD weit, weit niedriger, wie vom VRAM und b) wird selbst dann nicht alles, was im Speicher liegt, ständig ausgetauscht. Gestreamed werden vor allem Texturen. Das macht schon ordentlich was aus, aber nicht alles.

(Und c) funktioniert Direct Storage am PC anscheinend trotzdem nicht so gut, wie an der PS5 (dazu gibts ein paar Tests, die zeigen, dass die PS5 trotz eig. langsameren Speicher schneller ist).

Also kurz gesagt: Nein, so wie du das darlegst, funktioniert das nicht. So kann man den VRAM bedarf sicher nicht ausmachen und kein Spieleentwickler berechnet den VRAM Bedarf anhand der Speicherbandbreite des VRAM aus... Die wirst du sowieso niemals erreichen.

Du lädst immer vor. Je schneller der Speicher (hdd/ssd) wird, desto weniger weit musst du vorladen. Aber selbst wenn alles im RAM wäre, würdest du noch vorladen müssen, da der RAM viel zu langsam wäre.

Gast

2024-07-06, 14:40:33

Ich verstehe den Sinn dieser Aussage leider nicht.Ernsthaft? Der Spott trieft dermaßen raus, dass alle erkennen sollten, was gemeint ist.

Gast

2024-07-06, 16:55:42

Und diese Kritik ist eben falsch, da es sogar explizit NICHT darauf ankommt, wie viel das Spiel wirklich braucht, sondern nur darauf, wie viel Speicher noch zugewiesen werden kann bzw. wie viel Speicher schon zugewiesen wurde.

Genau umgekehrt das einzige was relevant ist, der reale Speicherverbrauch.

Reservieren kannst du so viel du willst, auch viel mehr als physischer Speicher überhaupt zur Verfügung steht, das ist vollkommen egal so lange der Speicher nicht tatsächlich verwendet wird.

In der 32bit Ära war reservierter Speicher noch relevant, da dieser natürlich auch Adressraum belegt und zumindest am Ende dieser der limitierende Faktor war und nicht der physische Speicher.

Mit 64bit ist der reservierte Speicher vollkommen egal, da der Adressraum so viel größer als der physische Speicher ist.

Platos

2024-07-06, 17:25:33

Genau umgekehrt das einzige was relevant ist, der reale Speicherverbrauch.

Reservieren kannst du so viel du willst, auch viel mehr als physischer Speicher überhaupt zur Verfügung steht, das ist vollkommen egal so lange der Speicher nicht tatsächlich verwendet wird.

In der 32bit Ära war reservierter Speicher noch relevant, da dieser natürlich auch Adressraum belegt und zumindest am Ende dieser der limitierende Faktor war und nicht der physische Speicher.

Mit 64bit ist der reservierte Speicher vollkommen egal, da der Adressraum so viel größer als der physische Speicher ist.

Ich glaube es gibt hier ein Problem über den Begriff "tatsächliche Verwendung".

Ein Programm reserviert immer mehr Speicher, als gerade physisch wirklich im Speicher geschrieben ist. Also auch dann, wenn es "Im Gebrauch ist", wird mehr reserviert, als physisch im Speicher geschrieben ist. Also d.h es wird immer so sein, dass wenn kein Speicher mehr zugewiesen werden kann (ohne ins RAM auszulagern), der zugewiesene Speicher grösser ist, wie die tatsächlich beschriebene Grösse. Deswegen ist die Angabe, wie viel gerade im Speicher geschrieben ist völlig irrelevant.

Ist beim System-RAM auch nicht anders. Da wird auch ausgelagert, wenn der zugewiesene Speicher deinen physisch vorhandenen übersteigt und nicht dann, wenn der physisch beschrieben Speicher voll läuft.

Kannst du ganz easy testen, was passiert, indem du die Auslagerungsdatei löscht. Die Programme werden dann abschmieren, wenn der zugewiesene Speicher die Grösse deines physischen Speichers erreicht hat und nicht erst dann, wenn dein physischer Speicher vollgeschrieben ist.

Das ist beim VRAM auch so, nur eben dort wird immer in den RAM ausgelagert. Kannst du meines Wissens nach nicht abschalten, ansonsten könnte man das wunderbar testen.

Gast

2024-07-06, 20:06:10

Gast

2024-07-06, 20:46:11

Ich glaube es gibt hier ein Problem über den Begriff "tatsächliche Verwendung".

Aber offensichtlich bei dir, wobei du auch nicht zur Aufklärung beiträgst, was du nun darunter verstehst.

Ein Programm reserviert immer mehr Speicher, als gerade physisch wirklich im Speicher geschrieben ist.

Nicht zwangsläufig, außer du zählst die paar ms zwischen Reservierung und Benutzung mit, aber selbst wenn du das tust ist der Unterschied zu vernachlässigen.

Deswegen ist die Angabe, wie viel gerade im Speicher geschrieben ist völlig irrelevant.

Das was gerade geschrieben ist, ist das einzig relevante.
Speicher ist virtualisiert, der Speicher den ein Prozess sieht hat gar nichts mit den physischen Gegebenheiten in der Hardware zu tun. Und Speicher wird erst "verbraucht" wenn in ihn geschrieben wird, nicht wenn er reserviert wird.

Wenn du ein beliebiges Java-Programm startest gibt es für die JVM einen Parameter -Xmx welcher festlegt wie viel Speicher die JVM für den Java-Heap reserviert. Dieser wird immer beim Start von Java reserviert, und du kannst da 20GB eintragen und trotzdem wird das Programm direkt nach dem Start keine 20GB konsumieren, weder im VRAM noch in der Auslagerungsdatei. Die 20GB werden nur für den Heap reserviert, falls sie irgendwann gebraucht werden.

Platos

2024-07-06, 22:18:38

https://www.techpowerup.com/review/the-first-descendant-fps-performance-benchmark/5.html

Bei RT und QHD werden auf RTX 4090 8,3 GB belegt. Dennoch performanen eine RTX 4060 TI mit 8 und 16 GB genau gleich. Erst bei 4k mit RT gibt es einen Unterschied.

Das sind winzige Unterschiede, um die es hier nicht geht. Es geht hier doch nicht um 0.3GB Unterschied.

Abgesehen davon wurde hier doch nun genug oft erwähnt, dass Speicherverbrauch und FPS/minFPS alleine nicht genügen, da bei Speichermangel in modernen Spielen oftmals einfach die Texturstufe reduziert wird.

https://www.youtube.com/watch?v=_-j1vdMV1Cc&t=68s

Schau doch mal hier. Obwohl die 8GB Version weit unter 8GB ist (z.B bei Ratchet), schneidet sie viel schlechter ab.
Es gibt Fälle, in denen die Version mit mehr Speicher mehr verbraucht, ja.

Es gibt Fälle, in denen der Speicher höher ist, obwohl es gleiche Perfomance und (soweit sichtbar in Youtube) gleiche Grafik hat. Es gibt aber auch genug, bei denen es nicht so ist. Und was man auch gut sieht: Der tatsächlich genutzt Speicher ist immer niedriger, als der zugesicherte (erstmal logisch), das jedoch auch dort, wo der Speicher der 8GB Version offensichtlich nicht reicht (z.B bei Ratchet). Sowohl der zugesicherte, als auch der tatsächlich genutzte Speicher ist weit unter 8GB und trotzdem gibts deutlich schlechtere Perfomance. Also nein, der tatsächliche Verbrauch sagt noch viel schlechter etwas darüber aus, wie viel GB man wirklich braucht, als der zugesicherte Verbrauch.

Kurz gesagt: Eigentlich beide Werte sind nicht wirklich genug Aussagekräftig, der Wert des tatsächlich gebrauchten Speichers ist aber noch weniger Aussagekräftig, wie man in den Fällen gesehen hat, bei denen die Perfomance unter 8GB einbricht. Am besten beurteilt man, wie viel Speicher es braucht, genau so, wie in diesem Video.

Das ist auch ein Grund, warum klassische IT-Medien nicht mit (manchen wenigen) Youtuber mithalten können. Sie testen einfach nur mit balken.

Fusion_Power

2024-07-06, 23:57:45

Irgend wie scheinen die Games heutzutage nicht immer optimal mit dem VRAM umzugehen, rein subjektiver Eindruck von mir. Ich hab manchmal das Gefühl, dass da auch mit weniger, mehr erreicht werden könnte, ohne dass die Optik wirklich leidet. Aber sowas wie sich wiederholende Texturen und andere Tricks scheinen aus der Mode zu kommen.
Die Grafikkarten von heute haben locker das 1000-fache an VRAM jener der ersten Generationen damals. Aber die Games heutzutage sehen nicht wirklich auch automatisch 1000x besser aus. Meine Voodoo2 damals hatte 8 Megabyte VRAM, hat nicht für HD gereicht aber Unreal sah trotzdem super aus damit. Inklusive guter Texturierung, sogar mit extra-Detail-Texturen wenn man nahe ran ging an die Wände. "Billige" Tricks vielleicht aus heutiger Sicht aber alles was technisch möglich war wurde auch aus der Hardware raus gequetscht.
Diese Extrameile vermisst man heute manchmal.

1ch0

2024-07-07, 00:38:02

Irgend wie scheinen die Games heutzutage nicht immer optimal mit dem VRAM umzugehen, rein subjektiver Eindruck von mir. Ich hab manchmal das Gefühl, dass da auch mit weniger, mehr erreicht werden könnte, ohne dass die Optik wirklich leidet.

Ich glaube, du unterschätzt, was heute alles in den VRAM muss und wie komplex die Spiele inzwischen bei den Assets sind. Sowas wie Texturlayer für Charaktere, die Gesichter super realistisch simulieren, und vieles andere… Das gab es halt alles früher nicht. Wir haben eben keine Texturtapeten mehr. Das kann man nicht so einfach sagen.

Fusion_Power

2024-07-07, 01:22:11

Ich glaube, du unterschätzt, was heute alles in den VRAM muss und wie komplex die Spiele inzwischen bei den Assets sind. Sowas wie Texturlayer für Charaktere, die Gesichter super realistisch simulieren, und vieles andere… Das gab es halt alles früher nicht. Wir haben eben keine Texturtapeten mehr. Das kann man nicht so einfach sagen.
Yo, ich bin mir auch sicher dass ich das total unterschätze. ich stamme noch aus der Zeit der guten, alten "Texturtapeten", hab früher selber welche erstellt, halt ehr für Spiele wie Duke 3D, als Übung. Nix kompliziertes, schon gar nicht mit Height/Bump... oder sonst welchem Mapping. :D
Wie macht man sowas denn heute? Muss wirklich aufwändig sein wenn Spiele locker über 100GB auf der Platte verbrauchen. Die CoD Reihe z.B. ist dafür ja berüchtigt. Wobei sie bis heute nie wirklich im Detail erklärt haben, was genau da so viel Speicher belegt. Hoffe das ist nicht alles im RAW Format hinterlegt oder so. Wäre irgend wie peinlich. :freak:

Iscaran

2024-07-07, 22:36:33

Natürlich gibt es schlecht programmierte Engines, aber das bedeutet nicht automatisch, dass deren Probleme ausschließlich an fehlerhafter VRAM-Allokation bzw. Freigabe liegen müssen (Gothic III fällt mir da gerade ein).

Korrekt - aber das habe ich auch nicht behauptet. Aber "schlechtes VRAM-Management" wäre auch EIN Kennzeichen für schlechte Programmierunge/Optimierung.

Iscaran

2024-07-07, 22:42:21

Es gibt Fälle, in denen der Speicher höher ist, obwohl es gleiche Perfomance und (soweit sichtbar in Youtube) gleiche Grafik hat. Es gibt aber auch genug, bei denen es nicht so ist. Und was man auch gut sieht: Der tatsächlich genutzt Speicher ist immer niedriger, als der zugesicherte (erstmal logisch), das jedoch auch dort, wo der Speicher der 8GB Version offensichtlich nicht reicht (z.B bei Ratchet). Sowohl der zugesicherte, als auch der tatsächlich genutzte Speicher ist weit unter 8GB und trotzdem gibts deutlich schlechtere Perfomance. Also nein, der tatsächliche Verbrauch sagt noch viel schlechter etwas darüber aus, wie viel GB man wirklich braucht, als der zugesicherte Verbrauch.

Aber ALL das was du hier aufzählst kannst du eben NICHT an der Zahl des VRAM Counters ablesen.

Qualitätsminderung durch "ungemeldetes" runterdrehen der Details => VRAM-Belegung "niedriger" bzw. niedrig genug.

Trotzdem am Arsch. usw.

Es geht darum, das man versucht der Zahl "VRAM-Belegung" mehr Bedeutung beizumessen als diese zu leisten vermag.

Deswegen ist die einzige Empfehlung an die Tester:
Checkt dass die BQ wirklich GLEICH ist (und nicht versteckt Details runterfahren).
Messt die FPS/Frametimes.

Bei sichtlichem Mangel an akutem VRAM macht sich das bemerkbar weil das "Streaming" eben nicht mehr hinterherkommt. Die FPS/Frametimes brechen dann SIGNIFIKANT ein (um XX % und nicht um 0.xx %)

Und ja richtig - das echte Bottleneck ist hier natürlich die hard disc und nicht unbedingt die Speicherbandbreite. Das war ja auch nur als Beispiel gedacht um zu verdeutlichen dass ein moderne GPU theoretisch den Speicher ZIGMAL pro Sekunde (als praktisch PRO FRAME) jeweils komplett vollballern könnte ohne dabei signifikant zu droppen. Speziell seit es SSDs gibt die extrem schnell reagieren und extrem schnell Daten schieben.
Dazu kommt ja noch, der System-RAM auch noch als "erweiterter Puffer" dient.

Aber in Zeiten von SSDs ist DIESES Problem auch deutlich reduziert im Vergleich zu früher.

Vielleicht wäre ein optimaler Test für "VRAM"-Bottlenecking EXTRA mal ne langsame Festplatte einbauen und dann 8GB vs 16 GB Karten testen?
Evtl. gepaart mit dem Test an Systemen die EXTRA WENIG System RAM haben (gleich viel wie die GPU höchstens).

Leonidas

2024-07-08, 04:36:53

Deswegen ist die einzige Empfehlung an die Tester:
Checkt dass die BQ wirklich GLEICH ist (und nicht versteckt Details runterfahren).
Messt die FPS/Frametimes.

Exakt. Wesentlich besser als die grobe Richtschnur der VRAM-Belegung.

Aber es gilt auch: Wer macht das in der Praxis? Es passiert viel zu selten.

Iscaran

2024-07-08, 11:16:34

Aber es gilt auch: Wer macht das in der Praxis? Es passiert viel zu selten.

Ja - aber dann stattdessen den VRAM-Counter angeben ist noch weniger Zielführend. Denn dieser Wert KANN obiges nicht ersetzen - nicht mal approximieren.

Bedingt durch seine Art und weise was er ist und was er misst.

Leonidas

2024-07-08, 11:39:52

Denkst Du nicht, dass die Angaben nicht eventuell in einem guten Maßstab korrelieren? Ich meine, es geht beiderseits exakt um dieselbe Meßgröße (VRAM) und sogar dasselbe Problem (Mangel).

Gast

2024-07-08, 14:14:31

Denkst Du nicht, dass die Angaben nicht eventuell in einem guten Maßstab korrelieren?

Naja, man kann zumindest sicher sagen, dass eine Karte mit mehr VRAM als bei einer Karte mit deutlich überdimensionierten VRAM alloziert wird garantiert keine VRAM-Bedingten Probleme haben wird.

Umgekehrt kann man aber überhaupt keine Aussage darüber treffen ob und wie weit es Einschränkungen mit einer Karte mit geringerer VRAM-Ausstattung gibt.

Iscaran

2024-07-08, 14:15:49

Denkst Du nicht, dass die Angaben nicht eventuell in einem guten Maßstab korrelieren?

NEIN. Warum hab ich (und andere) doch oben zur Genüge breitgetreten.

Eine GPU mit 16 GB VRAM wird bei lang genugem Spielen UND je nach Garbage Collection des Games IMMER bei 16 GB "Belegung" enden im "Worst case".

Das sagt NICHTS über die tatsächlich benötigte Menge an VRAM für ein konstantes Spielerlebnis aus. Zumal die tatsächlich relevante Menge an VRAM AUCH von Faktoren wie HDD vs SSD oder RAM abhängt.

Nebst der tatsächlich benötigten VRAM-Menge pro Frame bzw. viel wichtiger der tatsächlich benötigten delta-VRAM-Menge pro Framewechsel.

Natürlich ist auch davon auszugehen, dass es zu krassen Effekten kommt FALLS mal tatsächlich die Menge an VRAM die ein EINZELNER Frame braucht > VRAM-Verfügbar ist....

Denn in dem Fall kann das Game den Frame vielleicht gar nicht mehr berechnen oder nur in Stücken, also Absturz oder Makrolag oder was weiss ich.

NUR gibt es kein Tool der Welt das z.B. die Menge VRAM die Frame XY tatsächlich gebraucht habt ausgibt...nur das wäre vielleicht eine sinnvolle UNTERGRENZE für VRAM-Minimum.

Also Gamedeveloper könnte es sein, das man so eine Maßzahl irgendwo hat - aber auch das bezweifle ich, da es ja z.t. vom dynamischen Content abhängen kann wieviel VRAM man für ein Frame XY tatsächlich braucht.

Also NEIN - die Maßzahl "VRAM-Belegung" so wie sie gemessen und ausgegeben wird hat praktisch NULL-Relevanz für irgendeine daraus abzusehenden Limitierung.

Auf einer Karte mit viel VRAM physisch und schlechter "Garbage Collection" des Games, wird der VRAM immer "voll laufen" trotzdem wird die Performance nicht einbrechen (es sei denn die GC triggert ganz plötzlich und fängt dann im Hintergrund auf den VRAM aufzuräumen und frisst so Resssourcen schlagartig und massiv die man besser "kontinuierlich" in der Engine implementiert hätte.

Dann gibt es halt kurz einen Lag.

(Kurz weil die Bandbreite ja >>>> Grösser als das was man an VRAM hat => selbst wenn ich von einem Frame zum nächsten meine 8GB VRAM "löschen" und komplett neuschreiben muss sind bei 228 GB/s Bandbreite im Prinzip 28 FPS drin (natürlich wie Platos richtig eingeworfen ist das zu einfach gerechnet => RAM als Zwischenpuffer groß und HDD/ SSD Zeiten um 8 GB zu liefern sind hier die wahre "Untergrenze".

Der VRAM muss genau so große sein, dass man niemals im Frame-Berechnungsprozess warten muss auf Daten...das zu messen ist schwierig.

Messen tut das im Prinzip die Frametime (als komplexe Überlagerung ALLER an der Frameberechnung beteiligter Prozesse).

Einen EKLATANTEN Mangel an VRAM stellt man also in der Tat NUR
durch die Messung der Performance bei gleicher BQ fest

Gleiche BQ weil das ist ja gerade die Krux an den ganzen Neumodischen "Dynamische BQ-Anpassung"-Spielerereien, es gilt nicht mehr was eingestellt ist sondern nur noch was das Game als "Blackbox" von Frame zu Frame entscheidet was wichtig wäre.

Tut mir echt leid aber VRAM-Belegung misst bestenfalls wie gut oder schlecht die Garbage Collection von Game XY ist, oder wieviel Texturen+Sonstige Dinge (fertig kompilierte Shader etc) Game XY halt INSGESAMT braucht ohne auch nur 1 ms auf RAM/HDD/SSD auszugreifen.

Siehe dazu doch einfach das pyTorch beispiel und das ist ein unglaublich "simples" Programm - eine Game Engine ist da natürlich etwas komplexer aber GRUNDSÄTZLICH funktioniert das auch da exakt genauso.

Die Engine legt Dinge im VRAM ab die man für eine Frameberechnung braucht.

Nehmen wir mal an 1 GB pro Frame. Also lädt die Engine 1 GB in den VRAM für Frame1...dann wieder 1 GB für Frame 2 usw. (ggf. reduziert weil 90% des Inputs von Frame 1 für Frame2 recycelt werden können) also lädt das Game nur 0.1 GB zu den 1 GB dazu.

Zwischen Frame1 und Frame2 (oder zu bestimmten Abständen) zwischendrin würde der Game Interne "Garbagecollector" (GC) eigentlich mal durchchecken (hmmm, daten X-Z sind schon > 10 Frames im Speicher => brauchen wir wohl so bald nicht mehr also weg damit)

Die meisten GCs machen sowas aber ohne "Optimierung" durch den Programmierer eigentlich erst bei erreichen der Fahnenstange (= VRAM-Reserviert für Programm, bei dedizierten Sachen wie GPU-Treiber also = VRAM-physisch vorhanden (in erster Näherung).

Vorher wird einfach nur VRAM belegt und belegt und belegt. GEBRAUCHT wird davon aber nur ein Bruchteil um von Frame X auf Frame Y zu kommen.