Try
vkQueuePresentKHR is slow
Time for vkQueuePresentKHR in my laptop is sometimes 20-50 ms. After reboot it back to normal: 0-2 ms - so can be issue with my machine.
Anyway presentation engine should be reviewed.
-
Samsung present thread practice: https://www.khronos.org/assets/uploads/developers/library/2019-vulkanised/02_Live%20Long%20And%20Optimise-May19.pdf
-
vkAcquireFullScreenExclusiveModeEXT worth to be implemented for windows
Hi,
Not sure if I have done this the correct way, but I activated the line
Log::i("vkQueuePresentKHR = ",Application::tickCount()-t);
In vulkanapi.cpp and I can see that normaly the tick difference is 0, sometimes 1. After ~5min of gameplay with the log messages active I was able to observe 3 spikes where the value was above 10 and above 20. But I think this is expected if new textures are loaded?
I have a few ideas what could cause something like this.
- Did you check that your CPU and GPU temperature was in a normal temperature range? Most systems will reduce clock speed if certain temperature thresholds are reached.
- If you are running windows it could be a problem if energy saving is active (if it is set to "balanced" for example), as far as I know this can have a big impact on clock speed of the CPU which could cause a delay in code execution.
Currently I am running the game on my PC, tomorrow I will try to compile the project on my 9 year old cheap laptop, maybe I can see the problem there :)
Hi, @Eulenmensch93 !
But I think this is expected if new textures are loaded?
No, that not suppose to be the case - vkQueuePresentKHR doesn't do any 'real' work, it only pushes a command into a command queue.
I haven't to to measure temperature and such, because 20-50ms are way to large numbers for one api-function.
All I have so far is a Samsung presentation in topic: they say, that vkQueuePresentKHR calls into 'queueBuffer'(part of android gralloc, I think) and spends time there on some-sort of synchronization. May be Windows do something similar.