Wgpu 0.8 flickering during render

[sotrh]

When I open my model loading tutorial, I notice a lot of flickering in my scene. The angle I view the scene seems to effect the flickering. Whole triangles are flickering.

https://youtu.be/pSXPMDl1J4o

I was guessing it might be something to do with my depth buffer, but I disabled the depth pass and the flickering persisted. I've linked the trace and code below.

flickering_trace.zip
https://github.com/sotrh/learn-wgpu/tree/0.8/code/beginner/tutorial9-models

I've tried running my code with RenderDoc, but for whatever reason RenderDoc isn't giving me the option to record a frame so I can't see any of the api calls.

Let me know if I can provide anymore information.

[kvark]

Interesting issue... I reproduced on NVidia/Linux/Vulkan and played with this code. What's your platform?
I had no luck reducing the bug yet, and RenderDoc has issues on this machine, so I wasn't able to capture anything. So far it looks like the vertex transformation (or the primitive assembly) fails in some what, but it's hard to tell how exactly. This is unlikely anything wgpu is doing wrong, looks more like a driver bug to me.

[JeroenCops]

I have encountered the same issue. I produced it on NVidia/Windows/Vulkan and when switching to DirectX 12 the problem went away.

[qthree]

Probably related #1316

[kvark]

Interesting. @sotrh could you try enabling "cross" feature and seeing if it makes anything different?

[sotrh]

Yep that fixed it. I guess the output from shaderc works a little better with Spirv Cross enabled then? I'm going to check to see if it fixes my other issue #1359

[kvark]

When enabling "cross", the output of shaderc is passed directly into the driver. Otherwise, it gets parsed by Naga, and then we produce an entirely new SPIRV based on it. Something about this SPIRV is confusing the drivers.

…

On May 2, 2021, at 12:33, sotrh ***@***.***> wrote:  Yep that fixed it. I guess the output from shaderc works a little better with Spirv Cross enabled then? I'm going to check to see if it fixes my other issue #1359 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[kvark]

Please try writing shaders in WGSL and see if the issue persists

…

On May 2, 2021, at 12:52, Dzmitry ***@***.***> wrote:  When enabling "cross", the output of shaderc is passed directly into the driver. Otherwise, it gets parsed by Naga, and then we produce an entirely new SPIRV based on it. Something about this SPIRV is confusing the drivers. >> On May 2, 2021, at 12:33, sotrh ***@***.***> wrote: >> >  > Yep that fixed it. I guess the output from shaderc works a little better with Spirv Cross enabled then? I'm going to check to see if it fixes my other issue #1359 > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.

[sotrh]

Should I disable spirv cross as well as rewrite in wgsl?

[kvark]

If you run on Vulkan, and the shader is WGSL, then the "cross" feature doesn't do anything.

…

On May 2, 2021, at 13:03, sotrh ***@***.***> wrote:  Should I disable spirv cross as well as rewrite in wgsl? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[sotrh]

The wgsl code has no flickering. It does have some validation errors though.

// Vertex shader

[[block]]
struct Uniforms {
    view_proj: mat4x4<f32>;
};
[[group(1), binding(0)]]
var<uniform> uniforms: Uniforms;

struct VertexInput {
    [[location(0)]] position: vec3<f32>;
    [[location(1)]] tex_coords: vec2<f32>;
};
struct InstanceInput {
    [[location(5)]] model_matrix_0: vec4<f32>;
    [[location(6)]] model_matrix_1: vec4<f32>;
    [[location(7)]] model_matrix_2: vec4<f32>;
    [[location(8)]] model_matrix_3: vec4<f32>;
};

struct VertexOutput {
    [[builtin(position)]] clip_position: vec4<f32>;
    [[location(0)]] tex_coords: vec2<f32>;
};

[[stage(vertex)]]
fn main(
    model: VertexInput,
    instance: InstanceInput,
) -> VertexOutput {
    let model_matrix = mat4x4<f32>(
        instance.model_matrix_0,
        instance.model_matrix_1,
        instance.model_matrix_2,
        instance.model_matrix_3,
    );
    var out: VertexOutput;
    out.tex_coords = model.tex_coords;
    out.clip_position = uniforms.view_proj * model_matrix * vec4<f32>(model.position, 1.0);
    return out;
}

// Fragment shader

[[group(0), binding(0)]]
var t_diffuse: texture_2d<f32>;
[[group(0), binding(1)]]
var s_diffuse: sampler;

[[stage(fragment)]]
fn main(in: VertexOutput) -> [[location(0)]] vec4<f32> {
    return textureSample(t_diffuse, s_diffuse, in.tex_coords);
}

[2021-05-02T17:40:30Z ERROR gfx_backend_vulkan] 
    VALIDATION [UNASSIGNED-CoreValidation-Shader-InconsistentSpirv (0x6bbb14)] : Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0x55f74a6fa508, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: Capability Kernel is not allowed by Vulkan 1.2 specification (or requires extension)
      OpCapability Kernel
    
    object info: (type: DEVICE, hndl: 0x55f74a6fa508)
    
[2021-05-02T17:40:30Z ERROR gfx_backend_vulkan] 
    VALIDATION [UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled (0x8c548bfd)] : Validation Error: [ UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled ] Object 0: handle = 0x55f74a6fa508, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x8c548bfd | Shader requires VkPhysicalDeviceFeatures::shaderStorageImageMultisample but is not enabled on the device
    object info: (type: DEVICE, hndl: 0x55f74a6fa508)
    
[2021-05-02T17:40:30Z ERROR gfx_backend_vulkan] 
    VALIDATION [UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled (0x8c548bfd)] : Validation Error: [ UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled ] Object 0: handle = 0x55f74a6fa508, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x8c548bfd | Shader requires VkPhysicalDeviceFeatures::shaderStorageImageMultisample but is not enabled on the device
    object info: (type: DEVICE, hndl: 0x55f74a6fa508)

[kvark]

Looked at this tonight and found the reason - gfx-rs/naga#820

Also filed gfx-rs/naga#819 separately for the Kernel related validation error.

[kvark]

Fix is coming, hold tight!

[yanchith]

I am guessing the fix for this didn't make it in 0.8.1?

I can still reproduce on win32-vulkan-nvidia (all others I have access to work correctly, including win32-vulkan-intel). Can provide traces and videos, and help verify the fix also.

[kvark]

It's not a part of a Naga release yet, we'll back-port the change now.

[kvark]

Naga-0.4.1 is up.