CODEWITHSUNDEEP
windowsvisual-c++memory-managementgpudirectx-11
kreuzerkrieg
kreuzerkrieg

Reputation: 3219

Process memory, GPU shared memory and x86 process on x64 windows address space

Out of curiosity and some strange behavior observation.
How is the address space for x86 process presented when allocating both for the process itself using win32 memory management functions (malloc/new afterall go down there) and allocating textures on integrated intel GPU which uses machine's shared memory? Is the GPU allocations are part of process address space? Since I've seen today strange stuff happening to my process. I'm using x86 process on x64 machine, my process committed memory size is about ~1.3Gb, the GPU shared memory consumption is ~600Mb and I start to get ENOMEM from HeapAlloc when trying to allocate 32Mb buffer. I dont believe fragmentation is something to deal with here since the process runs up to minute. So I got the impression that the GPU memory is counted in the process address space, otherwise I cant explain how come the HeapAlloc returns null for CRT heap. Side note, DLL linked without /LARGEADDRESSAWARE, so 2Gb looks as the sum of above numbers (1.3+0.6)
Am I right? Wrong? Can anyone explain how it works?

EDIT001: A little clarification, the GPU consumes ~600Gb not out of the blue, but since I allocate textures using DirectX.

EDIT002: Test added I skipped device initialization here
constexpr size_t dim = 5000; CD3D11_TEXTURE2D_DESC texDescriptor(DXGI_FORMAT_D24_UNORM_S8_UINT, dim, dim, 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;
        }
    }
}

Just to remind, it is x86 process, with no LARGEADRESSAWARE setting, so, 2Gb available to it. The above code produces 35 buffers and 34 textures. If you comment out the texture creating block, 70 buffers created. Well...

Upvotes: 0

Views: 369

Answers (1)

Алексей Неудачин
Алексей Неудачин

Reputation: 415

no. "process address space" in windows means memory pages allocated for task.to deal with video memory you'll need ddk stuff.just "app" cant do things of this kind and doesnt own anything "video".

Upvotes: 0

Related Questions