Wgpu: HLSL multiple entry points don't work in DirectX12 backend

[suleyth]

Description
A frequent trick in HLSL is to have the entire shader in a single file and compile it into multiple bytecode files later. Mainly for clearance purposes. For example, this:

struct VertexInput {
    float3 Position: Position;
    float3 Color: Color;
};

struct VertexOutput {
    float4 Position: SV_Position;
    float4 Color: Color;
};

VertexOutput VsMain(VertexInput Input) {
    VertexOutput Output;
    Output.Position = float4(Input.Position, 1.0f);
    Output.Color = float4(Input.Color, 1.0f);
    return Output;
}

float4 PsMain(VertexOutput Input): SV_Target {
    return Input.Color;
}

Gets compiled to SPIRV with shaderc as a vertex shader with entry point VsMain and as a fragment shader with entry point PsMain - Two separate spv files but coded in a single file which is way easier.

However, loading these shaders in WGPU with wgpu::include_spirv!() using DirectX12 doesn't work. I don't think it's an entry point recognition error. If you put this in a RenderPipelineDescriptor:

vertex_stage: wgpu::ProgrammableStageDescriptor {
    module: &vs,
    entry_point: "VsMain"
},
fragment_stage: Some(wgpu::ProgrammableStageDescriptor {
    module: &fs,
    entry_point: "PsMain"
}),

WGPU panics with the message failed to create graphics pipeline: Failed to create pipeline: Shader error: Missing entry point: VsMain.

Again, I don't think it's an error with an entry point name - I've double checked that they are correct. And when you deliberately put incorrect names:

vertex_stage: wgpu::ProgrammableStageDescriptor {
    module: &vs,
    entry_point: "asasasas"
},
fragment_stage: Some(wgpu::ProgrammableStageDescriptor {
    module: &fs,
    entry_point: "asadad"
}),

The panic error message is different: error in stage VERTEX: unable to find an entry point matching the Vertex execution model

If you only mess up the fragment_stage name: error in stage FRAGMENT: unable to find an entry point matching the Fragment execution model

Repro steps

1. Write a simple shader like the one above
2. Compile it into separate spv files using the multiple entry points trick
3. Attempt to load them in WGPU code with the DX12 backend in the Instance

Expected vs observed behavior
It would be nice if this feature could be supported everywhere, since I think it's the last step to have first class HLSL support.

Extra materials
Here is the full backtrace with better_panic.
The only CompilerOptions I passed to shaderc::Compiler are setting the source language to HLSL.

Platform
I am in Windows 10, with Rust Nightly MSVC (though with no features activated). I was using the DirectX12 backend, but I tested it with the Vulkan backend too and it worked with no hassle at all.

[grovesNL]

Hi :wave: thanks for the detailed issue!

There were some changes made recently to gfx-backend-dx12 to support multiple entry points that might help with this, in https://github.com/gfx-rs/gfx/pull/3437 and https://github.com/gfx-rs/gfx/pull/3447. Could you check if this patch fixes it for you? You could use cargo patch overrides to test it, or wait for the next gfx-backend-dx12 patch release which will probably come soon.

[kvark]

backend-dx12-0.6.11 has been on crates since 5 days ago. Please double check if that's the one you are using.

[grovesNL]

@kvark the changes from https://github.com/gfx-rs/gfx/pull/3447 seem to be needed here, so we'd probably need to wait for backend-dx12-0.6.12

[grovesNL]

@suleyth the new DX12 backend has been published in versions >= 0.6.12.

Could you check if this allows you to use multiple entry points correctly by updating the DX12 backend in your project? e.g. cargo update or cargo update --package gfx-backend-dx12

[suleyth]

Sure! I have lost the code for the original example, but give me some days and I'll try to replicate the same thing again

[suleyth]

Sorry for the delay! It works fine now! Thanks!