Forum Discussion
Anonymous
4 years agoIssue with xrEnumerateSwapchainImages
This has been verified with Oculus OpenXR runtime version 1.55.0 using the XR_KHR_D3D11_enable extension.
According to the OpenXR spec, xrEnumerateSwapchainImages() has two modes of operation: a size query mode, where imageCapacityInput is 0 and only imageCountOutput is returned, and a texture retrieve mode, where the images array is filled up to imageCapacityInput capacity. Obviously, only the second call should AddRef() the swapchain textures (and only those that are actually passed back to the application), because the first call returns no pointers that the application can later Release().
Instead, with the current runtime, xrEnumerateSwapchainImages() AddRef()'s all the swapchain textures even in the first mode of operation. With the typical two-call paradigm (query for size first, then retrieve the array), this leads to a hidden increment of the reference count for all swapchain textures, which later on shutdown prevents the textures (and thus the D3D11 device) from ever being released correctly, leaking video memory.
This is normally hidden in simple test applications by the fact that the application terminates right away, forcing a cleanup of the device. But in more complex real-world scenarios, like the one I'm working on currently where the OpenXR renderer can be toggled on and off multiple times, this leads to all swapchain textures leaking every time.
According to the OpenXR spec, xrEnumerateSwapchainImages() has two modes of operation: a size query mode, where imageCapacityInput is 0 and only imageCountOutput is returned, and a texture retrieve mode, where the images array is filled up to imageCapacityInput capacity. Obviously, only the second call should AddRef() the swapchain textures (and only those that are actually passed back to the application), because the first call returns no pointers that the application can later Release().
Instead, with the current runtime, xrEnumerateSwapchainImages() AddRef()'s all the swapchain textures even in the first mode of operation. With the typical two-call paradigm (query for size first, then retrieve the array), this leads to a hidden increment of the reference count for all swapchain textures, which later on shutdown prevents the textures (and thus the D3D11 device) from ever being released correctly, leaking video memory.
This is normally hidden in simple test applications by the fact that the application terminates right away, forcing a cleanup of the device. But in more complex real-world scenarios, like the one I'm working on currently where the OpenXR renderer can be toggled on and off multiple times, this leads to all swapchain textures leaking every time.
1 Reply
- johnkearneyMeta EmployeeThanks for the clear information here @LukeRoss.
There is a bug here for sure - we will put up a fix ASAP. It will be included in the v27 release.
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device
Other Meta Support
Related Content
- 11 months ago
- 1 year ago
- 1 year ago
- 1 year ago