wgpu: vulkan validation error: VUID-vkDestroyFramebuffer-framebuffer-00892

Occasionally (every few hundred frames on average) I get VUID-vkDestroyFramebuffer-framebuffer-00892 validation errors. The timing seems irregular, so I guess something is racing under the hood.

My render loop is quite straighforward (removed error handling):

let frame = swap_chain.lock().await.get_next_frame().unwrap()
...
let mut encoder =  device.create_command_encoder(&wgpu::CommandEncoderDescriptor { label: None });
...
let mut rpass = geometry_pass.begin(&mut encoder, &frame.output.view);
...
let mut rpass = lighting_pass.begin(&mut encoder, &frame.output.view);
...
queue.submit(Some(encoder.finish()));

I played around a little and adding:

std::thread::sleep(std::time::Duration::from_millis(10));
drop(frame);

at the end prevents the validation errors.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 21 (13 by maintainers)

Commits related to this issue

[rs] Merge #785 785: Update to latest web-sys bindings r=kvark a=grovesNL We can wait for https://github.com/rustwasm/wasm-bindgen/pull/2482 first Co-authored-by: Joshua Groves <josh@joshgroves.com... — committed to kvark/wgpu by bors[bot] 3 years ago

Most upvoted comments

I’m running into this validation error as well. I see the validation error go away after applying one of the following changes:

Simplify the scene (by rendering fewer instances, or a mesh with fewer vertices).
Add a sleep after queue.submit as mentioned in https://github.com/gfx-rs/wgpu/issues/785#issue-655407567 (10ms was too short for me, 30ms worked though). EDIT: Adding the sleep before queue.submit also works for me. The location of the sleep doesn’t seem to matter too much. Also it might be relevant that device.poll takes about 30ms for me as well, or maybe that’s just a coincidence.
Call device.poll(wgpu::Maintain::Wait) before queue.submit.

I also tried calling device.poll after queue.submit, which did get rid of the validation error mentioned in this issue, but triggered a different one instead: UNASSIGNED-CoreValidation-DrawState-QueueForwardProgress. The result was the same when calling device.poll in a loop in a separate thread. I could make a separate issue for that?

benfrankel on Aug 3, 2020

All you need to finish it is to edit the file by appending “]” to it.

Ah thanks, now it works. I’ve tried with a few traces now and I don’t get the validation error when playing the trace, even though I get multiple on the original run…

I’ve been playing around a little more and noticed that I get very noticeable stalls (~1s) right before the validation error prints. introducing a sleep before acquiring a new frame gets rid of the validation error as well as the stalls.

I wonder if this is just gfx-rs/gfx#3184

I hadn’t seen that. Seems likely. There aren’t really any examples that are heavy enough to get frames in flight for long. I’ll see if I can patch one to reproduce this issue.

FlorianUekermann on Aug 2, 2020

I attached the vulkaninfo output and the trace with current master (had to compress it twice, because github doesn’t like .xz and just using zip makes it 20x larger).

lspci says: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] (rev c5) trace.zip vulkaninfo.txt

FlorianUekermann on Jul 13, 2020