vulkano-rs
Waiting on `SwapchainAcquireFuture` without dropping it
- Version of vulkano: 0.13
- OS: Ubuntu 18.04
- GPU (the selected PhysicalDevice): Intel(R) HD Graphics 530 (Skylake GT2)
I'm developing an application where latency is more important than anything else. I want to block the CPU waiting for the GPU in several places. Unfortunately, I can't seem to wait for a SwapchainAcquireFuture on the CPU side. I can drop it, but that means I loose access to it. From the code of drop() it looks like one could easily expose a wait() method for that future.
I tried two things: acquire_future.then_signal_fence_and_flush()?.wait()? but that leads to:
thread '<unnamed>' panicked at 'assertion failed: future.queue().is_some()', /home/lukas/.cargo/registry/src/github.com-1ecc6299db9ec823/vulkano-0.13.0/src/sync/future/fence_signal.rs:38:5
And since the SwapchainAcquireFuture already has an internal fence, it seems wasteful to add another one.
And as I said, I also tried dropping the future, assuming that afterwards acquisition is finished. Since the future is dropped and I don't have access to it anymore, instead of acquire_future.then_execute(...) I use my_cb.execute(). But this way I get:
access to a resource has been denied (AccessError { error: SwapchainImageAcquireOnly, command_name: "vkCmdBeginRenderPass", command_param: "attachment 0", command_offset: 1 })
So I'm not really reporting an issue but rather a feature request. But it also might be that I misunderstand something fundamentally, so just let me know if that's the case :P
Why would you actually want to wait on the acquisition of a swapchain image and not the presentation? I recommend having a look at the different swapchain presentation modes vulkan offers, then deciding which one fits your purpose most and then waiting on the presentation future instead of the acquire future:
https://vulkan-tutorial.com/Drawing_a_triangle/Presentation/Swap_chain#page_Presentation-mode https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html#VkPresentModeKHR
Well... it probably boils down to "bad Intel drivers". Here a bit longer explanation, with the key points in bold:
For the past few weeks I tried to build a low-input-lag frontend for a gameboy emulator. The actual "rendering" is as easy as it can get: it just draws a quad on the screen showing one texture that was previously created by the emulator. So that part is very fast, even on old hardware. The important part is to keep the lag down. On my Intel GPU, I get roughly 2 or 3 frames of input lag when using "fifo" present mode. This also happens when I explicitly block until the presentation future is fulfilled. I'm pretty sure by now that my driver is just doing strange stuff and ignores certain "block now" requests. With OpenGL I had the same problem: glFinish and fences did nothing after buffer swap.
(Also compare this issue, which seems highly related.) Using "mailbox" or "immediate" fixes the issue of input lag, but they are not always available and lead to stuttering.
Anyway, due to these problems, I want to have some timing on the CPU side. For example, it would be nice to know when exactly vblank would happen and how long emulation and rendering take. With that, one can defer the emulation and "rendering" step as much as possible such that they happen as close to the vblank as possible. To get these timings and estimations, it would be useful to be able to time every step Vulkan does. Basically turning it into a almost synchronize API. I am aware that this is a very special case and syncing GPU and CPU is something one usually wants to avoid in 99% of Vulkan applications.
I'm just saying: it would be nice to explicitly wait for all futures in the vulkano library, without dropping them. The functionality is already there, just not exposed.
I would say it's perfectly fine what you want to do but I'm not sure whether it solves your problem. However, I'm not the maintainer, so I guess you have to implement it yourself and open a PR.
Anyhow, acquire_future.then_signal_fence_and_flush()?.wait()? should actually never panic so I would consider this a bug.