aboutsummaryrefslogtreecommitdiff
path: root/layers/unique_objects.cpp
diff options
context:
space:
mode:
authorDamien Leone <dleone@nvidia.com>2017-04-14 16:10:14 -0700
committerTony-LunarG <tony@lunarg.com>2017-05-02 08:56:10 -0600
commitc336d8220000c1b97a7a23c93396cf00d9f0383c (patch)
treebcd2f341eac5b5255aa1031c37bf6b1cd7103383 /layers/unique_objects.cpp
parent97301d61a9155173eaa1016bed1245dfad0f2037 (diff)
downloadusermoji-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