简体   繁体   English

x64 Windows地址空间上的进程内存,GPU共享内存和x86进程

[英]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? 当使用win32内存管理功能为进程本身分配内存( malloc/new afterall放在那儿)并在使用机器共享内存的集成Intel GPU上分配纹理时,x86进程的地址空间如何呈现? Is the GPU allocations are part of process address space? GPU分配是进程地址空间的一部分吗? 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. 我在x64机器上使用x86进程,进程的承诺内存大小约为1.3Gb,GPU共享内存消耗约为600Mb,当尝试分配32Mb缓冲区时,我开始从HeapAlloc获取ENOMEM 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. 因此,我给人的印象是GPU内存是在进程地址空间中计算的,否则我无法解释HeapAlloc为何会为CRT堆返回null。 Side note, DLL linked without /LARGEADDRESSAWARE, so 2Gb looks as the sum of above numbers (1.3+0.6) 旁注,DLL链接时没有/ LARGEADDRESSAWARE,因此2Gb看起来是上述数字的总和(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. EDIT001:稍微澄清一下,GPU消耗了大约600Gb的内存,但不是因为我使用DirectX分配了纹理。

EDIT002: Test added I skipped device initialization here EDIT002:已添加测试,在此我跳过了设备初始化
constexpr size_t dim = 5000; constexpr size_t dim = 5000; CD3D11_TEXTURE2D_DESC texDescriptor(DXGI_FORMAT_D24_UNORM_S8_UINT, dim, dim, 1, 1, D3D11_BIND_DEPTH_STENCIL); 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. 提醒一下,它是x86进程,没有LARGEADRESSAWARE设置,因此2Gb可用。 The above code produces 35 buffers and 34 textures. 上面的代码产生35个缓冲区和34个纹理。 If you comment out the texture creating block, 70 buffers created. 如果注释掉纹理创建块,则会创建70个缓冲区。 Well... 好...

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". Windows中的“进程地址空间”表示为任务分配的内存页面。要处理视频内存,您​​将需要ddk的东西。仅“ app”不能做这种事情,并且不拥有任何“ video”。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM