part01-resizing panics on resize under Linux+Vulkan

[icefoxen]

Pretty much what it says, I run part01-resizing with a Vulkan backend, and on resize I get the following:

thread 'main' panicked at 'Present failed: ()', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:809
  10: part01_resizing::main
             at src/bin/part01-resizing.rs:313
  11: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  12: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  13: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  14: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  15: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  16: main
  17: __libc_start_main
  18: _start

This line appears to be swapchain.present(&mut queue_group.queues[0], frame_index, &[]).expect("Present failed");. Haven't fiddled around with it further yet.

[mistodon]

I'll try to dust off my linux laptop in a bit and repro this. Thanks for reporting it!

[icefoxen]

Oh, for reference: This is on Debian Buster, using an NVidia GTX 660 graphics card with the proprietary drivers.

[human9]

I can reproduce this, and also fix it by recreating the swapchain when .acquire_image(FrameSync::Semaphore(&frame_semaphore)) returns an error, as in the gfx-rs quad example.

[human9]

Actually I think initially I found a different problem, I was using an intel gpu for the first commit, I then tested on an nvidia gpu using proprietary drivers and found that the panic that occurs at swapchain.present(...)
The gfx quad example recreates the swapchain in both cases which seems to fix it so I'm guessing that's the best solution

[mistodon]

It sounds like a reasonable solution yep - I'm having some trouble setting up a vulkan environment for testing, but your changes look correct. Thanks for the help :)

[icefoxen]

Ah, looks like the latest commit (474e6dc) DOES resize properly on Linux using Intel drivers now! I'll try to remember to test on my NVidia machine when I get back to it.

[mistodon]

Cool, let me know if it's all fine and I'll close this :)

[riverreal]

@mistodon
Tested on nvidia GTX 880M
The swapchain recreation indeed fixed the crash on linux using vulkan backend