-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to correctly implement/interpret xrReleaseSwapchainImage specification? #177
Comments
You call xrReleaseSwapchainImage once you are done submitting your draw commands, the runtime will do something like inserting a fence and checking asynchronously to see if it is done. (I think this is your option 2, in your first list. The runtime should not block on the image you submitted: if it's not ready in time, it will re-use your old one.) If you call xrEndFrame without calling xrReleaseSwapchainImage during that "frame", the runtime will reproject the frame from the last time that you called xrReleaseSwapchainImage. Usually you do not want to do this, but sometimes you might have a layer that is only infrequently updated. (I think this is your option 3 in your second list.) Does this help? |
@rpavlik ad 1) If the runtime/compositor should not block on (possibly still being rendered) "last released" image (which makes sense), taking an older released image may lead to situation where the compositor is compositing a mix of "current" and "old" released/finished images. To elaborate - until now I understood the spec. in a way that the app defines (implicitly) a set of images which should be composited together into a particular frame, by calling ad 2) I guess I read "not calling |
After some thought, I suggest that the specification makes the distinction between "last released" and "last finished" image and use the right one in the swapchain management context (going with the wording/explanation along your answer). I also suggest clarifying the "not calling Otherwise this topic can be closed. |
An issue (number 2387) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2387 ), to facilitate working group processes. This GitHub issue will continue to be the main site of discussion. |
From the current OpenXR spec (https://registry.khronos.org/OpenXR/specs/1.1-khr/html/xrspec.html), bold face is mine:
xrReleaseSwapchainImage
(excerpt):From
xrReleaseSwapchainImage
spec. it is not clear whether the client callsxrReleaseSwapchainImage
right after submitting all commands to the command queue (but possibly not having the image rendered by GPU yet), or client must synchronize on GPU work before calling the function.xEndFrame
call, so it may need toxEndFrame
call, but this may unnecessary block some images, which may have been already replaced by newer ones by the client, and lose the images which has been finished.Having the compositor waiting for the image to be released by GPU may lead to lost vsync.
So the common sense would suggest that the synchronization would be the responsibility of the client app, but after having look at
hello_xr
demo I did not find any such mechanism. So what is the right approach for the runtime?Another unclarity is related to
xrEndFrame
and the possibility for client to not callxrReleaseSwapchainImage
before.From OpenXR spec. -
Frame Submission
(excerpt):An application may call xrEndFrame without having called xrReleaseSwapchainImage since the previous call to xrEndFrame for any swapchain passed to xrEndFrame.
What is the right approach for the runtime then?
xrReleaseSwapchainImage
on each image which has been "waited" on?The text was updated successfully, but these errors were encountered: