gfx-rs/wgpu

Regression: Multiple command buffers / render passes seems to break surface.get_current_texture()

ggadwa opened this issue · 2 comments

Description
Going from 0.19.4 to 0.20.0 makes my game always return timeout when getting the output surface.

Repro steps
Just for ease in my code, there are multiple command buffer creation, render pass, then queue submits. This is all on a single thread. In 0.19.4, this worked, but if I do anything more than a single command buffer, this:

surface.get_current_texture()

returns a timeout.

Not a recreation example but just how my normal rendering goes (this happens maybe 5-10 times every frame, and is different every time but the normal command/render pass/queue stuff), this is just a simple example.

       // set the matrix
        let buf: [[f32; 4]; 4] = view.ortho_matrix.into();
        view.queue.write_buffer(&self.uniform_buffer_ortho_matrix, 0, bytemuck::cast_slice(&buf));

        let mut encoder = view.device.create_command_encoder(
            &wgpu::CommandEncoderDescriptor {
                label: None,
            }
        );
        
        { // to drop render pass
            let mut render_pass = 
                encoder.begin_render_pass(&wgpu::RenderPassDescriptor {
                    label: None,
                    color_attachments: &[Some(wgpu::RenderPassColorAttachment {
                        view: &view.color_texture_view,
                        resolve_target: None,
                        ops: wgpu::Operations {
                            load: wgpu::LoadOp::Load,
                            store: wgpu::StoreOp::Store,
                        },
                    })],
                    depth_stencil_attachment: None,
                    occlusion_query_set: None,
                    timestamp_writes: None
                });

            render_pass.set_pipeline(&self.pipeline);
            render_pass.set_bind_group(0, &self.bind_group_ortho_matrix, &[]);
            render_pass.set_vertex_buffer(0, self.vertex_buffer.slice(..));
            render_pass.draw(0..6, 0..1);
        }

        view.queue.submit(iter::once(encoder.finish()));

This worked fine in 0.19.4, in 0.20.0 it throws the timeout (always, not just a first frame or every once in a while). If I need to rework all my code I can but this seems like a regression.

So, specifically, if I do an encoder/render pass/draw something/queue submit more than once in a frame in the same thread it breaks current surface. If I do it JUST ONCE, it works fine.

Expected vs observed behavior
Seems to be a regression; to have it work like it did in 0.19.4.

Extra materials
n/a

Platform
Windows 10, AMD card, game also runs on Mac but haven't tested it there yet.

Note: I saw a couple deadlock issues appeared as I typed in this one -- possibly related.

Closing as duplicate of #5693.