feat-fix(server_openvr): Add timewarped compositing to Windows OpenVR compositor

[shinyquagsire23]

Fixes juddery menus on Riven, and possibly judder on other OpenXR apps (HUDs, 2D menus, text, etc rendered at higher resolutions are the most likely candidates).

Before vs After

tl;dr on compositing

• To composite with timewarp, we need three things: The exact view poses the layer frame was rendered at, the headset's per-eye view frustum tangents, and a renderer which can render a quad with positions/sizes in meters.
  • FrameRender is now passed the pose of each layer, the view tangents, and the eye transforms to make this happen.
• The layer's quad is centered at 0,0 and extended 1 unit out in each direction, and then each direction is multiplied by the view tangents.
  • Each layer's quad is projected forward by 700m (to "infinity") and scaled proportionally, to remove small positional differences from IPD and the user's head rotation.
  • If the layer is at the exact current view position (which is always the case for layer 0), it will be projected pixel-perfect onto the framebuffer.
  • Layers indices >=1 only ever seem to appear in OpenXR-based titles, I think OpenVR started compositing its app layers into layer 0 on our behalf within the last 6 months (the dashboard used to be juddery as well).
• For simplicity, and to make debugging a bit easier, I did all the vertex math on the CPU with the DirectX math functions (it's only 8 vertices and DirectX has SIMD support anyway).
  • I also split the draw command into two calls with different viewports/scissor rects, since the quads could cross between eyes after the transform
• Also I removed the depth buffer for now, since we were not actually using it. If we ever decide to try and get fancy with depth buffers we can add it back I guess.

[zmerp]

Sorry it took a bit, left some comments.

[shinyquagsire23]

@zmerp Addressed the nits, I guess I kinda see the logic on m_pD3DRender since it would allow render passes to do things with per-eye transforms and such if they needed to w/o a bunch of arg passing, but it still seems a bit odd to me.

[zmerp]

Looks nice now. I didn't test but either this code is all correct it or it will crash, edge cases are unlikely. Your testing should suffice.

[zmerp]

Oh wait, my bad. I said the class d3dRender but I meant FrameRender. I thought they were the same class.

[shinyquagsire23]

should be set now