Hi there! 👋 I've stumbled upon a weird issue while writing unit tests for my library ComputeSharp, which uses a 1:1 C# port of D3D12MA, and I'm investigating it to try to narrow down the root cause. I thought I'd also open an issue here for tracking as it seems to be related to D3D12MA (I've verified I cannot repro it if I just allocate my resources with ID3D12Device::CreateCommittedResource) in some way.

I don't yet have a full minimal repro, but here's the general idea:

• This issue only happens when using a WARP device.
• This issue also only happens when using D3D12MA and a custom pool (here) for UMA devices.
• This issue only happens when working with 3D textures and copying data between them.
• I can only reproduce the issue when the test in question is running after another one with different parameters. If I run it on its own, it passes fine. This makes me think it might be somewhat related to how D3D12MA is reusing allocations.
• I can repro this on 2 different machines with Windows 11. I've had another dev run the tests on his Windows 10 machine and they all passed. Another dev on another Windows 10 machine instead has even more tests failing for whatever reason.

The repro steps I have so far:

• Create a WARP device with D3D_FEATURE_LEVEL_11_0
• Create a copy command queue, fence, etc. (the usual setup)
• Create a D3D12MA allocator, and a pool with these parameters:

D3D12MA_POOL_DESC poolDesc = default;
poolDesc.HeapProperties.CreationNodeMask = 1;
poolDesc.HeapProperties.VisibleNodeMask = 1;
poolDesc.HeapProperties.Type = D3D12_HEAP_TYPE_CUSTOM;
poolDesc.HeapProperties.CPUPageProperty = D3D12_CPU_PAGE_PROPERTY_WRITE_BACK;
poolDesc.HeapProperties.MemoryPoolPreference = D3D12_MEMORY_POOL_L0;

• Create a 3D texture with DXGI_FORMAT_R32_FLOAT format, D3D12_RESOURCE_FLAG_NONE flags, D3D12_RESOURCE_STATE_COMMON state, D3D12_HEAP_TYPE_DEFAULT heap, D3D12MA_ALLOCATION_FLAG_NONE D3D12MA flags, with the UMA pool.
• Fill this texture with sample data, by creating an upload buffer with the allocator (D3D12_HEAP_TYPE_UPLOAD, D3D12_RESOURCE_FLAG_NONE, D3D12_RESOURCE_STATE_GENERIC_READ), using the right byte size depending on the copyable footprint retrieved from the previously allocated 3D texture. Map this resource, write the sample data to it, then create a copy command list and use ID3D12GraphicsCommandList::CopyTextureRegion to copy this data to the actual texture.
• Create another 3D texture, leave this uninitialized (ie. use D3D12MA_ALLOCATION_FLAG_COMMITTED to force zeroing).
• Copy a given volume from the first 3D texture to this new texture (ID3D12GraphicsCommandList::CopyTextureRegion).
• Copy the entire second 3D texture back to be able to verify its contents after the previous copy. That is, allocate a readback buffer just like the upload buffer before, call ID3D12GraphicsCommandList::CopyTextureRegion to it, then map it and copy its contents somewhere you can easily read from (or alternatively just map the buffer and then read directly from there).

Now, running these 2 tests one after the other causes the second one to fail:

1. First test (passing ✅):
   • Source texture size: (512, 512, 3)
   • Destination texture size: (512, 512, 3)
   • Source copy offsets: (0, 0, 0)
   • Destination copy offsets: (0, 0, 1)
   • Copy volume size: (512, 512, 2)
2. Second test (failing ❌):
   • Source texture size: (512, 512, 3)
   • Destination texture size: (512, 512, 4)
   • Source copy offsets: (0, 0, 1)
   • Destination copy offsets: (0, 0, 2)
   • Copy volume size: (512, 512, 2)

By "test failing", I mean that when verifying the data read back from the second texture (the destination one), I get this:

• The depth level 0 is correctly all zeroed ✅
• The depth level 1 is not zeroed. It seems to still have the data from the previous test run, where items were copied at destination dpeth level 1 in the second texture. This time instead the destination depth level is 2, so depth level 1 should just all be 0. We're explicitly passing D3D12MA_ALLOCATION_FLAG_COMMITTED for the destination texture, so it should always be a new allocation with no previous data in it. ❌
• Depth levels 2 and 3 are correctly holding the data copied from the source texture ✅

Just a random thought, but if D3D12MA is in fact accidentlaly not using a committed allocation here and reusing a previous one, it might explain why the behavior is so inconsistent across different OS versions and machines, as the exact way previous allocations are reused and cleared by the OS/driver is undefined? Anyway this is as detailed I could be for this, let me know if there's anything else I can do! I can also try to actually come up with a minimal repro if it helps (though that'd be in C#).

Thanks! 😄

Overview

Let me start by saying that D3D12MA is a great project and it's super easy to integrate, which is awesome 😄

There's one big limitation currently in the way D3D12MA can be used, which is that there is no support for custom heaps. Even when using Allocator::CreatePool to create a custom pool, the POOL_DESC.HeapType specifically mentions in the documentation not to use the CUSTOM heap type, and there is also no way to pass other heap properties for the pool. In general, it would be necessary for POOL_DESC to allow callers to pass a D3D12_HEAP_PROPERTIES value directly (eg. replacing that single HeapType field), so that consumers would have full control on the target heap used for allocations when using that pool.

This would enable a number of scenarios not possible today when using D3D12MA, such as:

• Properly supporting UMA architectures (with a custom heap that's CPU visible)
• Using a custom DEFAULT heap that's also CPU visible (using POOL_L0 and PAGE_ACCESS_WRITE_BACK)
• Using a custom READBACK heap for transfer buffers that can be both read to and written to by the GPU
• Etc.

Proposed solution

The simplest solution I can think of would be to just change this field in POOL_DESC:

 struct POOL_DESC
 {
-    D3D12_HEAP_TYPE HeapType;
+    D3D12_HEAP_PROPERTIES HeapProperties;
 };

That HeapProperties would then be passed internally just like HeapType is today, and then MemoryBlock::Init would use that HeapProperties value to setup the D3D12_HEAP_DESC value before calling ID3D12Device::CreateHeap, instead of just setting the heap type like it does today. As in, minor changes would need to be done here:

https://github.com/GPUOpen-LibrariesAndSDKs/D3D12MemoryAllocator/blob/e56c26d8105a679f22860b865f4c074d19006e88/src/D3D12MemAlloc.cpp#L3425-L3435

This would give consumers of the library much greater flexibility, and it'd make the ability to create custom allocation pools much more worthwhile, as there could be way more customization done on the allocation parameters used by them.

Hello Adam ! Small question regarding defragmentation.

In the documentation it is written :

What it means in practice is that you shouldn't free any allocations from the defragmented pool since the moment a call to BeginPass begins.

One solution that you give is :

A solution to freeing allocations during defragmentation is to find such allocation on the list pass.pMoves[i] and set its operation to D3D12MA::DEFRAGMENTATION_MOVE_OPERATION_DESTROY instead of calling allocation->Release()

However, it is only possible to set the operation after having the pass moves (after the return of the call). Do I need to keep track of allocations that want to be released during computation time or won't it be an issue if releasing occurs ? Could it be simpler to just add a reference to allocations that ends up being part of a move and remove a reference at the end of the pass ?

Hope those questions are not stupid :) Have a nice day !

Is it possible to let the D3D12MA::Allocator inherit from IUnknown and provide implementations for AddRef (this won't conflict with the current use of the member method, AddRef), Release and QueryInterface to be used with Microsoft's intrusive ComPtr? This would be consistent with D3D12 types themselves and with 3th-party tools such as DirectXShaderCompiler which also mimic this former behavior.

With the memory allocator there are some issues from the gpu based validator.

there is an uav which runs fine on the gpu, however i get warnings in the validator.

They do not happen on the cpu validator. If i use only committed memory, there are no such errors. I am looking where this may come from

D3D12 ERROR: GPU-BASED VALIDATION: Dispatch, Incompatible resource state: Resource: 0x000002BA10D56500:'Unnamed ID3D12Resource Object', Subresource Index: [0], Root descriptor type: UAV, Resource State: D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE(0x40) (Promoted from COMMON state), Shader Stage: COMPUTE, Root Parameter Index: [2], Dispatch Index: [21], Shader Code: <couldn't find file location in debug info>, Asm Instruction Range: [0xa-0xffffffff], Asm Operand Index: [0], Command List: 0x000002BA10951520:'CommandList 2, Allocator 0', SRV/UAV/CBV Descriptor Heap: 0x000002BA10693200:'StaticHeapDX12', Sampler Descriptor Heap: 0x000002BA10696300:'StaticHeapDX12', Pipeline State: 0x000002BA4D5C6A00:'TressFXSDFCollision.hlslCollideHairVerticesWithSdf_forward', [ EXECUTION ERROR #942: GPU_BASED_VALIDATION_INCOMPATIBLE_RESOURCE_STATE]

Hello, How do you recommend using this library with residency management. Microsoft has an example about this. Do you have any recommendations about this? Thank you

Hi, I am doing d3d12 programing. it's a few people do the similar work and it's very difficult to find someone to communication. I am try to create a texture, my code like this: ` D3D12_HEAP_PROPERTIES HeapPro; BuildTextureHeapPro(HeapPro); D3D12_RESOURCE_DESC TextureDesc; BuildTextureDesc(TextureDesc); TextureDesc.Alignment = 65536;

D3D12_RESOURCE_ALLOCATION_INFO Info;
Info = Device->GetResourceAllocationInfo(0, 1, &TextureDesc);
mTextureLen = (int)Info.SizeInBytes;

` It works ok in most times. But when the texture width is 1108 and the height is 1440, B8G8R8A8 format, Info.SizeInBytes return a wrong size, which return 6619136. and 1108 * 1440 * 4 = 6382080. I try another way, for example, i try "Device->GetCopyableFootprints(&TextureDesc, 0, 1, 0, &Layouts, nullptr, &RowSizeInBytes, &RequiredSize);", and RequiredSize is 6635344, and it is not the right value. I think the right value is 6635520. Because the row pitch is 4608 and the right value is 4608 * 1440 = 6635520. what is the problem? i google for days and can't find the solution. please help, thankyou!

Hello, I noticed that a couple of tests are currently failing, in particular TestStats and TestID3D12Device4. This happens both when running the pre-built executable, as well as when manually building and running the sample.

I'm getting these two errors (the second is after commenting out the first and re-running the tests):

Test stats Assertion failed: 0 && "C:\Users\Sergio\Documents\GitHub\D3D12MemoryAllocator\src\Tests.cpp" "(" "924" "): !( " "endStats.Total.AllocationCount == begStats.Total.AllocationCount + count" " )", file C:\Users\Sergio\Documents\GitHub\D3D12MemoryAllocator\src\Tests.cpp, line 924

Test ID3D12Device4 Assertion failed: 0 && "C:\Users\Sergio\Documents\GitHub\D3D12MemoryAllocator\src\Tests.cpp" "(" "1372" "): FAILED( " "ctx.allocator->AllocateMemory1(&allocDesc, &heapAllocInfo, session, &alloc)" " )", file C:\Users\Sergio\Documents\GitHub\D3D12MemoryAllocator\src\Tests.cpp, line 1372

System info:

• Windows 10 Pro, x64 (build 19041.782)
• GTX 1080 (driver 456.71)

Hope this helps, keep up the good work! 🙌

StrStrI is undefined no matter what I do.

I've included it like this:

#include <shlwapi.h> #inc.... #pragma comment (lib, "Shlwapi.lib")

Please help.

We upgraded D3D12MA and immediately started seeing an uptick in a crash in the wild. From what we can tell MemoryBlock::Init is blindly using GetDevice4() which may not be available in earlier versions of Windows 10 and code like this will GPF:

#ifdef __ID3D12Device4_INTERFACE_DEFINED__
    HRESULT hr = m_Allocator->GetDevice4()->CreateHeap1(&heapDesc, pProtectedSession, D3D12MA_IID_PPV_ARGS(&m_Heap));
#else
    D3D12MA_ASSERT(pProtectedSession == NULL);
    HRESULT hr = m_Allocator->GetDevice()->CreateHeap(&heapDesc, D3D12MA_IID_PPV_ARGS(&m_Heap));
#endif

Hi, I'm currently trying to implement this library with com smart pointers, but I've run into a problem.

When I use Microsoft::WRL::ComPtrD3D12MA::Allocator allocator, I get the following compiler warning.

C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\winrt\wrl/client.h(235,1): error C2440: '=': cannot convert from 'void' to 'unsigned long' [C:\Users\username\source\repos\D3D12\build\D3D12.vcxproj] [build] C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\winrt\wrl/client.h(235,32): message : Expressions of type void cannot be converted to other types [C:\Users\username\source\repos\D3D12\build\D3D12.vcxproj] [build] C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\winrt\wrl/client.h(228): message : while compiling class template member function 'unsigned long Microsoft::WRL::ComPtrD3D12MA::Allocator::InternalRelease(void) noexcept' [C:\Users\username\source\repos\D3D12\build\D3D12.vcxproj] [build] C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\winrt\wrl/client.h(290): message : see reference to function template instantiation 'unsigned long Microsoft::WRL::ComPtrD3D12MA::Allocator::InternalRelease(void) noexcept' being compiled [C:\Users\username\source\repos\D3D12\build\D3D12.vcxproj] [build] C:\Users\username\source\repos\D3D12\src\DXWindow.hpp(73): message : see reference to class template instantiation 'Microsoft::WRL::ComPtrD3D12MA::Allocator' being compiled [C:\Users\username\source\repos\D3D12\build\D3D12.vcxproj]

However if I use CComPtrD3D12MA::Allocator allocator everything works fine.

The gpuopen docs says this library should work with WRL pointers.

I don't know if I should be mixing both types of smart pointer as my other com objects are using WRL.

Any help is appreciated, thanks.

Hi Adam ! Hope everything is ok !

I wanted to know if something was a feature or more of a bug.

I have a resource that is created with the allocator. By default, this resource (because it can be created without the allocator) is using the D3D12_HEAP_FLAGS : D3D12_HEAP_FLAG_CREATE_NOT_ZEROED. Because of this extra flag, the function CalcDefaultPoolIndex considers that the resource should not be created in a default pool, return -1 and the resource will be created as committed.

Is it the correct behaviour or should it be created as placed (since a placed resource will never be zeroed) ?

https://github.com/GPUOpen-LibrariesAndSDKs/D3D12MemoryAllocator/blob/7597f717c7b32b74d263009ecc15985b517585c7/src/D3D12MemAlloc.cpp#L8023

If you are using the same heap for buffers and textures, it would be possible for a "small" texture with 4kb alignment to be placed in that memory space after the buffer, if the size is not aligned up. Is there any other reason you align up the size when you allocate memory for a buffer?

Or is the intention to always use separate heaps for buffers and textures?

Just a few modifications added for compilation using XGDK and specific DX12 for xbox related headers. Also modified ressource alignement allocation management to work with UMA arch. (DX12 on xbox and consoles)