Examples continue to run long after exit on Mac

[swiftcoder]

The triangle example hangs for a long time (10-20 seconds) after one presses the close button on Mac (Mojave developer beta 7, using MoltenVK via vulkansdk-macos-1.1.82.1).

The Teapot example exposes something much more interesting - it isn't hanging per se, because the teapot continues to animate after the close event is processed. If you add a println! as the very last statement in main, you can see that the program exits the main loop entirely, but continues to render and animate for 10 seconds or so.

I'm not entirely sure where to start debugging this. It seems as thought the program is only actually displaying 1 frame each time it should display 2, and after the program ends it proceeds to play back all the missing frames that have been queued up. I can't really tell if that's a Vulkano issue, a MoltenVK issue, or an issue in the sample code?

[swiftcoder]

As an additional data point, the same samples run fine on Windows/NVidia (as expected), which tends to point to a MoltenVK-specific issue, or some sort difference in the way MoltenVK handles frame submit.

[swiftcoder]

The workaround is fine, albeit likely negatively impacting performance, but are we sure this is a MoltenVK bug, and not an issue between Vulkano and varying interpretations of the spec?

https://github.com/KhronosGroup/MoltenVK/issues/146 does look very similar to this.

[rukai]

Yeah, someone needs to either:

• Create a c++ repro of the frames stacking up.
• Or find a bug in vulkano causing frames stacking up.

[Keshi]

I'm encountering a similar problem.. exiting from triangle simply causes it to hang forever without closing the window. I'm not sure if it is the same problem, but it seems to be waiting on a fence?

__psynch_cvwait 0x00007fff744d47de _pthread_cond_wait 0x00007fff7458e593 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) 0x00007fff71a6dbda MVKSemaphoreImpl::wait(unsigned long long, bool) 0x000000010aa50fab mvkWaitForFences(unsigned int, VkFence_T* const*, unsigned int, unsigned long long) 0x000000010aa52535 vk_sys::DevicePointers::WaitForFences::h7d322add3c6fead8 lib.rs:2699 _$LT$vulkano..sync..fence..Fence$LT$D$GT$$GT$::wait::h350985ab537a39e9 fence.rs:169 _$LT$vulkano..sync..future..fence_signal..FenceSignalFuture$LT$F$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::he6685a66dd3b6a1b fence_signal.rs:437 core::ptr::drop_in_place::h4beede58f3032683 0x0000000109d6af85 core::ptr::drop_in_place::h3a781f07896bb430 0x0000000109d6a5b7 triangle::main::hde1c3b6b40d1ae79 triangle.rs:450 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hfc2dfc814f5233ba 0x0000000109d3f9a2 std::panicking::try::do_call::ha38138adc359e978 0x0000000109ec6d98 std::panicking::try::do_call::ha38138adc359e978 0x0000000109ec6d8c __rust_maybe_catch_panic 0x0000000109ed307f std::rt::lang_start_internal::hb574fbed1955c3b8 0x0000000109ebf99d std::rt::lang_start_internal::hb574fbed1955c3b8 0x0000000109ebf96a std::rt::lang_start_internal::hb574fbed1955c3b8 0x0000000109ebf96a std::rt::lang_start::h83fec2f34e76bd75 0x0000000109d3f982 main 0x0000000109c69eb2 start 0x00007fff74397ed9

[Rua]

Is this still an issue?