2017-01-17 1 views
0

Aus Neugier und etwas seltsames Verhalten Beobachtung.
Wie wird der Adressraum für den x86-Prozess dargestellt, wenn sowohl die Zuweisung für den Prozess selbst mit Win32-Speicherverwaltungsfunktionen (malloc/new afterall) als auch die Zuweisung von Texturen auf der integrierten Intel-GPU erfolgt, die den gemeinsamen Speicher der Maschine verwendet? Sind die GPU-Zuweisungen Teil des Prozessadressraums? Seit ich heute seltsame Dinge gesehen habe, die mit meinem Prozess passiert sind. Ich benutze x86-Prozess auf x64-Maschine, mein Prozess festgeschrieben Speichergröße ist etwa ~ 1,3 GB, die GPU Shared Memory-Verbrauch ist ~ 600 MB und ich beginne ENOMEM von HeapAlloc beim Versuch, 32 MB Puffer zu reservieren. Ich glaube nicht, Fragmentierung ist hier etwas zu tun, da der Prozess läuft bis zur Minute. So hatte ich den Eindruck, dass der GPU-Speicher im Prozessadressraum gezählt wird, sonst kann ich nicht erklären, wie die HeapAlloc Null für CRT-Heap zurückgibt. Randnotiz, DLL ohne/LARGEADDRESSAWARE verlinkt, also sieht 2Gb wie die Summe der obigen Zahlen aus (1.3 + 0.6)
Bin ich richtig? Falsch? Kann mir jemand erklären, wie es funktioniert?Prozessspeicher, GPU Shared Memory und x86 Prozess auf x64 Windows Adressraum

EDIT001: Eine kleine Klarstellung, verbraucht die GPU ~ 600Gb nicht aus heiterem Himmel, aber da ich Texturen mit DirectX zuweisen.

EDIT002: Test hinzugefügt I-Device-Initialisierung übersprungen hier
constexpr size_t dim = 5000; CD3D11_TEXTURE2D_DESC texDescriptor (DXGI_FORMAT_D24_UNORM_S8_UINT, Abblenden, Abblenden, 1, 1, D3D11_BIND_DEPTH_STENCIL);

std::vector<std::vector<uint8_t>> procData; 
std::vector<CComPtr<ID3D11Texture2D>> gpuData; 

// Some device/context init here 

for(;;) 
{ 
    { 
     CComPtr<ID3D11Texture2D> tex; 
     hr = device->CreateTexture2D(&texDescriptor, nullptr, &tex); 
     if(SUCCEEDED(hr)) 
     { 
      gpuData.emplace_back(tex); 
     } 
     else 
     { 
      std::cout << "Failed to create " << gpuData.size() << "th texture." << std::endl; 
     } 
    } 
    { 
     try 
     { 
      std::vector<uint8_t> buff(dim * dim, 0); 
      procData.emplace_back(buff); 
     } 
     catch(std::exception& ex) 
     { 
      std::cout << "Failed to create " << procData.size() << "th buffer." << std::endl; 
     } 
    } 
} 

Nur zur Erinnerung, ist es x86-Prozess, ohne LARGEADRESSAWARE Einstellung, so, 2Gb zu Verfügung. Der obige Code erzeugt 35 Puffer und 34 Texturen. Wenn Sie den Texturerstellungsblock auskommentieren, werden 70 Puffer erstellt. Nun ...

+0

Ich bin kein Experte in GPU, aber die virtuelle Speicherzuordnung für jeden angegebenen Prozess kann leicht von [VMMap] (https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx) visualisiert werden. Ich empfehle Ihnen, mit diesem Tool zu spielen und Adressen von Puffern zu drucken, die Sie interessieren, damit Sie bestimmen können, zu welchem ​​Bereich sie gehören. –

+0

Bereits getan ... es gibt nichts besonderes auf den ersten Blick, gehen Figur – kreuzerkrieg

Antwort

0

nein. "Adressraum verarbeiten" bedeutet in Windows Speicherseiten, die für die Aufgabe reserviert sind. Um mit dem Videospeicher umgehen zu können, benötigen Sie ddk stuff.just "app" kann solche Dinge nicht tun und besitzt nichts "video".

+0

Klärung der Frage hinzugefügt – kreuzerkrieg

+0

RAM wird von Grafikkarte auf Hardware-Ebene geschnitten.Es hat keine Ahnung über Ihren Prozess –

+0

Sicher? vielleicht auf Treiberebene? andernfalls wird dem Betriebssystem nicht bekannt sein, dass der Speicher von ihm "gestohlen" wird ... – kreuzerkrieg