Skip to main content
New Participant
December 29, 2025
Question

Feature request - Expose Android Surface swapchain frames to GPU (Vulkan) for compute processing

Hello Meta XR / OpenXR Runtime Team,

I’m developing a Quest 3 OpenXR 8K video player using Vulkan. It uses MediaCodec to decode video frames directly into a runtime-owned Android Surface swapchain (XR_KHR_android_surface_swapchain) in a zero-copy pipeline. This works well for playback, but it prevents the application from running any GPU processing on the decoded frames (e.g., sharpening, denoise, chroma upsampling, lightweight super-resolution) before the runtime compositor samples the surface for an XrCompositionLayerEquirect2KHR layer.

Feature request:
I’d like to request an official, supported way for applications to access the decoded frame content on the GPU (Vulkan) prior to composition, while retaining the benefits of the Android Surface swapchain decode path. The current copy/blit workaround is not acceptable because it adds significant memory bandwidth overhead and defeats the purpose of the zero-copy pipeline.

Sincerely,

Zurab Kargareteli - Graphics Engineer
Vrex Immersive
zurabkargareteli@vreximmersive.com

2 replies

steve40
Honored Contributor
January 1, 2026

You should submit a formal suggestion to the Developer Feedback Center, where it has less chance of being ignored šŸ¤·ā€ā™‚ļø.

PS. it's probably not a good idea to post your email in a public forum where spambots might harvest it.

New Participant
February 5, 2026

This is a well explained request highlighting a real limitation of the zero copy pipeline, and exposing GPU access before composition would unlock meaningful post-processing without costly workarounds. Right now the restriction feels like handing off frames blindly, almost like relying on a cold calling agency london instead of giving developers direct, controlled access to optimize quality.