34930eaf5b
Originally, Metal did not support this directly, and still largely doesn't on GPUs other than Apple family 6. Therefore, this implementation uses vertex instancing to draw the needed views. To support the Vulkan requirement that only the layers for the enabled views are loaded and stored in a multiview render pass, this implementation uses multiple Metal render passes for multiple "clumps" of enabled views. For indirect draws, as with tessellation, we must adjust the draw parameters at execution time to account for the extra views, so we need to use deferred store actions here. Without them, tracking the state becomes too involved. If the implementation doesn't support either layered rendering or deferred store actions, multiview render passes are instead unrolled and rendered one view at a time. This will enable us to support the extension even on older devices and OSes, but at the cost of additional command buffer memory and (possibly) worse performance. Eventually, we should consider using vertex amplification to accelerate this, particularly since indirect multiview draws are terrible and currently require a compute pass to adjust the instance count. Also, instanced drawing in itself is terrible due to its subpar performance. But, since vertex amplification on family 6 only supports two views, when `VK_KHR_multiview` mandates a minimum of 6, we'll still need to use instancing to support more than two views. I have tested this extensively against the CTS. I'm very confident in its correctness. The only failing tests are `dEQP-VK.multiview.queries.*`, due to our inadequate implementation of timestamp queries; and `dEQP-VK.multiview.depth.*`, due to what I assume is a bug in the way Metal handles arrayed packed depth/stencil textures, and which may only be a problem on Mojave. I need to test this on Catalina and Big Sur. Update SPIRV-Cross to pull in some fixes necessary for this to work. Fixes #347.
2 lines
41 B
Plaintext
2 lines
41 B
Plaintext
bad9dab8df6f2e6b80da9693db247b9357aebd2f
|