KhronosGroup / KhronosGroup/Vulkan-Samples

Rework synchronization in port of my framework

Open
#1,380 0 comments 0 reactions 1 assignee Claimed by @SaschaWillems View on GitHub
framework
Dominant language
C++
Stars
5.4k
Forks
835
Avg merge
2h 16m
Merged PRs (30d)
1

Description

Back when I started doing Vulkan samples, I did use vkQueueWaitIdle to "sync" frame presentation. That made it easier to write samples, but kills any chance of CPU/GPU parallelism like frames-in-flight. This makes all samples based on the port of my framework sub-optimal from Vulkan's Point-of-View:

```cpp
void ApiVulkanSample::submit_frame()
{
if (get_render_context().has_swapchain())
{
...
}

// DO NOT USE
// vkDeviceWaitIdle and vkQueueWaitIdle are extremely expensive functions, and are used here purely for demonstrating the vulkan API
// without having to concern ourselves with proper syncronization. These functions should NEVER be used inside the render loop like this (every frame).
VK_CHECK(get_device().get_queue_by_present(0).wait_idle());
}
```

Removing this will require duplicating resources shared by CPU and GPU (e.g. uniform buffers) in all samples and redoing the semaphore/fence setup.

That's something I'm currently fixing in my own samples [link](https://github.com/SaschaWillems/Vulkan/pull/1224), and after that I'd be willing to also do that for the Khronos samples.

Will probably be a larger effort (at least weeks, more prob. months) but in the end it'll be worth it to show how to properly use Vulkan.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.