diff options
| author | Damien Leone <dleone@nvidia.com> | 2017-04-14 16:10:14 -0700 |
|---|---|---|
| committer | Tony-LunarG <tony@lunarg.com> | 2017-05-02 08:56:10 -0600 |
| commit | c336d8220000c1b97a7a23c93396cf00d9f0383c (patch) | |
| tree | bcd2f341eac5b5255aa1031c37bf6b1cd7103383 /layers/unique_objects.cpp | |
| parent | 97301d61a9155173eaa1016bed1245dfad0f2037 (diff) | |
| download | usermoji-c336d8220000c1b97a7a23c93396cf00d9f0383c.tar.xz | |
cube: Throttle rendering rather than presentation
It is currently impossible to reliably throttle presentation per the
Vulkan spec.
The previous code was relying on fences returned by
vkAcquireNextImageKHR() to throttle. The only information this fence
holds is whether it is possible to render to that image since the *last
time* it was presented, which could have happened several frames ago.
Instead, we can throttle the rendering by passing a fence to
vkQueueSubmit().
The previous code (only the cube.c version) was using a fence there to
synchronize a vkMapMemory() in demo_update_data_buffer(), which doesn't
seem necessary.
Before this commit, we were effectively throttling to the number of
frames in the swapchain rather than on FRAME_LAG.
In the FIFO present mode, this could schedule too much work in the
presentation channel (since we have to account for VBLANK events)
and thus causing undesired side effects, such as stutters when trying
to move the cube window on a desktop, which is I assume why the
throttle code was added in the first place.
Diffstat (limited to 'layers/unique_objects.cpp')
0 files changed, 0 insertions, 0 deletions
