Skip to content

OFXR Bridge v0.2.5 (V324)

Choose a tag to compare

@djules75 djules75 released this 25 Sep 17:56
· 69 commits to main since this release

An unofficial build on
tig3rmast3r's v0.2.1.
A follow-up to 0.2.4.

What's new

  • Vulkan support (experimental, off by default). Frame generation for
    games that render through Vulkan. Tested with No Man's Sky through
    OpenComposite on SteamVR.
  • Unity games no longer hang. Games whose D3D11 device is single-threaded,
    which Unity creates by default, froze on the loading screen (The Forest VR
    through OpenComposite was the reported case). They run now.
  • UEVR games with many swapchains now generate. Ghostwire: Tokyo showed a
    red FPS number from the first frame because SteamVR ran out of swapchains.
    The bridge now falls back to the lighter pipeline for that session instead
    of giving up.

Vulkan support

Turn it on in the tray: Vulkan support (experimental). It is off by
default
and will stay off by default until it has had more testing and
feedback — please report results, working or not.

What it does. With the option on, the bridge generates frames for Vulkan
games exactly as it does for D3D11 games: the game's frames are moved into
the bridge's own D3D12 device for optical flow and the generated frames are
moved back.

What it installs. A Vulkan game's runtime submits work on the game's own
GPU queue, and so does the bridge, from a second thread — which Vulkan
forbids, and which crashed the game after a few seconds in testing. So while
the bridge is armed with the option on, it registers a small Vulkan layer of
its own (OFXR_vulkan_queue_layer.dll) that puts a lock around queue
submissions. It does nothing else. It is registered when you arm and removed
when you disarm or close the tray, like the OpenXR layer itself, and the
watchdog removes it if the tray exits unexpectedly. Note that a Vulkan
implicit layer loads into every Vulkan application while it is
registered — browsers included. That is the reason the option is off by
default. If you ever need to keep the bridge armed but stop the layer for one
program, set OFXR_DISABLE_VULKAN_QUEUE_LAYER=1 in that program's
environment.

Known limitation: no FPS number in Vulkan games. The in-headset FPS
overlay has no Vulkan path yet, so the number does not draw and the
"delivered" counter with it. The purple and green diagnostic squares still
show that generation is running. Use fpsVR or the Virtual Desktop overlay to
read the rate.

SteamVR: turn off "fixed frame rate at half" for the game. In SteamVR's
per-application video settings, both this and Motion Smoothing make SteamVR
hold the game to half rate, and the bridge can then only deliver half. With
it off, No Man's Sky on a 72 Hz headset delivered a real 72.

Tested with: No Man's Sky (Steam) through the OpenComposite build linked
above, on SteamVR with a Pimax Crystal Super, through the menu, the galaxy
loading screen and into the world. Nothing else Vulkan has been tried yet.
Note that X-Plane 12, though it renders in Vulkan, submits to OpenXR through
a D3D11 bridge of its own and already worked before this release.

Other changes

  • Games whose D3D11 device is single-threaded (Unity's default) never get a
    second bridge thread, since that thread raced the game's on the device and
    hung it. They run inline instead, which paces less well on SteamVR but does
    not hang. Ticking nothing is needed.
  • When SteamVR refuses a swapchain while the bridge is arming with "Prefer
    FPS over latency" (which needs four per eye against three), the session
    drops to the lighter pipeline and arms again rather than passing the whole
    game through. UEVR games that submit depth are the ones that hit the limit.
  • The headset's refresh rate is read from the compositor itself, so a game
    that SteamVR throttles from its first frame no longer paces the bridge to
    the throttled rate.

Known issues

  • No FPS overlay in Vulkan games (above).
  • Vulkan runs on SteamVR only in testing so far. VDXR has not been re-run
    with the Vulkan layer; the earlier failure there was the same cause the
    layer fixes, so it should hold, but it is unconfirmed.
  • Dips are often a resolution ceiling, not the bridge. Disarm the bridge
    and play the same scene: if the dips remain, lower the per-eye resolution.
  • Pick a refresh rate close to double your 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.
  • Selecting the NVIDIA backend without an NVIDIA card silently does
    nothing.
    On AMD or Intel, leave the backend on FidelityFX.

Installing

Unzip anywhere and run OFXRBridgeTray.exe. It arms the bridge by itself.
Keep OFXRBridgeTray.exe and the ofxr folder together — it holds the
OpenXR layer, its settings and, new in this release, the Vulkan layer. If an
earlier version is armed, disarm it and close its tray first.

Tested

On SteamVR with a Pimax Crystal Super OLED:

  • No Man's Sky through OpenComposite (Vulkan, the option on)
  • Ghostwire: Tokyo (UEVR, D3D12) — the swapchain fallback
  • Microsoft Flight Simulator 2024 and Hogwarts Legacy (UEVR) — both
    at 90 delivered on the deep pipeline, unchanged
  • The Forest VR through OpenComposite (Unity, D3D11) — the hang fix
  • Assetto Corsa (D3D11) — unchanged

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\v324\.