Du bist nicht angemeldet.

Werbeanzeige

TrommlBomml

Community-Fossil

  • »TrommlBomml« ist der Autor dieses Themas

Beiträge: 2 143

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

1

12.09.2017, 23:53

Memory Profiling OpenGL Application mit Visual Studio 2017

Hallo Zusammen,

ich habe eine kleine OpenGL-Anwendung, die die Sponza-Szene lädt und darstellt. Ich habe mir interessehalber den Speicherverbrauch angeschaut und war über die 450MB etwas schockiert und wollte das mit dem Visual Studio Performance Profiler untersuchen. Allerdings verwirrt mich das Ergebnis:



Die ca. 13MB wären eher mein erwartetes Ergebnis, allerdings zeigt der Profiler ja an private Bytes eher so um die 600MB an. Da ich die Anwendung im Release auch im Taskmanager mit ca. 450MB verglichen habe (ich weiß kein Maß, aber als einfache Referenz ja in Ordnung), kann der Overhead zu 13MB nicht nur Debuginformationen oder VS-Daten sein. Wo geht bitte der ganze Speicher hin bzw. woher weiß ich, für was das alles verbraucht wird? Da ich den Profiler bisher sonst in .NET verwende, erstellt mir der Snapshot natürlich einen ordentlichen Speicheraufbau dar, passend zum Gesamtverbrauch laut Graph.

David Scherfgen

Administrator

Beiträge: 10 296

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

2

13.09.2017, 00:04

Wahrscheinlich hält der Grafiktreiber Kopien von Texturen und Geometrie auch im Hauptspeicher. Du kannst ja mal die Szene Schritt für Schritt laden und schauen, wie dabei der Speicherverbrauch steigt.

Tobiking

1x Rätselkönig

  • Private Nachricht senden

3

13.09.2017, 08:03

Ich weiß nicht was in VS genau angezeigt wird, aber häufig wird den Prozessen auch shared libraries und anderes was nur in den virtuellen Adressraum gemappt wird zugerechnet. Beim Process Explorer sieht man bei den Prozessen (Rechtklick -> Properties -> Performance) separate Zahlen dafür wie viel virtuell und physisch belegt wird.

David Scherfgen

Administrator

Beiträge: 10 296

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

4

13.09.2017, 12:37

Bei "Private Bytes" sollten die geteilten DLLs usw. aber nicht mit eingerechnet werden.

TrommlBomml

Community-Fossil

  • »TrommlBomml« ist der Autor dieses Themas

Beiträge: 2 143

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

5

13.09.2017, 14:09

Wahrscheinlich hält der Grafiktreiber Kopien von Texturen und Geometrie auch im Hauptspeicher. Du kannst ja mal die Szene Schritt für Schritt laden und schauen, wie dabei der Speicherverbrauch steigt.


Das müsste ich dann aber ggf. im Grafikdebugger sehen? Werde ich heute Abend ausprobieren.

TrommlBomml

Community-Fossil

  • »TrommlBomml« ist der Autor dieses Themas

Beiträge: 2 143

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

6

13.09.2017, 21:14

@David: Du hast denke mit dem Treiber recht: Ich habe das ganze mal explizit mit meiner dedizierten Grafikkarte laufen lassen an statt meinem Intelchip, der Speicherverbrauch ging auf 64MB zurück. Macht ja auch Sinn, der Interne Chip wird sich ja dem Shared Memory und/oder System Memory bedienen.

Trotzdem immer noch ziemlich viel, was der Treiber an RAM für so eine popelige Szene an RAM verbraucht, meine Objekte verbrauchen insgesamt laut Snapshot nur ein paar KB.

Sylence

Community-Fossil

Beiträge: 1 667

Beruf: Softwareentwickler

  • Private Nachricht senden

7

14.09.2017, 08:22

Denk daran, dass Texturen unkomprimiert im Speicher liegen
Software documentation is like sex. If it's good you want more, if it's bad it's better than nothing.

Werbeanzeige