OFXR Bridge v0.2.4 (V312)

An unofficial build on
tig3rmast3r's v0.2.1.
The first release after the 0.2.3 betas.

What's new

• Much better performance on SteamVR headsets (Pimax and any other headset
  that runs through SteamVR).
• The bridge arms itself when you start the tray.
• New option: Prefer FPS over latency. It is on by default. It adds one
  frame of latency. In return, a game that only just reaches half your
  headset's refresh rate can reach the full rate, and FPS dips are much
  smoother.

If you saw little or no benefit on SteamVR before, try this release. The
likely cause is fixed. SteamVR was throwing away generated frames that were
already finished, so the frame rate barely rose even though the bridge was
working. How often that happened depended on the game and the machine, which
is why some users saw a clear gain and others saw almost none. The section
below explains what changed.

Much better performance on SteamVR

SteamVR needed work that other runtimes do not, and the bridge now has a
pipeline built specifically for it.

Why SteamVR needs it. The bridge sends the headset two frames for every
frame the game renders: the real one and a generated one. The two have to
arrive one display refresh apart. Virtual Desktop (VDXR) handles that itself:
each time the bridge asks for its next frame slot, it waits until one refresh
has passed. SteamVR answers straight away. If the bridge sent the second frame
then, both frames would arrive in the same refresh and the compositor would
throw one away. On SteamVR the bridge therefore has to time its frames against
SteamVR's compositor. It asks the compositor where it is in its current
refresh and places each frame in time for the next one.

What changed in this release. SteamVR only uses a frame once the GPU work
that produced it has finished, and it tracked that finish on the game's own
GPU queue. The game queues its next frame on the same queue straight away. So
a generated frame that was already finished could still look unfinished to
SteamVR, which dropped it and showed the previous image again. On SteamVR,
the bridge now gives the runtime a queue of its own, which holds only the
bridge's frames. The game's next frame can no longer delay them.

In our testing on a Pimax Crystal Super, Hogwarts Legacy at 8344×3268 held
87 FPS or more 94% of the time and felt steady at 90 throughout. In MSFS 2024,
the dips that used to stutter and freeze now stay close to 90.

The separate queue is used only for games that use D3D12 directly, and only
on SteamVR. On other runtimes it brought no gain, so they keep the game's
queue.

The bridge arms itself

Starting OFXRBridgeTray.exe now arms the bridge straight away; you no
longer need to pick Arm bridge until manual disarm first. As before,
closing the tray or selecting Disarm bridge turns it off. If arming
fails, the tray shows why and stays disarmed, and you can retry from the menu.

Prefer FPS over latency

A new tray option, on by default.

What it does. The bridge holds each generated frame back by one display
refresh, which gives the optical flow a whole refresh to finish its work.
Without the option, it has only the gap the game leaves between frames. When
the game is close to its limit, that gap is small, and generated frames that
finish late are dropped.

What you gain. If your game can only sustain half your headset's refresh
rate, you can now get the full benefit of frame generation. A game holding
45–50 FPS on a 90 Hz headset is likely to reach 90. Dips are also much
smoother, because a frame that is a little late no longer drops out.

What it costs. One frame of extra latency: about 11 ms at 90 Hz and
10 ms at 100 Hz.

When to turn it off. When your GPU has budget to spare. The simplest way
to tell is to try it: turn the option off and play the same scene. If you
still hold your full frame rate, leave it off and you save one frame of
latency. If you lose frames or the dips come back, turn it back on.

The change takes effect the next time the game starts.

Other changes

• D3D11 games drop fewer frames. For D3D11 games (Cyberpunk 2077 through
  R.E.A.L. VR, Assetto Corsa and others), the bridge's own GPU work now runs at
  high priority, as it already did for D3D12. In our Cyberpunk 2077 testing,
  the frames SteamVR skipped fell from over 20 a minute to about 6.
• Fewer missing generated frames in games that run their own frame
  timing. MSFS 2024 sends frame timings that do not always move forward.
  With Prefer FPS over latency on, the bridge now pairs frames in the order
  the game renders them. Frames with an out-of-order timing still get a
  generated frame instead of being skipped.
• A generated frame is never shown unfinished. If the GPU has not finished
  a generated frame by its turn, the bridge shows the previous frame again and
  sends the generated one at the next refresh.
• More detailed flight logs on SteamVR. With the Bridge flight recorder
  on, the log now records every frame SteamVR's compositor settled, including
  the ones it never showed. Reports with a log are much quicker to diagnose.

Known issues

• Dips are often a resolution ceiling, not the bridge. Disarm the bridge
  and play the same scene: if the dips remain, your PC is past its comfortable
  per-eye resolution. When you report a dip, please say whether it survives
  disarming, and at what per-eye resolution.
• Very high per-eye resolutions remain the hard limit. Above roughly 9
  megapixels per eye, generated frames may not be finished early enough to be
  shown.
• Pick a refresh rate close to double your game's frame rate. Frame
  generation doubles the game's frame rate. If double is still short of the
  refresh rate, the bridge fills the difference with repeated frames and the
  image judders.
• If SteamVR is restarted while a game is running, the frame timing the
  bridge reads from SteamVR may stop being accurate until the game is restarted.
• Selecting the NVIDIA backend without an NVIDIA card silently does
  nothing. On AMD or Intel, leave the backend on FidelityFX, the default.

Installing

Unzip anywhere and run OFXRBridgeTray.exe. It arms the bridge by itself.
Keep OFXRBridgeTray.exe and the ofxr folder together. If an earlier
version is armed, disarm it and close its tray first.

Tested

On SteamVR with a Pimax Crystal Super OLED:

• Hogwarts Legacy and The Callisto Protocol (UEVR, D3D12)
• Microsoft Flight Simulator 2024 (D3D12)
• Cyberpunk 2077 through R.E.A.L. VR (D3D11)
• Assetto Corsa (D3D11)
• Skyrim VR FUS with opencomposite (D3D11)

On a Quest 3 through Virtual Desktop (VDXR):

• Hogwarts Legacy and Microsoft Flight Simulator 2024, at 90, 100
  and 144 Hz

Compatibility is not universal. Please report results, working or not, on
this fork's GitHub Issues, with an OFXR flight log where you
can. To record one, enable Bridge flight recorder in the tray, reproduce
the problem, then use Open bridge logs. Logs are written under
%LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v312\.