Wgpu: flickering when pipeline reused

[m4b]

I don't have an immediate repro (and I can't seem to repro in a straightforward manner on cube example) but I have a function like this:

    pub fn draw(&self, bind_group: &wgpu::BindGroup, rpass: &mut wgpu::RenderPass) {
        rpass.set_pipeline(&self.pipeline);
        rpass.set_bind_group(0, bind_group, &[]);
        rpass.set_vertex_buffers(&[(&self.buf, 0)]);
        rpass.draw(0..(self.buf.len()) as u32, 0..1);

        if self.strips_buf.len() != 0 {
            // this is required because of a bug in wgpu which causes flickering unless we reset teh pipeline and bind group
            rpass.set_pipeline(&self.pipeline); // <------ must re-set this otherwise flickers
            rpass.set_bind_group(0, bind_group, &[]);
            rpass.set_vertex_buffers(&[(&self.strips_buf, 0)]);
            rpass.draw(0..(self.strips_buf.len()) as u32, 0..1);
        }
    }

E.g., I have to re-set_pipeline (but not the bind group), for the same pipeline (and bindgroup), otherwise i see flickering on the resultant triangle from the vertices in self.strips_buf.

I don't immediately know why this would happen, and I use the above workaround, but @kvark suggested I should file anyway so it's here and that it's probably a bug in wgpu.

I don't have any validation errors, etc., this is on vulkan backend, archlinux os, intel integrated gpu.

[kvark]

Are you seeing validation errors in general on this setup? Would you see them if something was clearly incorrect?

[m4b]

Yes I always see validation errors if something is wrong, eg wrong flags, etc. only time I haven’t is previous issue where I passed too many elements to a draw call, but that is now fixed in master.

There have been times where I think a shader was writing/reading to points in a buffer, and I did not receive any crashes or warnings (on both metal and vulkan backends) but I don’t know if validation errors can catch that gpu side issue ?

[kvark]

Our validation is still WIP, so it can easily miss some cases, especially if they are related to shader reflection/sanitation (which we haven't gotten hooked up yet).

[m4b]

Ok I’ll double check but I don’t think I’m reading or writing any invalid memory anymore, and as far as I can see there aren’t any major issues remaining.

[aloucks]

Do you have other pipelines or bind groups? Could this be a case of the bind group being "disturbed" by another bind?

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#descriptorsets-compatibility

When binding a descriptor set (see Descriptor Set Binding) to set number N, if the previously bound descriptor sets for sets zero through N-1 were all bound using compatible pipeline layouts, then performing this binding does not disturb any of the lower numbered sets. If, additionally, the previous bound descriptor set for set N was bound using a pipeline layout compatible for set N, then the bindings in sets numbered greater than N are also not disturbed.

[m4b]

Hmm yes I have other pipelines and bind groups. But I think the cube demo does too ? If not would be interesting to see if having multiple pipelines and bind groups and the reusing one could cause this issue

[aloucks]

The bindings are only disturbed if the pipelines are considered incompatible.

[m4b]

Yea I was rereading that. But in my example above why would that cause flickering? I rebind the exact same pipeline just to avoid flickering when I change the bound vertex buffer, which also has the same layout as the previous vertex buffer.

[dragly]

This is definitely related to https://github.com/gfx-rs/wgpu-rs/issues/49

@m4b I tried your workaround of re-setting the pipeline before the second draw call and that stops the flickering.

In my modified cube example (https://github.com/dragly/wgpu-rs/commit/cc36db229b416390892457c0bd0d3bb430dbec2a), the following conditions need to be met to reproduce flickering:

• There must be both a compute pass and a render pass. The compute pass can be no-op.
• The first draw call must have some load. In my case, drawing 32x32x32 instances does the trick.
• The pipeline needs to be reused (as is pointed out in this issue already).

Let me know if there is anything I can do to help debug this issue.

[m4b]

Awesome thanks for checking ! Great detail too, thanks!

[dragly]

As mentioned in https://github.com/gfx-rs/wgpu-rs/issues/49, I filed a bug report to Mesa and it was immediately reported as a duplicate of a similar issue in vkQuake. Seems like this could be a graphics driver bug.

[dragly]

@m4b a patch that solved the issue for me was just posted here, in case you want to try it out and see if it also fixes your issue: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1526

[kvark]

I wonder if this is related to the problems #319 is fixing. I know that Mesa patch saves the day, but re-setting the pipeline could also make an effect on our binding code.

[dragly]

Rebased on top of the latest version of wgpu-rs and the problem persists. Seems like the Mesa patch is still necessary.