[Sammelthread] Spiele, die 512MB Graka-Ram benutzen

Da ich die meiste Zeit auf dem 2. Monitor ein paar Statistik-Tools offen habe und mich der VRAM-Gebrauch meiner Graka schon immer interessiert hat (woher kommen die Ruckler die ich mich nicht erklären kann) hat sich inzwischen eine recht ansehnliche Sammlung angefunden.
Vielleicht ist es ja für den einen oder anderen genau so interessant.
Und nochmal zum mitmeißeln, VRAM-Gebrauch. Bedeutet wenn 1.5GB benutztes VRAM angezeigt werden bedeutet es nicht dass es auf Karten mit 1GB zu einem völligen Zusammenbruch kommt. Es könnte aber sein^^
Letzte Änderung: 02.03.2013


Spitzenreiter:
Hitman Absolution mit 6GB ohne überzogene AA-Einstellungen (sieht man an der Performance vom Game). Am Ende mit unschönen Textur-Swaps.



Settings: Solange nicht anders genannt Nvidia-Graka, Treiber auf HQ, alle Optimierungen aus, 2xAA 16xAF.

Und noch ein Wunsch von mir:

Dies soll keine Performance-Diskussion werden sondern nur ein empirischer Vergleich. Wer meint das 256MB VRAM für seine Games reichen ... ja, ist toll. Akzeptiere ich voll und ganz. Dass ATI sparsamer mit VRAM umgehen soll als Nvidia (auch wenn die Texturen nicht weniger werden^^) weiß ich auch, allerdings habe ich letztens mit meiner 5970 Vergleiche angestellt und keinen Unterschied gesehen. Ich möchte euch nur meine Beobachtungen zeigen, deshalb sind die meisten Screenshots auch ohne FPS-Anzeige (wobei ich spielbare Settings bevorzuge). Dafür aber noch mit dem tatsächlichen RAM-Verbrauch des Games in der Anzeige vom ProcMon. Vielleicht ein kleiner Leitfaden für die Leute die wissen wollen was ein Programm so an Speicher nutzt.

Neue Beobachtungen


Crysis 2 1.2GB (2560x1600 Extreme, keine Einsteller für AA/AF im Game zur Zeit) DX9




Witcher2
1.4GB


Shogun 2
1.2GB
Settings und Benchmark-Szene


Dirt3, etwas über 1GB



Call of Duty Black Ops
1GB


Starcraft II
Knapp 1GB schon in der 1. Misson der Kampagne


CIV5:
1.25GB


COD6/MW2
1GB schon in einer der 1. Missionen


ARMA 2
800MB im BootCamp



Battlefield 2: Bad Company: Gerade so 600MB


Borderlands, Unreal-Engine-typisch keine 400MB



Dirt II: Etwas über 600MB


NFS Shift
Fast 1GB


Batman Arcam Asylum: 640MB,


Metro 2033: Nur knapp über 600MB in DX9

In DX11 knapp 1GB



Sacred2 fast 900MB


Risen nur 700MB



Spiele mit den Anfangsbuchstaben A bis E
Spiele mit den Anfangsbuchstaben F bis Q
Spiele mit den Anfangsbuchstaben R bis Z

Normalerweise sind die neueren Screens immer in 2560x1600 gemacht, aber das sollte euch nicht stören, die Bildschirm-Größe geht abhängig von der Grafik-Engine nur wenig in den VRAM-Gebrauch ein, der Löwenanteil sind Texturen und AA-Modi (deshalb hab ich den AA-Modi extra klein gehalten, ausserdem geht mir dann auch irgendwann die Performance am 30" aus^^). Eine Textur in 4096x4096 braucht im VRAM immer den gleichen Platz, egal ob sie auf dem Bildschirm auf einem Dreieck mit 2x2x3 oder 2000x2000x3000 Pixel zu sehen ist.

Zum Vergleich das es nicht immer von der Bildschirm-Größe abhängt noch schnell zwei Screenshots in 640x480 bzw 800x600 von einem sehr alten Game und einem Game das gar kein AA unterstützt.


GTA4, mit Ini-Datei-Mod in 800x600. Über 1GB VRAM-Gebrauch



Quake 4 in Ultra-Settings und nur 640x480, hier allerdings 8xAA, 16xAF um zu verdeutlichen was AA wirklich an VRAM frisst. Mit 2xAA sind es nur 750MB




Bevor ihr jetzt die Screens auseinandernehmt:

Ich glaube wir könne die Diskussion eigentlich beenden denn im Grunde sind wir uns einig, aus gewissen Perspekiven betrachtet.

1. V-Ram ist immer wichtig.
2. Mehr V-Ram "kann" die Performance steigern.
3. Es kommt immer auf die Settings drauf an die man verwenden will oder kann.
4. Gewisse Spiele nutzen derart viel V-Ram das auch eine kleinere Karte durchaus einen Performancezuwachs bekommen "könnte"
5. Wer nicht grade extrem Auflösungen verwendet (jenseits von 1680x1050), nicht Krampfhaft über 4xAA einstellt, kommt bei den "meisten" Spielen (Ausnahmen gibt es immer) auch mit 512MB Karten "noch" gut zurecht.
6. Ein Spiel das mehr als 512MB V-Ram verbraucht, bricht nicht automatisch in den FPS gegenüber dem 1GB Modell ein. Ein Spiel das 600MB benötigt läuft auf einer 1GB Karte nicht unbedingt schneller als auf einer 512MB Karte. Es kommt ganz auf das Spiel drauf an.
7. Grade SSAA und Konsorten, sind Einstellungen die vom durchschnittlichen Spieler nicht wirklich verwendet werden. Das man da sehr viel V-Ram benötigt und es sehr viel Performance kostet, darüber dürfte sich jeder klar sein.
8. Wer mit einer betagen oder mittlerweile schwachen Karte wie einer 3870/4670/8800GT/9800GT mit 512MB erwartet in Full HD mit hohen Settings zu spielen, wird keine Freude haben. Das aber auch nicht mit Karten ihrer Klasse die 1GB V-Ram haben da hier "in der Regel" die GPU zu schwach ist.
 
Zuletzt bearbeitet:
Verstehe das als reservierten VRAM, dedicated memory usage, ist klar, aber "GPU shared memory usage" könnte man auch anders verstehen. Ist das deine Interpretation, oder gibts von Aftterburner sowas wie changelogs? Am Ende ist es wahrscheinlich so wie du vermutest und eine interessantes feature...Zeit mal upzudaten den Kram :>

Unwinder dokumentiert einige seiner Features. Müsste man mal im Guru3D nachlesen.


Here you go.



I forgot to document one more tiny but interesting feature of recently published 4.6.3 beta 2. GPU.dll monitoring plugin was upgraded and received 2 new performance counters: “GPU dedicated memory \ process” and “GPU shared memory \ process”, so you may give it a try. The counters are displaying local and non-local VRAM commits for foreground process, so you may use them to see how much VRAM is allocated by the game you’re currently playing and compare it with total system-wide VRAM usage. The counters were added to help you to compare apples to apples and oranges to oranges, because recently there was rather interesting post @ resetera (https://www.resetera.com/threads/vram-in-2020-2024-why-10gb-is-enough.280976/) dedicated to VRAM usage measurement. While it contains a few true statements, it also contains good porting of misunderstanding and false claims and in result it confuses readers even more. So the post claims that:

- Games use less VRAM than you see in GPU-Z, MSI AB, Precision, HwInfo etc. That’s correct statement. Games run in multitasking environment. Games do not own whole VRAM exclusively, it is shared between all running processes in the system. Even before you start your game, standard background applications of almost every modern PC like Steam, internet browsers, background video streaming/recording applications and even OS itself (e.g. DWM aka Desktop Windows Manager, OS component responsible for hardware accelerated desktop windows rendering) eat from few hundred megabytes to few gigabytes of VRAM. All that dedicated VRAM consumed by background processes also counts and displayed in total VRAM usage in tools mentioned above. Total dedicated VRAM minus VRAM consumed by all background processes form VRAM budget for a game, i.e. amount of VRAM the game can commit and use without causing VRAM evictions for other processes and degrading system performance. The budget is expected to be less (sometimes few gigabytes less) than total amount of VRAM installed on your graphics card.

- Misleading applications like GPU-Z, MSI AB, Precision, HwInfo display absolutely useless VRAM allocation value opposing to the only real usage reported by budget API and displayed by Special K. That’s false statement. First, there is no any “allocated VRAM” versus “real VRAM usage”. Real usage he is referencing is also nothing but exactly the same allocation, i.e VRAM commit but in context of single game process. Any form of VRAM usage monitoring (including the “real” one based on DXGI budget monitoring) is displaying you current amount of commited/allocated VRAM. DXGI budget monitoring API was added by Microsoft to help 3D application developers to avoid overcommiting VRAM. So it is just giving you your current VRAM commit limit (budget) and allows you to track how much you’ve already commited. While it is _extremely_ useful performance counter for a developer on game development stage, it doesn’t allow you to see whole system picture when your profile whole system performance, doesn’t allow you to see how much VRAM other applications commited, how much of this total commited VRAM is currently resident in local VRAM and how close to physical VRAM limit (and VRAM eviction related stuttering) we’re. So those are nothing but VRAM commits displayed on different (game/system) levels and both are useful.

New performance counters (“GPU dedicated memory \ process” and “GPU shared memory \ process” exported by GPU.dll plugin) just allow you to see this “real usage” (application specific VRAM commit in reality). But instead of using in-process DXGI budget API it uses more low-level and advanced D3DKMT API, which allows to peek into process specific D3D performance counters from different processes. Due to that reason new “GPU dedicated memory \ process” and “GPU shared memory \ process” are currently not supported for EAC/BattleEye protected games (as they require opening game process from external application, such request won't work for EAC/BE protected games). Here is the example of using new performance counters in MSFS 2020:

View attachment 1987

The first one in RTSS “Mem” line, 5290MB, is a total amount of VRAM commited by display driver + all running processes and residing in local videomemory. It is MSI AB’s built in “Memory usage” performance counter taking data from NVAPI on NVIDIA GPU (on AMD GPUs native VRAM monitoring is not exposed by their API so it is read via D3DKMT by MSI AB and matches with the second performance counter). The second one in RTSS “Mem” line, 5125MB, is total amount of VRAM commited by all running processes and residing in local videomemory. Unlike the first one, it doesn’t include internal display driver’s VRAM allocations. So it is expected to be a couple hundred megabytes lower. It is reported by “GPU dedicated memory usage” counter exported by GPU.dll plugin and comes from D3DKMT. The third one, 3446MB, is VRAM commited by foreground process (i.e. MSFS 2020 game). It comes from "GPU dedicated memory usage \ process" counter exporeted by GPU.dll plugin and duplicates GPU budget usage, displayed by MSFS developer overlay.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
The counters are displaying local and non-local VRAM commits for foreground process, so you may use them to see how much VRAM is allocated by the game you’re currently playing and compare it with total system-wide VRAM usage.
Ah super, da ist ja tatsächlich die ausführliche Erklärung! :) Der entscheidende Satz nochmal als quote o.g.
Systemweit und nur tatsächlich vom game genutzt, ok! :>
 
Allocated by the game heißt aber nur, dass der Speicherplatz vom Programm reserviert wurde. Nicht dass er gebraucht wird. Die Erneuerung ist nur, dass Du nicht den gesamten allokierten VRAM des Rechners siehst, sondern den allokierten VRAM des Programms.
 
bei COD ist es der Punkt "Cache Point Shadows" und der darunter, oder wie die sich schimpfen. Die den ganzen Speicher zuballern.
Und wenn Du das aktivierst, dann wird es wohl auch "gebraucht" :-) bzw. sinnvoll genutzt.
Kann man natürlich auch abschalten. Dann wirds nicht so viel.
 
Wenn Du damit Delta mehr Verbrauch VRam erzeugst, dann wird das Delta natürlich gebraucht.
 
habe die beta installiert... ich hab die punkte leider nicht zur auswahl?

Unbenannt.JPG
 
Das ist mal lustig. Du bist jetzt der 2. der das sagt. Dabei hast Du genau wie ich ne Turing.
Eventuell muss der RTSS dafür auch geupdated werden? Ein Neustart nötig?
 
rtss ist auch gleich mitgeupdatet aber ich hab direkt die version aus dem download von 3dguru genommen.

7.3.0 beta 6 ist rtss
 
Ich werde später auch mal updaten und schauen obs bei mit ner gtx1070 auch nicht zur Auswahl steht.
 
@ Hisn

wie hast du die Frametimes eigentlich wieder so flach bekommen?

ich habs immer noch nicht gepackt :d
 

Anhänge

  • rgergegr.JPG
    rgergegr.JPG
    75,9 KB · Aufrufe: 138
Ich habe gesagt "alle Objekte sind Balken" und dann den Frametime-Graph als Ausnahme definiert^^
Glaub ich.
Ich schau morgen nochmal genau nach, wenn ich wieder am Rechner bin.
 
Die Punkte erscheinen wenn man unter (Aktivierung der Hardwarekurven) die Gpu.dll auswählt und die Punkte aktiviert. Ich hatte diese vorher auch nicht.

Siehe Bild:
 
Zuletzt bearbeitet:
Mit Pascal Karten scheint das sich nicht Installieren zu lassen:

Unbenannt.PNG

Oder mache ich was falsch? :d
 
Ja machst du. Beende erst einmal Afterburner und den Statistikserver. Notfalls mit dem Taskmanager die laufenden Prozesse killen. Oder klassisch die Software deinstallieren (reboot) und dann erneut installieren.
 
Bin einfach jetzt auf ignorieren gegangen und er hat es Installiert.

Oder ist dieser RTCore wichtig?
Beitrag automatisch zusammengeführt:

Die Punkte erscheinen wenn man unter (Aktivierung der Hardwarekurven) die Gpu.dll auswählt und die Punkte aktiviert. Ich hatte diese vorher auch nicht.

Siehe Bild:
Wahrscheinlich schon, da das bei mir nicht zur Auswahl steht ^^
 
Ich habe das jetzt bei mir auch mal zum testen eingestellt. Nur nochmal zur Sicherheit, wie würdest du die Werte interpretieren @HisN ?

dedicated = von Tomb Raider angefordert?
GGDR5 oben = Insgesamt vom System angefordert?
shared = ?

tomb_raider.png
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh