OpenXR support and late latching

[zmerp]

OpenXR support is still early in development and it is early for talking about optimizations but I want to mention a few things to keep in mind while defining the pipelined rendering architecture.
Late latching is a technique for reducing the jitter of head and controllers by polling their poses as late as possible.

OpenXR expects very strict coupling between update and rendering logic. A naive single threaded OpenXR application loop looks like this:

1. Logic/physics updates are executed. Head and controller poses are polled here.
2. Rendering happens respecting head and controller poses.
3. Frames are presented.
4. xrWaitFrame() is called, which throttles the application to sync up with the XR runtime. The runtime dynamically adjusts the blocking duration of this call to minimize updates latency.

This is what I'm targeting while developing the OpenXR support.

A multithreaded application with update + rendering threads that implements late latching should look like this:

Update loop thread:

1. Get copy of head and controller poses polled from the render thread.
2. Do update logic.
3. sleep() for throttling.

Render loop thread:

1. Record command encoders (this can happen also in another thread).
2. Poll head and controllers poses (keep a copy for the update thread).
3. Submit command buffers with updated poses.
4. Present frames.
5. xrWaitFrame()

Late latching cannot be implemented without deep integration. In the current architecture, resources are polled in the RenderStage::Extract stage, but head and controller poses should be polled just before the Render stage or even inside it. I think the best way to achieve late latching is to add a flag to GlobalTransform with the type of pose source (or none). The engine should keep track of this flag for the entire rendering process and the render graph is shaped so that the pose data can be polled and submitted as late as possible (for example as push constants).