Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

TrommlBomml

Community-Fossil

  • »TrommlBomml« ist der Autor dieses Themas

Beiträge: 2 117

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 382

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 382

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 117

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 117

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 663

Beruf: Softwareentwickler

  • Private Nachricht senden

7

14.09.2017, 08:22

Denk daran, dass Texturen unkomprimiert im Speicher liegen

Werbeanzeige