too long waiting for fence

user_11929476 0
Viewed 66

I am using Vulkan with C# and Silk.net. And can't understand why it takes so long to complete even small command queues. Please, look at this CPU timeline:

enter image description here

As you can see, there are too long waitings, while GPU work times are small:

enter image description here

I understand that it is not efficient to wait for fences. But here is something strange, I think. When it was OpenGL, it was possible to synchronize CPU and GPU after every draw. Even with different shaders, textures, and much of work. So, it must be possible without such waiting.

Is it some bug or normal behaviour for Vulkan?

vulkan c#
1 Answers

Vulkan does not specify behavior in terms of timing. So this is neither a "bug" nor "normal". Performance questions of this sort are not a matter of the API definition. They are a matter of reasonable expectation out of a system.

The delay times you are talking about appear to be on the order of tenths of a millisecond. That is not entirely unreasonable as far as overhead is concerned for waiting on an unsignaled fence. It is not reasonable to expect the CPU thread to be woken up instantly upon the completion of the GPU operation being waited on.

Waiting on an unsignaled fence is only something that should happen if the CPU starts outrunning the GPU. You should only check a fence from a previous frame, and only if you need to use some memory resources or swapchain images used by that frame. And if it is still unsignaled, go do whatever CPU work you can that doesn't require using those resources. Only when you are out of other work to do should you actually wait on the fence with a non-zero time.

user_7340690
Related