Open risa2000 opened 1 month ago
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 Thanks, you answered my questions! I have just two comments.
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 xrEndFrame
and the images are exactly those "last released" in respective swapchains referenced in XrFrameEndInfo
.
Using your interpretation, the images which will be composited are not necessarily those "last released", but those "last finished", which is a subtle but important difference as this way the client cannot be sure what actually ends up in the composited frame. It may not be what was released immediately prior to xrEndFrame
call.
ad 2) I guess I read "not calling xrReleaseSwapchainImage
" as client missing it as the last part of the whole sequence (Acquire
, Wait
, and Release
). While your interpretation suggests that the meaning is rather the client not rendering a new image in a specific swapchain at all, but still using the swapchain for composition (in xrEndFrame
). In that case the compositor is still using "the last released/finished" image, it just might be one which is not updated regularly. Makes sense.
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 xrReleaseSwapchainImage
" with an explanation you gave above.
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?