Vulkan multiview rendering

[hrydgard]

VK_KHR_multiview is a very widely supported Vulkan extension that lets you automatically and very efficiently duplicate rendering across layers in a framebuffer, and you get a convenient gl_ViewIndex variable in the shaders so you can customize matrices and so on per view.

Obviously, this is perfect for stereo rendering, such as required by VR. But can also be used for regular old stereo effects like red/blue, and it's easier to start with that, since it can be cleanly debugged with plain Renderdoc and stuff, before hooking up VR stuff. Unfortunately, this does mean that we need to handle multilayer render targets everywhere. It can be mostly abstracted away, but not entirely.

This is not by any means finished yet, but thought people might want a preview so making a draft PR.

There's plenty of work left to do all over the place, most of our shaders like reinterpret and so on are not multiview-aware. They don't really need to be, but in that case they need to loop over the layers.

So right now only games that don't do a lot of fancy framebuffer effects work.

Non-goals:

• Combine stereo with regular post-processing. Could be done, but likely not worth the trouble.

Post-goals (after this is merged):

• Improve the depth distortion function, the Z value we are using makes little sense for many games.
• Make depth distorsion and the zero depth configurable (per-game needed? Likely). This will require adding a couple of uniforms, which we now have space for
• Try to hook up VR with Vulkan using this

[hrydgard]

Remaining issues:

• Track layout separately for the two layers of a framebuffer in the queue runner (though, avoidable with the next point);
• Add a mode that can run a single "2d" render pass over both layers, automatically picking the right source layer as a 2d texture and the right destination layer as a framebuffer. This will avoid the problems of the first point, but require a big refactoring where we move descriptor set management of Draw2D to the queue runner, for it to independently be able to change textures.
• 3rd alternative: Make all the little passes like reinterpret and depal aware of stereo. I would really like to avoid this, at least initially.

I'm currently leaning towards point 2, because it will be by far the least invasive across the rest of the code. I don't want much stereo logic to leak into the regular framebuffer and texture management, that stuff should all look like before.

Although, come to think of it, all the little passes are using ShaderWriter for shader generation these days. Maybe it would not be that hard to make them all stereo-aware without much fuss....

Now leaning towards 3, ShaderWriter-aided...

[hrydgard]

Getting pretty close now, stereo makes it through all the major rendering pathways now, including depal.

There are still a few issues (getting validation errors in a few games) but getting there.

Not quite happy about how complex this stuff ended up though... but performance-wise, it'll probably worth it for VR (plus, we can't easily multipass like we can in GL due to how we do descriptor set management), and it's a cool novelty feature on desktop.

[hrydgard]

OK, compatibility is way better now (although the depth function is still bad). But I prefer to work on that part after merge, I think.

Still needs some more general testing before we can merge though, which I will do.

[hrydgard]

Seems pretty solid now, including on Android, which is nice. Fixed up the setting and the check for the Vulkan feature.

[hrydgard]

Lubos pointed out that the SBS shader would be a full replacement for the Cardboard mode, with a couple of parameters added. So once this is in, I'll probably just get rid of all the old cardboard stuff in favor of this.

[hrydgard]

This currently breaks the Oculus build, some shader error. Will fix.