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
Unity's CommandBuffer.IssuePluginCustomTextureUpdateV2 method causes a major drop in performance (fps) when rendering high-res (~4K) textures on Android devices when using Vulkan due to an expensive memcpy call to copy the buffer data from CPU to GPU. This is impacting a customer trying to use com.unity.webrtc as this is invoked by WebRTC.UpdateRendererTexture.
Describe the solution you'd like
Ideally the native plugin would implement a zero-copy approach using native buffers to avoid the memcpy and speed up Vulkan performance.
Describe alternatives you've considered
An investigation found multiple old branches on this repository which (based on their naming) suggest they were attempts at addressing this very issue, namely experimental/android-hardwarebuffer and experimental/nativeframebuffer. However both of these branches have been abandoned without merge and are quite stale. If any of these are indeed relevant to the issue then picking one, updating it with main, and resuming the effort seems like the obvious approach, but the merge conflicts could prove challenging for anyone not super familiar with the codebase. Those also include changes for D3D11/D3D12, OpenGL, and Metal, which I neither need nor am able to build for and test changes with.
Additional context
This has been observed on XR HMD devices running the OpenXR Plugin. The customer attempted to port a Meta Quest 3 app to the Magic Leap 2. The Quest3 and the Meta XR provider support OpenGL but the ML2 and the OpenXR Plugin do not, so Vulkan is required.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Unity's
CommandBuffer.IssuePluginCustomTextureUpdateV2
method causes a major drop in performance (fps) when rendering high-res (~4K) textures on Android devices when using Vulkan due to an expensive memcpy call to copy the buffer data from CPU to GPU. This is impacting a customer trying to use com.unity.webrtc as this is invoked by WebRTC.UpdateRendererTexture.Describe the solution you'd like
Ideally the native plugin would implement a zero-copy approach using native buffers to avoid the memcpy and speed up Vulkan performance.
Describe alternatives you've considered
An investigation found multiple old branches on this repository which (based on their naming) suggest they were attempts at addressing this very issue, namely experimental/android-hardwarebuffer and experimental/nativeframebuffer. However both of these branches have been abandoned without merge and are quite stale. If any of these are indeed relevant to the issue then picking one, updating it with main, and resuming the effort seems like the obvious approach, but the merge conflicts could prove challenging for anyone not super familiar with the codebase. Those also include changes for D3D11/D3D12, OpenGL, and Metal, which I neither need nor am able to build for and test changes with.
Additional context
This has been observed on XR HMD devices running the OpenXR Plugin. The customer attempted to port a Meta Quest 3 app to the Magic Leap 2. The Quest3 and the Meta XR provider support OpenGL but the ML2 and the OpenXR Plugin do not, so Vulkan is required.
The text was updated successfully, but these errors were encountered: