Bevy: DX12 backend renders various things incorrectly

[cart]

First, we should determine if this is a wgpu issue or a bevy issue. And in the short term we should probably default to Vulkan on windows until this is fixed.

[kvark]

Likely gfx's DX12 fault. I wrote down the workflow of submitting issues like this in #124.
We can also try running Bevy ourselves, if the workflow encounters any hitches.

[cart]

It sounds like the user that reported this tried repro-ing on the wgpu cube example and couldn't. so this might be our problem. ill try to repro.

[jmitchell89]

These HLSL shaders should help determine if its a shader issue.

forward.vert(HLSL):

cbuffer Transform : register(b0)
{
    row_major float4x4 _14_Model : packoffset(c0);
};

cbuffer Camera : register(b0)
{
    row_major float4x4 _67_ViewProj : packoffset(c0);
};


static float4 gl_Position;
static float3 v_Normal;
static float3 Vertex_Normal;
static float3 v_Position;
static float3 Vertex_Position;
static float2 v_Uv;
static float2 Vertex_Uv;

struct SPIRV_Cross_Input
{
    float3 Vertex_Position : TEXCOORD0;
    float3 Vertex_Normal : TEXCOORD1;
    float2 Vertex_Uv : TEXCOORD2;
};

struct SPIRV_Cross_Output
{
    float3 v_Position : TEXCOORD0;
    float3 v_Normal : TEXCOORD1;
    float2 v_Uv : TEXCOORD2;
    float4 gl_Position : SV_Position;
};

void vert_main()
{
    v_Normal = mul(float4(Vertex_Normal, 1.0f), _14_Model).xyz;
    v_Normal = mul(Vertex_Normal, float3x3(_14_Model[0].xyz, _14_Model[1].xyz, _14_Model[2].xyz));
    v_Position = mul(float4(Vertex_Position, 1.0f), _14_Model).xyz;
    v_Uv = Vertex_Uv;
    gl_Position = mul(float4(v_Position, 1.0f), _67_ViewProj);
}

SPIRV_Cross_Output main(SPIRV_Cross_Input stage_input)
{
    Vertex_Normal = stage_input.Vertex_Normal;
    Vertex_Position = stage_input.Vertex_Position;
    Vertex_Uv = stage_input.Vertex_Uv;
    vert_main();
    SPIRV_Cross_Output stage_output;
    stage_output.gl_Position = gl_Position;
    stage_output.v_Normal = v_Normal;
    stage_output.v_Position = v_Position;
    stage_output.v_Uv = v_Uv;
    return stage_output;
}

forward.frag(HLSL):

struct Light
{
    row_major float4x4 proj;
    float4 pos;
    float4 color;
};

cbuffer StandardMaterial_albedo : register(b0)
{
    float4 _12_Albedo : packoffset(c0);
};

cbuffer Camera : register(b0)
{
    row_major float4x4 _32_ViewProj : packoffset(c0);
};

cbuffer Lights : register(b0)
{
    uint4 _40_NumLights : packoffset(c0);
    Light _40_SceneLights[10] : packoffset(c1);
};


static float4 o_Target;
static float3 v_Position;
static float3 v_Normal;
static float2 v_Uv;

struct SPIRV_Cross_Input
{
    float3 v_Position : TEXCOORD0;
    float3 v_Normal : TEXCOORD1;
    float2 v_Uv : TEXCOORD2;
};

struct SPIRV_Cross_Output
{
    float4 o_Target : SV_Target0;
};

void frag_main()
{
    float4 output_color = _12_Albedo;
    o_Target = output_color;
}

SPIRV_Cross_Output main(SPIRV_Cross_Input stage_input)
{
    v_Position = stage_input.v_Position;
    v_Normal = stage_input.v_Normal;
    v_Uv = stage_input.v_Uv;
    frag_main();
    SPIRV_Cross_Output stage_output;
    stage_output.o_Target = o_Target;
    return stage_output;
}

[kvark]

What's the repro case here, exactly?

[cart]

I am unable to repro the exact results above. Instead, i see a blank grey screen (our clear color) when I use DX12.

wgpu_trace:
wgpu_trace.zip

(when it should be a cube, a sphere, and a plane)

[cart]

Actually this is the more relevant wgpu trace. the last one i sent doesn't include the "sphere" primitive, which is currently there in the master branch:

wgpu_trace.zip

This is using the cart-tmp-wgpu crate.

[cart]

(im happy to take a new trace using 0.6.0 when that drops)

[kvark]

@cart could you upload the code of wgpu somewhere that you are using? Or maybe it's a revision of our code?

[kvark]

Nvm, I was able to find the revision corresponding to your code, and reproduce the problem.
Really enjoy working with wgpu tracing infrastructure :)
The issue is now fixed in gfx-backend-dx12-0.5.10

[cart]

it seems very fancy. thanks for looking in to this!

[zicklag]

Really enjoy working with wgpu tracing infrastructure :)

@kvark I don't know how you've got that setup, but are the tools ( crates, etc. ) you used for the generic enough that we could create the same thing for Bevy ( or other applications for that matter )? Is it GPU specific or just using something like the tracing crate or something?

[kvark]

You can read more at https://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-api-tracing.html
There is no need for any tools per se, just serde and a few calls here and there to serialize the incoming work. wgpu uses RON as a format.
The traces are not GPU specific, and that's the best part about them (unlike, say RenderDoc captures).

Are you thinking about tracing bevy at a higher level?

[zicklag]

You can read more at https://kvark.github.io/wgpu/debug/test/ron/2020/07/18/wgpu-api-tracing.html

Awesome.

Are you thinking about tracing bevy at a higher level?

Yeah, it just seemed so useful here already I was wondering if it could be useful for Bevy to help reproduce bugs or something. Not sure if it makes sense or not yet, but figured it was worth thinking about.

[Moxinilian]

Has this been tested with newer versions of wgpu now that it is fixed upstream?