Wgpu: DX12 crash on create_pipeline_layout: Can't serialize root signature: -2147024809

[DasEtwas]

Windows 10, wgpu 0710a7a9116ffca8039ce7d8fc58197b93e02d3c

HRESULT: -2147024809 = 0x80070057

I'm using a fairly complex bind group layout. A panic! is triggered inside the dx12 gfx-rs backend when calling RootSignature.

wgpu device features:

Features::PUSH_CONSTANTS|
Features::SAMPLED_TEXTURE_BINDING_ARRAY|
Features::SAMPLED_TEXTURE_ARRAY_NON_UNIFORM_INDEXING|
Features::NON_FILL_POLYGON_MODE,

Copy of PipelineLayoutDescriptor and PipelineLayoutDescriptor::bind_group_layouts

[kvark]

When running from VisualStudio, you should see the actual DX runtime errors printed out to the console. Could you provide those, please?

[DasEtwas]

WARNING: ID3D12CommandList::ClearRenderTargetView: The application did not pass any clear value to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #820: CLEARRENDERTARGETVIEW_MISMATCHINGCLEARVALUE]
WARNING: ID3D12CommandList::ClearDepthStencilView: The application did not pass any clear value to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #821: CLEARDEPTHSTENCILVIEW_MISMATCHINGCLEARVALUE]
^ these come once with every RenderPipeline or their content


ERROR: ID3D12CommandQueue::ExecuteCommandLists: Using ResourceBarrier on Command List (0x0000017A84E64360:'clear shader renderpass'): Before state (0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]) of resource (0x0000017AD8778140:'procedural 2D texture') (subresource: 0) specified by transition barrier does not match with the state (0xC0: D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE|D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE) specified in the previous call to ResourceBarrier [ RESOURCE_MANIPULATION ERROR gfx-rs/wgpu-rs#527: RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]

ERROR: GPU-BASED VALIDATION: ResourceBarrier, StateBefore invalid, Barrier array index [0], Incompatible resource state: Resource: 0x0000017AD8778140:'procedural 2D texture', Subresource Index: [0], Resource State: D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE|D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE(0xc0), Required State Bits: D3D12_RESOURCE_STATE_[COMMON|PRESENT](0x0), Draw Count [0], Dispatch Count [0], Command List: <deleted>,  [ EXECUTION ERROR #942: GPU_BASED_VALIDATION_INCOMPATIBLE_RESOURCE_STATE]

ERROR: ID3D12CommandList::Close: An ID3D12Resource object (0x0000017A84DC9E90:'model static vertex buffer'), referenced in the command list being closed (0x0000017A84E9D4E0:'D3D12 Debug Layer Indirect Command List'), was deleted prior to closing the command list.  This is invalid and can result in application instability. [ EXECUTION ERROR #921: OBJECT_DELETED_WHILE_STILL_IN_USE]
ERROR: ID3D12CommandList::Close: An ID3D12Resource object (0x0000017AD80B2280:'model static vertex buffer'), referenced in the command list being closed (0x0000017A84E9D4E0:'D3D12 Debug Layer Indirect Command List'), was deleted prior to closing the command list.  This is invalid and can result in application instability. [ EXECUTION ERROR #921: OBJECT_DELETED_WHILE_STILL_IN_USE]

apparently no errors are shown for RootSignature things

[kvark]

Could you provide a repro case for us?

[DasEtwas]

I narrowed it down to a BindGroupLayoutEntrys binding and count changing, but I am certain there may be more factors. It seems like the order of elements in BindGroupLayoutDescriptor::entries does not matter.

Butchered hello-triangle with isolated crash variables:
https://github.com/DasEtwas/wgpu-rs/blob/dasetwas/dx-gfx-panic/examples/hello-triangle/main.rs

[kvark]

Thank you for the test case, it helps a ton!

Here is what I found. Our DX12 backend currently places resource for binding X at the descriptor index X within the space of descriptors corresponding to the descriptor set. Unsurprisingly, in order to place an array of resources, we need a contiguous range of descriptors in the space. So the test case fails because it tries to have 10 textures starting at binding 0 and 2 textures starting at binding 2.

@cwfitzgerald I suggest we completely decouple the gfx-rs binding indices from the DX12 descriptor indices. I.e. we basically can have a map stored in DescriptorSetLayout that would do binding -> descriptor_index mapping. It's fairly easy to build one, and it's not difficult to use it consistently when binding resources. It's just work work that needs to be done, but an important one, because otherwise the sampler arrays are not usable on DX12. Or at least, their use is limited: you just have to have such an array either go last, or leave a hole in the binding space on wgpu-side.

[kvark]

@DasEtwas is this a blocker for you atm? Will the suggested workaround be sufficient while we are taking time fixing the real issue?

[DasEtwas]

@DasEtwas is this a blocker for you atm? Will the suggested workaround be sufficient while we are taking time fixing the real issue?

It is sufficient, I can just swap some binding locations around.

[cwfitzgerald]

I suggest we completely decouple the gfx-rs binding indices from the DX12 descriptor indices. I.e. we basically can have a map stored in DescriptorSetLayout that would do binding -> descriptor_index mapping.

Sounds reasonable to me. I won't be able to get to this for a couple days, but I can give it a shot.

[DasEtwas]

Wouldn't this apply to OpenGL as well?

[kvark]

This is DX12-specific, it's in the binding model implementation, which is very different from OpenGL.