VRAM Allocator CUDA-Version
- Ersteller HisN
- Erstellt am
L
Laggy.NET
Gast
Okay, deaktiviertes overlay hat geholfen, aber jetzt schmiert mir nach dem zweiten mal Starten CapFrameX ab, auch nach Neuinstallation. Konnte nur eine einzige Messung machen und darstellen und die war in SotTR ohne VRAM Allocator.
Jetzt hab ich keine Lust mehr.
Dann muss halt der Text reichen.
Hab jetzt nochmal nen Test mit Battlefield V gemacht, weil ich weiß, dass es den VRAM garantiert ganz voll macht.
Max Details incl. Ultra Texturen, 200% Auflössungsskalierung und Speicherlimitierung deaktiviert. Mehr geht nicht.
VRAM ist bei über 4050 MB, die Performance komplett im Keller.
Folgendes ist zu beobachten:
Wenn ich mit diesen Settings ins Menü gehe, dann bin ich bei 3,8 GB Auslastung. Sobald ich aufs Übungsgelände klicke und es lade, sinkt die VRAM Auslastung sofort auf etwa 1 GB und klettert danach auf knapp über 4GB, bis das Level geladen ist.
Wenn ich jetzt den VRAM Allocator nehme, die 3350 MB einstelle (mehr geht anscheinend wirklich nicht) und BF V starte, dann bin ich schon im Menü bei knapp über 4 GB VRAM Auslastung. Wenn ich dann das Übungsgelände lade, dann geht die VRAM Auslastung erneut auf 1 GB runter ehe das fertig geladene Level den VRAM dann wieder auf knapp über 4 GB füllt. Also passiert wieder das gleiche wie schon vorher beschrieben. Der reservierte Speicher wird ausgelagert und bleibt dann ausgelagert und hat somit logischerweise auch keinen Einfluss mehr auf die Performance.
Frametimes sind zumindest laut Afterburner in beiden Fällen identisch. Ich hab aber auch allgemein keinerlei größere Framtime Ausreißer, weder in SotTR noch in BFV, egal ob mit oder ohne VRAM Allocator.
Jetzt hab ich keine Lust mehr.
Dann muss halt der Text reichen.
Hab jetzt nochmal nen Test mit Battlefield V gemacht, weil ich weiß, dass es den VRAM garantiert ganz voll macht.
Max Details incl. Ultra Texturen, 200% Auflössungsskalierung und Speicherlimitierung deaktiviert. Mehr geht nicht.
VRAM ist bei über 4050 MB, die Performance komplett im Keller.
Folgendes ist zu beobachten:
Wenn ich mit diesen Settings ins Menü gehe, dann bin ich bei 3,8 GB Auslastung. Sobald ich aufs Übungsgelände klicke und es lade, sinkt die VRAM Auslastung sofort auf etwa 1 GB und klettert danach auf knapp über 4GB, bis das Level geladen ist.
Wenn ich jetzt den VRAM Allocator nehme, die 3350 MB einstelle (mehr geht anscheinend wirklich nicht) und BF V starte, dann bin ich schon im Menü bei knapp über 4 GB VRAM Auslastung. Wenn ich dann das Übungsgelände lade, dann geht die VRAM Auslastung erneut auf 1 GB runter ehe das fertig geladene Level den VRAM dann wieder auf knapp über 4 GB füllt. Also passiert wieder das gleiche wie schon vorher beschrieben. Der reservierte Speicher wird ausgelagert und bleibt dann ausgelagert und hat somit logischerweise auch keinen Einfluss mehr auf die Performance.
Frametimes sind zumindest laut Afterburner in beiden Fällen identisch. Ich hab aber auch allgemein keinerlei größere Framtime Ausreißer, weder in SotTR noch in BFV, egal ob mit oder ohne VRAM Allocator.
Z
ZeroStrat
Gast
Ist interessant. Ich beobachte sowas wie Swapping hier gar nicht. Ich müsste mal einen Swapping Test über mittlere Zugriffslatenzen einbauen.
L
Laggy.NET
Gast
Hab noch ein paar Screenshots gemacht, wo man das Swapping schön sieht:
Hier BFV mit max. Details und 200% Auflösungsskalierung. Speicherlimit ist ingame ausgeschaltet.
Man sieht hier, wie das Menü erst den Speicher voll macht und sobald ich dann in der Mitte des Graphen das Übungsgelände lade, wird der VRAM freigeräumt und mit den Daten der Map wieder vollgeladen.
BFV wieder geschlossen. Jetzt starte ich vorher den VRAM Allocator und setze die 3350 MB:
Jetzt starte ich BFV mit den gleichen Settings wie zuvor:
Man sieht jetzt wieder, wie das Menü den VRAM voll macht und dabei links unten den gemeinsamen GPU Speicher voll macht. Das war vorher nicht der Fall.
Man sieht auch, wie das Laden der Map wie zuvor erst die VRAM Belegung einbrechen lässt, und dann wieder ansteigen lässt.
Und so siehts aus, nachdem ich BF V geschlossen habe und der VRAM Allocator weiterhin läuft.
Man sieht, dass nahezu alles, was das Tool vorher reserviert hat, jetzt ausgelagert ist und dort auch weiterhin bleibt. Und genau das sollte ja eigentlich nicht passieren...
Hier BFV mit max. Details und 200% Auflösungsskalierung. Speicherlimit ist ingame ausgeschaltet.
Man sieht hier, wie das Menü erst den Speicher voll macht und sobald ich dann in der Mitte des Graphen das Übungsgelände lade, wird der VRAM freigeräumt und mit den Daten der Map wieder vollgeladen.
BFV wieder geschlossen. Jetzt starte ich vorher den VRAM Allocator und setze die 3350 MB:
Jetzt starte ich BFV mit den gleichen Settings wie zuvor:
Man sieht jetzt wieder, wie das Menü den VRAM voll macht und dabei links unten den gemeinsamen GPU Speicher voll macht. Das war vorher nicht der Fall.
Man sieht auch, wie das Laden der Map wie zuvor erst die VRAM Belegung einbrechen lässt, und dann wieder ansteigen lässt.
Und so siehts aus, nachdem ich BF V geschlossen habe und der VRAM Allocator weiterhin läuft.
Man sieht, dass nahezu alles, was das Tool vorher reserviert hat, jetzt ausgelagert ist und dort auch weiterhin bleibt. Und genau das sollte ja eigentlich nicht passieren...
- Registriert
- Nov. 2005
- Beiträge
- 83.324
L
Laggy.NET
Gast
Refreshen wäre vermutlich kontraproduktiv, da wahrscheinlich pausenlos versucht wird, den Block auszulagern. Das heißt, er würde ausgelagert werden und sobald der Refresh kommt wieder zurückgeholt werden.
Damit würde man ständig die Speicherbandbreite beanspruchen. Und Speicherbandbreite ist genau das, was gebraucht wird, wenn der VRAM voll ist.
Man hätte somit doppelten Performanceimpact. Einmal Speichermangel und einmal reduzierte Speicherbandbreite für das Spiel.
Aber ich klinke mich an der Stelle mal aus. Was mir aufgefallen ist hab ich euch mitgeteilt und ich hoffe es hilft, das Tool besser zu machen bzw. das Problem zu verstehen. Wär natürlich ne feine Sache, wenn sich das Swapping umgehen lässt.
Damit würde man ständig die Speicherbandbreite beanspruchen. Und Speicherbandbreite ist genau das, was gebraucht wird, wenn der VRAM voll ist.
Man hätte somit doppelten Performanceimpact. Einmal Speichermangel und einmal reduzierte Speicherbandbreite für das Spiel.
Aber ich klinke mich an der Stelle mal aus. Was mir aufgefallen ist hab ich euch mitgeteilt und ich hoffe es hilft, das Tool besser zu machen bzw. das Problem zu verstehen. Wär natürlich ne feine Sache, wenn sich das Swapping umgehen lässt.
@HisN Das beschriebene Verhalten von @Laggy.NET entspricht quasi ein Swapping vom VRAM in den System RAM.
Man bräuchte zumindest einen Job auf dem GPU, der durchgehend Zugriffe auf den Speicherbereich ausführt. In den Fall wird es spannend, wie der GPU Treiber die Daten verwaltet.
Man bräuchte zumindest einen Job auf dem GPU, der durchgehend Zugriffe auf den Speicherbereich ausführt. In den Fall wird es spannend, wie der GPU Treiber die Daten verwaltet.
L
Laggy.NET
Gast
Mal ne blöde Frage. Kann man diesen "gemeinsamen GPU Speicher" irgendwo konfigurieren?
Ich verstehe allgemein nicht, warum das 8 GB sind. Von was ist das abhängig? (ich habe 16 GB RAM).
Wenn man diesen Speicherbereich auf ein Minimum reduzieren könnte, könnte man vielleicht auch das Swapping verhindern.
.... oder es wird dann stattdessen auf der Festplatte bzw. SSD ausgelagert?
Ich verstehe allgemein nicht, warum das 8 GB sind. Von was ist das abhängig? (ich habe 16 GB RAM).
Wenn man diesen Speicherbereich auf ein Minimum reduzieren könnte, könnte man vielleicht auch das Swapping verhindern.
.... oder es wird dann stattdessen auf der Festplatte bzw. SSD ausgelagert?
Z
ZeroStrat
Gast
Ich habe ein bisschen die Hoffnung, dass man mit OpenCL mehr Kontrolle über das Swapping erhält...
Z
ZeroStrat
Gast
Wird schwer mit unserem Projekt HisN. 
Nvidia Support:
"The windows WDDM memory manager (controlled by Microsoft, not NVIDIA) does virtual memory management on the GPU memory, and this applies to both CUDA and gaming. The WDDM memory manager may swap out even CUDA allocations to system memory, according to its own heuristics.
You don't have any direct control over this.
You can influence the behavior by not just allocating the memory using cudaMalloc, but also writing CUDA code that accesses the memory. WHen the CUDA kernel is running, the WDDM memory manager will ensure that the needed allocations are physically resident in GPU memory, not "swapped out" to system memory, which is used as a backing store.
However, when a CUDA kernel is running in a WDDM environment, many other GPU activities (including display updates) are "frozen" until the kernel completes. And if you run the kernel too long, you will hit a WDDM TDR timeout.
So there is no simple method to do this. You could experiment with trying to run a short CUDA kernel (say, 100ms or less, in duration) once every second or so. But this is just playing games with the WDDM memory manager, and at some point your attempt to evaluate game behavior is going to be influenced by this, apart from any memory considerations."
Nvidia Support:
"The windows WDDM memory manager (controlled by Microsoft, not NVIDIA) does virtual memory management on the GPU memory, and this applies to both CUDA and gaming. The WDDM memory manager may swap out even CUDA allocations to system memory, according to its own heuristics.
You don't have any direct control over this.
You can influence the behavior by not just allocating the memory using cudaMalloc, but also writing CUDA code that accesses the memory. WHen the CUDA kernel is running, the WDDM memory manager will ensure that the needed allocations are physically resident in GPU memory, not "swapped out" to system memory, which is used as a backing store.
However, when a CUDA kernel is running in a WDDM environment, many other GPU activities (including display updates) are "frozen" until the kernel completes. And if you run the kernel too long, you will hit a WDDM TDR timeout.
So there is no simple method to do this. You could experiment with trying to run a short CUDA kernel (say, 100ms or less, in duration) once every second or so. But this is just playing games with the WDDM memory manager, and at some point your attempt to evaluate game behavior is going to be influenced by this, apart from any memory considerations."
Zuletzt bearbeitet von einem Moderator:
- Registriert
- Nov. 2005
- Beiträge
- 83.324
Oha,
das ist aber freundlich vom NV-Support so schnell zu antworten.
Naja, wenn man es nicht direkt beeinflussen kann, dann zwingt das Tool doch wenigstens den Memory-Manager zur Arbeit :-)
Für das was ich erreichen wollte ist es allemal ausreichend.
Nochmal vielen Dank für Deine Mühe und Deine Zeit.
das ist aber freundlich vom NV-Support so schnell zu antworten.
Naja, wenn man es nicht direkt beeinflussen kann, dann zwingt das Tool doch wenigstens den Memory-Manager zur Arbeit :-)
Für das was ich erreichen wollte ist es allemal ausreichend.
Nochmal vielen Dank für Deine Mühe und Deine Zeit.
Z
ZeroStrat
Gast
Das sieht wohl ganz danach aus...Hallo32 schrieb:
Z
ZeroStrat
Gast
Wie das?? Welche Grafikkarte hast du? Bei mir wird's immer brav im VRAM allokiert. Hab ne 1080 Ti.Hallo32 schrieb:
Z
ZeroStrat
Gast
Welcher OpenCL Code?