You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Greetings, I have a question regarding one of the tutorials.
I'd have used disqus but the registration doesn't work for me so this is my only remaining option, sorry.
In your tutorial you have a createVertexBuffer function which creates a staging buffer, maps, writes and unmaps it then copies it to the final gpu memory buffer:
The copy uses endSingleTimeCommands which itself uses an vkQueueWaitIdle to ait on the graphics queue.
I have an OpenGL application that uploads small buffers to the gpu per frame. It is using merely glMapBuffer/glUnmapBuffer with unsynchronized access at a point where it knows the buffer is not used by the gpu.
Now when I port this to Vulkan I have a measurable wait time at this vkQueueWaitIdle. In a high load test where 500 frames are allowed, the OpenGL app produces almost 500 while the Vulkan version produces 300. Cause seems to be a delay in the Linux poll() function caused by the above mentioned vkQueueWaitIdle which can be up to 10 ms which is just too much (X64 Ubuntu, Nvidia driver).
My question is if a separate command buffer and vkQueueWaitIdle is really necessary if I know the buffer is not in use at the moment. Can't I just drop all command in the same command buffer the drawcall that uses this VBO goes to?
Regards
The text was updated successfully, but these errors were encountered:
Desperado17
changed the title
Question regarding
Question regarding buffer upload synchronization
Aug 12, 2022
Greetings, I have a question regarding one of the tutorials.
I'd have used disqus but the registration doesn't work for me so this is my only remaining option, sorry.
In your tutorial you have a createVertexBuffer function which creates a staging buffer, maps, writes and unmaps it then copies it to the final gpu memory buffer:
VulkanTutorial/code/30_multisampling.cpp
Line 1176 in 1256617
The copy uses endSingleTimeCommands which itself uses an vkQueueWaitIdle to ait on the graphics queue.
I have an OpenGL application that uploads small buffers to the gpu per frame. It is using merely glMapBuffer/glUnmapBuffer with unsynchronized access at a point where it knows the buffer is not used by the gpu.
Now when I port this to Vulkan I have a measurable wait time at this vkQueueWaitIdle. In a high load test where 500 frames are allowed, the OpenGL app produces almost 500 while the Vulkan version produces 300. Cause seems to be a delay in the Linux poll() function caused by the above mentioned vkQueueWaitIdle which can be up to 10 ms which is just too much (X64 Ubuntu, Nvidia driver).
My question is if a separate command buffer and vkQueueWaitIdle is really necessary if I know the buffer is not in use at the moment. Can't I just drop all command in the same command buffer the drawcall that uses this VBO goes to?
Regards
The text was updated successfully, but these errors were encountered: