Quick 3D multiview plumbing (umbrella)

Some identified problems so far (i.e. things that are less trivial to deal with).

How does post-processing effects work in multiview mode (i.e. when the renderMode is Underlay/Overlay and our main render target is a texture array with size 2)? Any intermediate 2D texture is incorrect, they need to be texture arrays as well, but that has consequences rolling down to the shader code level, incl. user-provided shader code. Also internal logic such as "fullscreen" blits need to be quite different when a texture array is involved. Alternatively, effects could stay with a '2 separate runs' mode, i.e. do the left eye with layer 0 as the source using regular 2D intermediate textures, blit the result back to layer 0, then repeat for the right eye (layer 1). This could achieve shader code compatibility to a large degree. Although there are other problems, see below points.
-> to be investigated QTBUG-125056 QTBUG-125132 QTBUG-125136

What happens to PROJECTION_MATRIX, INVERSE_PROJECTION_MATRIX, VIEWPROJECTION_MATRIX, MODELVIEWPROJECTION_MATRIX, VIEW_MATRIX , etc. in multiview mode in custom materials and effects? (there is two? how is that exposed to the shader? how do they know which one is "active"? What if accessed in a fragment shader? etc.) For effects it could be that having 2 separate runs is a better way, in which case this is less of an issue. But custom materials are regardless a problem.
-> assumed to be solved

Consequences for instancing? E.g. it does not simply take a qt_modelViewProjection "uniform" but calculates based on qt_viewProjectionMatrix and others.
-> assumed to be solved

SSAO? Uses the depth texture, the fragment shader uses sampler2D of course. How does this deal with the case when the depth texture is an array of size 2?
_-> The AO texture also needs to be an array with multiview. Done.

Just as with SSAO, have no overview yet which built-in (static) shaders need to be multiview-aware. Should be evaluated one by one based on their usage (e.g. a shader cubemap blur shader needs no multiview support because it is never used with a multiview render target, whereas others might need differentiation in the vertex shader, and in some cases, e.g. SSAO, in the fragment shader too?)
-> Particles done. Shadows do not need to care about this. (and the shadow system will anyway change soon).

Depth and screen textures handled separately. QTBUG-124842 QTBUG-124843

Skybox static shaders need to be made multiview aware (viewMatrix, inverseProjectionMatrix). Done.

-> Done

Grid

-> Done

Reflection probes. (and skybox within a reflection probe?)

-> Looks ok for now

Render extensions are not multiview aware, in the sense that only one camera is ever exposed. See todo (###) in QSSGLayerRenderData::prepareModelsForRender().
-> open

What features rely on the camera? (on the projection or view matrices) Once there are multiple of those (matrices), features where the result is a single image (e.g. a shadow map, either 2D or cubemap), but using calculations that are based on the camera, become problematic. Ideally the results should not become texture arrays, but then what? Also, does it always matter to be fully correct? Can we use the left eye's camera for the right eye in some cases (or vice versa), in case the visual results are still acceptable? For example, shadows have frustum bounds calculations. What about reflections, particles, frustum culling, etc.?
-> assumed to be solved, by using the first (left eye) camera where sensible.

Not difficult but annoying: APIs such as mapFrom3DScene in the View3D need a new counterpart that deal with the fact of multiple "cameras" (like take an index to be able to say the result should be based on the right eye camera)
-> open