Presently I am engaged on updating a Home windows 11 DX12 desktop app to make the most of the applied sciences launched by DX12 Final (i.e. mesh shaders, VRS & DXR).
All of the official samples for Final had been efficiently compiled in VS2022 and run in Debug construct on a Core i9/RTX3070 laptop computer PC. As a primary step, I want to start migrating as a lot static (i.e. unskinned) geometry over from the traditional (IA-vertex shader) rendering pipeline over to the Amplification->Mesh shader pipeline.
I am naturally utilizing code from the official samples to facilitate this, and within the course of I’ve encountered a really unusual challenge which solely triggers in my app, however not within the compiled supply mission.
The precise drawback pertains to establishing meshlet instancing culling & dynamic LOD choice. When setting descriptors into the mesh shader SRV heap, my app was failing to create a CBV:
// Mesh Information Buffers
D3D12_CONSTANT_BUFFER_VIEW_DESC cbvDesc{};
cbvDesc.BufferLocation = m.MeshInfoResource->GetGPUVirtualAddress();
cbvDesc.SizeInBytes = MeshletUtils::GetAlignedSize<UINT>(sizeof(MeshInfo)); // 256 bytes which is right
device->CreateConstantBufferView(&cbvDesc, OffsetHandle(i)); // generates error
A CBV into the descriptor vary could not be generated as a result of the useful resource’s GPU handle vary was created with solely 16 bytes:
D3D12 ERROR: ID3D12Device::CreateConstantBufferView:
pDesc->BufferLocation + SizeInBytes – 1 (0x0000000008c1f0ff) exceeds
finish of the digital handle vary of Useful resource
(0x000001BD88FE1BF0:’MeshInfoResource’, GPU VA Vary:
0x0000000008c1f000 – 0x0000000008c1f00f). [ STATE_CREATION ERROR #649:
CREATE_CONSTANT_BUFFER_VIEW_INVALID_RESOURCE]
What made this irritating was the code is similar to the official pattern, however the pattern was compiling with out challenge. However after many hours of making an attempt dumb issues, I lastly determined to look at the scale of the MeshInfo construction, and therein lay the answer.
The MeshInfo struct is outlined within the pattern’s Mannequin class as:
struct MeshInfo
{
uint32_t IndexSize;
uint32_t MeshletCount;
uint32_t LastMeshletVertCount;
uint32_t LastMeshletPrimCount;
};
It’s 16 bytes in dimension, and handed to the useful resource’s description previous to its creation:
auto meshInfoDesc = CD3DX12_RESOURCE_DESC::Buffer(sizeof(MeshInfo));
ThrowIfFailed(device->CreateCommittedResource(&defaultHeap, D3D12_HEAP_FLAG_NONE, &meshInfoDesc, D3D12_RESOURCE_STATE_COPY_DEST, nullptr, IID_PPV_ARGS(&m.MeshInfoResource)));
SetDebugObjectName(m.MeshInfoResource.Get(), L"MeshInfoResource");
However clearly I wanted a 256 byte vary to evolve with D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT, so I modified meshInfoDesc to:
auto meshInfoDesc = CD3DX12_RESOURCE_DESC::Buffer(sizeof(MeshInfo) * 16u);
And the mission compiles efficiently.
So my query is, why is not this GPU digital handle error additionally occurring within the pattern???
PS: It was essential to rename Mannequin.h/Mannequin.cpp to MeshletModel.h/MeshletModel.cpp to be used in my mission, which is predicated on the DirectX Device Equipment framework, the place Mannequin.h/Mannequin.cpp recordsdata exist already for the DXTK inflexible physique animation impact.
