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
{{ message }}
This repository has been archived by the owner on Jul 29, 2021. It is now read-only.
According to Synchronization Examples and Google's samples it is possible the rendering queue does not support presentation; therefore a different queue must be used for presentation.
I don't know what GPUs out there require the code to handle this case, but it appears it must be dealt by the code. Maybe it's Optimus laptops, maybe it's Android devices that have a special queue for handling rotations.
The text was updated successfully, but these errors were encountered:
If I remember correctly, back when we added separate queue handling into the cube demo, I couldn't find a device that has a graphics queue that didn't support present and I had to force it down that path to test the new code. But that was years ago, so things might have changed.
It looks like, in general, the samples address some of the issues with separate graphics and present queues. QueueSubmit is called with info.graphics_queue and QueuePresent is called with info.present_queue. I do see that image ownership of the swapchain image is not transferred between queues - is that what is missing? Anything else?
They use an additional semaphore because when the queue is the same, present just waits for the graphics submission to end. However when two queues are used, they use another vkQueueSubmit (I don't see why they couldn't be merged into the same queue with a pipeline barrier, but Google's way is probably more flexible if we consider two queues an edge case) and the present must wait for the second vkQueueSubmit that handles the ownership change.
So there's two things: The samples need two variables (one for the graphics queue, another for the present queue; which may or may not be set to the same value), and ownership transfer.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi!
What the title says :)
According to Synchronization Examples and Google's samples it is possible the rendering queue does not support presentation; therefore a different queue must be used for presentation.
I don't know what GPUs out there require the code to handle this case, but it appears it must be dealt by the code. Maybe it's Optimus laptops, maybe it's Android devices that have a special queue for handling rotations.
The text was updated successfully, but these errors were encountered: