An unofficial build on
tig3rmast3r's v0.2.1.
A follow-up to 0.2.3_beta1 — two fixes, no new features.
Short version
If you play a D3D11 game on SteamVR — Skyrim VR above all — take this build.
It fixes a fault that could crash or freeze the game, and it fixes frame
delivery in that title specifically.
Everyone else on SteamVR should take it too. 0.2.3_beta1's frame delivery
depended on where the bridge's schedule happened to start when you launched.
Sometimes that was a good place and you got the full rate; sometimes it wasn't,
and you lost a third of your frames for the whole session with no way back. That
is fixed. Same game, same machine, two launches now give you the same result.
Nothing outside SteamVR is touched. VDXR, Oculus and PimaxXR take exactly the
path they did in 0.2.3_beta1.
What was wrong
1. The schedule started wherever it landed, and stayed there
beta1 asks SteamVR where the display is and corrects towards it every frame.
That part worked. But the correction was limited to 50 microseconds a frame — a
size chosen for cancelling slow drift — while the error it had to fix could be
half a refresh interval. It never got there, so the session kept whatever
starting position it was given.
Worse, the arithmetic wrapped the error into one refresh interval. Being a
whole frame out looked identical to being perfectly on target, so the bridge
reported itself correct while your headset received half the frames. Nothing in
the bridge could see the difference.
Both are fixed: the correction is no longer limited to a size that cannot fix
the problem, and it no longer folds a whole-frame error down to nothing.
2. Two threads in the runtime at once, on D3D11 games
When the game uses D3D11 — Skyrim VR, and a number of older titles — the bridge
must keep its two threads from being inside the OpenXR runtime's D3D11 code at
the same time, because the NVIDIA driver does not survive it. That guard existed
but had a gap: one of the calls it needed to cover was never included.
Measured in a Skyrim VR session, the two threads met inside the runtime on
31.5% of calls — about 17,000 times in a single session. The NVIDIA D3D11
driver crashed twice in one afternoon of testing, and never once in 249 crash
logs going back eighteen months.
The gap is closed.
Measured
Delivered frames a second, from SteamVR's own counters, on a Pimax Crystal
Super OLED at 90 Hz:
| 0.2.3_beta1 | 0.2.3_beta2 | |
|---|---|---|
| Skyrim VR (D3D11, OpenComposite) | unplayable dips, crashes | 89.7 |
| The Callisto Protocol (UEVR) | varied by launch | 89.5 |
| Hogwarts Legacy (UEVR) | 67.7 | 81.4 |
Hogwarts and Callisto were measured back to back in the same areas. Skyrim VR
could not be measured meaningfully on beta1 because of fault 2.
How to tell it is working
The same signs as beta1 — the overlay counter should sit at your full refresh
while the game's own rate sits at half it, and fpsVR should agree.
What is new is that it should do so every launch, not some of them. If you
used to see one session run beautifully and the next one sit at two thirds for
no reason you could name, that was fault 1, and it is the thing this build is
for.
Known issues
- Hogwarts Legacy still sits below the others, around 81 rather than 89. It
is a large improvement over beta1's 67.7 but it is not where Callisto and
Skyrim are, and we do not yet know why — its submissions scatter more inside
the compositor's frame than other titles', despite the game itself being no
less steady. Under investigation. - The D3D11 fix is not proven, only measured. The fault it addresses is
probabilistic and can take a minute or more to appear, so a clean session does
not prove much. If a D3D11 game still crashes inside the runtime or freezes
with the process alive, please report it. - Very high per-eye resolutions remain the hard limit, unchanged. Above
roughly 9 megapixels per eye the generated frame cannot be finished early
enough to be shown. - Selecting the NVIDIA backend without an NVIDIA card silently does nothing.
On AMD or Intel leave the backend on FidelityFX, the shipped default.
Everything else is unchanged from 0.2.3_beta1
The NVIDIA backend recommendation, the odd-looking frame times in fpsVR, the
optical flow resolution setting and the installation steps are all as described
in the 0.2.3_beta1 notes. Nothing in this release changes how
frames are generated — only when they are handed over.
Installing
Unzip anywhere and run OFXRBridgeTray.exe, then Arm bridge. Keep
OFXRBridgeTray.exe and the ofxr folder together. If you have an earlier
version armed, disarm it first.
Tested
- Skyrim VR through OpenComposite, with the FUS modlist
- The Callisto Protocol and Hogwarts Legacy (UEVR)
- Microsoft Flight Simulator 2024
on SteamVR with a Pimax Crystal Super OLED, on the NVIDIA OFA backend, and
cross-checked on a Quest 3 through VDXR with no change to that path.
This is an experimental beta and compatibility is not universal. Please report
results — working and not — on this fork's GitHub Issues, with
an OFXR flight log where you can. Enable one by setting logging_enabled=1
under [diagnostics] in ofxr_bridge.ini; logs are written next to the armed
layer under %LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v268\.