STATUS_ACCESS_VIOLATION when requesting device for Intel iGPU on wgpu 27.0.1

[vorporeal]

Description
#8110 introduces a regression which produces a STATUS_ACCESS_VIOLATION crash when requesting a device for an Intel(R) Iris(R) Xe Graphics integrated graphics adapter. The crash does not reproduce at 1f10d0c, but does at 05cc6dc.

Repro steps
I can reproduce this by running cargo run --bin wgpu-examples hello_triangle with WGPU_BACKEND set to dx12.

Expected vs observed behavior
Should be able to request device without any crash (as worked in the previous commit on trunk).

Extra materials

Screenshot of relevant stack trace from windbg:

Platform

• Windows 11 (10.0.26100)
• Intel i9-13900H CPU
• Intel(R) Iris(R) Xe Graphics (driver version 32.0.101.6913)
  • This is the device that is having issues.
• NVIDIA RTX 2000 Ada Generation Laptop GPU
  • This continues to work without issues.

[vorporeal]

My guess is this is relevant: I was doing some poking at things that changed in that PR, and was curious what the value of mesh_shader_supported was for this device, and it's the only device on my system for which mesh_shader_supported is false.

[inner-daemons]

My guess is this is relevant: I was doing some poking at things that changed in that PR, and was curious what the value of mesh_shader_supported was for this device, and it's the only device on my system for which mesh_shader_supported is false.

Are you referring to this line of code right here, in that this code runs fine? It isn't surprising that mesh_shader_supported would be false on an integrated device btw.

        let mesh_shader_supported = {
            let mut features7 = Direct3D12::D3D12_FEATURE_DATA_D3D12_OPTIONS7::default();
            unsafe {
                device.CheckFeatureSupport(
                    Direct3D12::D3D12_FEATURE_D3D12_OPTIONS7,
                    <*mut _>::cast(&mut features7),
                    size_of_val(&features7) as u32,
                )
            }
            .is_ok()
                && features7.MeshShaderTier != Direct3D12::D3D12_MESH_SHADER_TIER_NOT_SUPPORTED
        };
        features.set(
            wgt::Features::EXPERIMENTAL_MESH_SHADER,
            mesh_shader_supported,
        );

[inner-daemons]

I'm guessing it comes from the command signature creation, which I forgot to gate behind the feature. Very sloppy. Fortunately, the fix should be very easy.

[vorporeal]

Are you referring to this line of code right here

Yep, that feature is unavailable for my iGPU.

FWIW, when I change the code that generates the draw_mesh command signature to do the same thing as the dispatch command signature below, I still get the crash. Not 100% convinced that it's simply a matter of feature-gating the signature.

[inner-daemons]

The stack trace you shared shows there's definitely a crash within root signature creation. Can you make sure you aren't getting a different error when using the fix you did?

[vorporeal]

Ah, my apologies - I had only changed one of the two places where the draw_mesh command signature is generated (Device::new(), but not Device::create_pipeline_layout()). When I change both of them to use D3D12_INDIRECT_ARGUMENT_TYPE_DISPATCH, the crash goes away.

[inner-daemons]

Great, thanks for that! If you could do a quick patch PR that would be really great. Then I'm sure we would backport it to 27.0.2.

[vorporeal]

I could do that, sure. Presumably we want to make draw_mesh optional within CommandSignatures, with its presence being conditioned on the feature?

If so, what should we do at the places in CommandEncoder that reference it when it is unset? Looks like we simply panic in the Vulkan implementation - good enough here too?