Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Vulkan resource ownership transfer vs VK_SHARING_MODE_CONCURRENT & different queue families performance

I have a compute shader which produces vertex buffer and draw indirect structure that are then used to draw some geometry.

Compute shader is invoked not every frame, but once per 5-10 frames. In fact, I have my vertex and draw indirect buffers duplicated, so while I am rendering geometry using VB1 and DI1, compute shader is able to write to VB2 and DI2 and then swap them, so compute and drawing invocations may be independent. I also have 2 queue families: do-everything and compute-only.

So, I can think of 3 ways to do this:

  1. Use only one do-everything queue with VK_SHARING_MODE_EXCLUSIVE buffers
  2. Use compute-only queue for compute shader and do-everything for drawing with VK_SHARING_MODE_EXCLUSIVE buffers and ownership transfer between queues
  3. Use compute-only queue for compute shader and do-everything for drawing with VK_SHARING_MODE_CONCURRENT buffers

I would like hearing your advices about what option to use and what are they pros/cons. I have some assumptions about it and want to know, am I right or not:

  1. I think that using separate family dedicated for compute operations may improve performance
  2. I think that ownership transfer is a heavy operation and it worth doing it only once (like when uploading resource to gpu memory), but not every 5-10 frames
  3. Therefore I think that 3rd option will be the best choice for me
like image 354
YaaZ Avatar asked Jul 02 '19 13:07

YaaZ


People also ask

What is swap chain in Vulkan?

Swap chain. Vulkan does not have the concept of a "default framebuffer", hence it requires an infrastructure that will own the buffers we will render to before we visualize them on the screen. This infrastructure is known as the swap chain and must be created explicitly in Vulkan.

Is there a problem with VK_present_mode_FIFO_KHR?

Ah, right, I see what you mean now. Yeah, the problem is that some drivers do report VK_PRESENT_MODE_FIFO_KHR as available, but they actually crash/behave weirdly if you choose to use it. That's why we still prefer immediate mode in that case. Ahhhh. Thanks!

Is image presentation part of Vulkan core?

Secondly, since image presentation is heavily tied into the window system and the surfaces associated with windows, it is not actually part of the Vulkan core. You have to enable the VK_KHR_swapchain device extension after querying for its support.

How does the vkphysicaldevice and vksurfacekhr support query work?

This function takes the specified VkPhysicalDevice and VkSurfaceKHR window surface into account when determining the supported capabilities. All of the support querying functions have these two as first parameters because they are the core components of the swap chain. The next step is about querying the supported surface formats.


1 Answers

Since the standard has this explicit warning:

VK_SHARING_MODE_CONCURRENT may result in lower performance access to the buffer or image than VK_SHARING_MODE_EXCLUSIVE.

I would say that you should pick exclusive mode unless and until your profiling data suggests there is a performance problem. After all, you said there is at least a 5:1 ratio between using the buffers and moving them across queues. So you access the buffers with greater frequency than the frequency with which you perform queue ownership operations.

like image 92
Nicol Bolas Avatar answered Oct 01 '22 14:10

Nicol Bolas