OpenXR-Docs
OpenXR-Docs copied to clipboard
KhronosGroup
Visibility mask API interacts poorly with multiview rendering
First, background: multiview rendering broadcasts a single stream of commands to two separate layers of an array image, with shader invocations distinguished on the GPU by an index that can be used to e.g. select the appropriate view-projection matrix. This is very convenient and may improve performance for stereo rendering, as is common with HMDs.
The visibility mask API provides a distinct set of vertices and indices for each view. This makes it painful to combine with multiview, because with multiview you must bind a single index buffer/vertex buffer set and render it to both views. OpenXR provides no guarantees whatsoever about the topology of the visibility mask, so portable code cannot assume that even the number of vertices matches, let alone their connectivity. Therefore, simply uploading the provided geometry to the GPU and drawing, even selecting between two vertex inputs based on view ID in the shader, is not portable.
I've worked around this problem in my application by flattening the indexed geometry of each view into a non-indexed triangle list, padding any mismatch in number of vertices using degenerate triangles, and finally selecting between two vertex inputs using the view index. This works okay in practice, but feels like a really horrible hack.
A simple fix (which I really hope is consistent with real-world deployments) would be for the visibility mask extension to guarantee that the topologies of the meshes are identical when used with XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO. This would still require two vertex buffers to be bound, or for position data to be fetched manually from e.g. a SSBO, but reduces the effort needed from the application substantially. A more disruptive change could improve on that further by supplying a single mesh and per-view transform matrices for it, but that may not be justified.
An issue (number 1542) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1542 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
