OFXR Bridge V439 release 38 - fix frame pacing regression

OFXR Bridge V439, release 38

This release fixes the 2X deep-pipeline pacing regression introduced in
release 37's V452 port. Affected non-SteamVR sessions could fall toward
60 displayed frames per second on a 90 Hz headset even though generated
images were ready. Updating from release 37 is recommended.

What was wrong

The new release gate could start the game's next frame too late to satisfy
the deep pipeline's minimum queue age. OFXR then repeated an older image
for a display slot. The feedback controller counted unwritten images but
missed these age-related holds, so a two-slot cycle could remain stuck at
three slots. This was reproduced with the shipped release 36 and 37 DLLs.

Changes

• Reserve the deep interpolation pipeline's required age slot when choosing
  where to release the application. Allow an additional slot of lead when
  rendering takes more than one display period, preserving the full 2X
  rendering budget.
• Include age-related holds in pacing feedback, once per affected group.
  Before moving release later, require both GPU readiness and sufficient
  queue age. Preserve the required age slot through cooldown and restarts.
• Count missed slots when the next group has not arrived yet, even if its
  images are fully written by their eventual presentation. This fixes the
  related regression under slower CPU workloads in shallow interpolation,
  extrapolation, and 3X as well.
• Keep shallow interpolation, real-first extrapolation, and 3X release
  bounds intact. SteamVR continues to use its existing pacing.
• Extend flight-recorder event 802 with separate age-hold and late-arrival counts.
• Add sustained-cadence regression tests with fast and slower application
  workloads, shallow/deep pipelines, D3D11 admission, extrapolation, 3X,
  and presenter restart. These check display slots and elapsed time;
  release 37's tests checked progress but missed the throughput loss.

Native DLSS FG and the Preset A / Performance Preset C selector are retained.
Changing the NVIDIA model preset still requires restarting the game.

Validation

The new regression test rejects the shipped release 37 DLL at its cadence
assertion and passes with this release. In the same D3D12 2X/deep test with
a simulated 100 Hz runtime, a 2 ms application workload, and 330 measured
application frames after warmup:

Build	Application FPS	Runtime display slots (660 expected)	Synthetic images released
37	32.2	983	330
38	47.8	660	330

The slower 14 ms workload also sustained 47.8 application FPS. The test
uses small FidelityFX/WARP images to isolate the common presenter; these
numbers are not a native DLSS FG game benchmark.

The native-enabled Windows x64 Release build passed 130 automated tests:
ten cadence scenarios, the controller tests, and 119 compatibility checks.
Native DLSS FG correctness tests also passed under Preset A and Preset C.

The regression tests use a simulated OpenXR runtime and the shared presenter
path. They do not establish performance or headset comfort in the reporter's
game; the reporter's runtime and flight log were unavailable.

Package and installation

The Windows x64 ZIP includes the tray, OpenXR and Vulkan layers, benchmark,
production NVIDIA DLSS-G runtime, documentation, and licenses. The bundled
NVIDIA runtime is unchanged. Preset C's updated model is supplied separately
by the NVIDIA app beta. File checksums are in SHA256SUMS.txt, and a separate
checksum accompanies the ZIP.

Disable OFXR and close games using it before replacing an existing install.
Extract the archive and run OFXRBridgeTray.exe to enable it again.

OFXR Bridge V439 release 37 - adaptive presenter pacing

OFXR Bridge V439, release 37

This release ports upstream V452's adaptive presenter pacing into the native
DLSS FG fork. On non-SteamVR runtimes, OFXR now adjusts when the game starts
its next frame based on whether generated images are actually ready. This
addresses cases where submission counters look healthy but the runtime
receives generated frames before the GPU has finished writing them.

Changes

• Readiness-based pacing in 2X and 3X. OFXR can release the game up to
  one display slot earlier at 2X or two at 3X. It evaluates 30 generated
  groups at a time and uses a cooldown before moving back to reduce latency.
  The learned position survives presenter restarts and is bounded when
  changing the multiplier.
• Safe admission for D3D11 and Vulkan bridges. The release target always
  belongs to an already queued group. This adapts the upstream change to
  avoid waiting for a future submission that the blocked game has not yet
  enqueued. Repeated frames cannot satisfy the sequence gate.
• Support for this fork's extrapolation order. Readiness follows the
  first actual synthetic image even when the real image is submitted first.
• New diagnostics. Flight-recorder event 802 reports release position,
  unwritten and early images, and adjustments. See
  diagnostics.

SteamVR retains its existing pacing and 3X delay. Native DLSS FG and the
Preset A / Performance Preset C selector from release 36 remain available.
Changing the NVIDIA model preset still requires restarting the game.

Based on djules75's V452 presenter fix, commit 006ac8d,
ported selectively rather than replacing the fork with upstream V452.
The package therefore retains the internal V439 identifier.

Validation

• Windows x64 Release build with native DLSS FG enabled.
• 120 automated regression tests passed, including new controller tests,
  D3D12 2X/3X interpolation and extrapolation, D3D11 admission, and a
  SteamVR control that verifies the new controller stays disabled.
• Native DLSS FG correctness tests passed under Preset A and Preset C.

No fresh Galactic Racer race or headset test was completed for this port;
the game-testing connection was unresponsive. The release 36 A/C race
measurements are separate evidence and are not a benchmark of this change.

Package and installation

The Windows x64 archive contains the tray, OpenXR and Vulkan layers,
benchmark, production NVIDIA DLSS-G runtime, documentation, and licenses.
The bundled NVIDIA runtime is unchanged; Preset C's updated model is
supplied separately by the NVIDIA app beta. SHA256SUMS.txt lists packaged
file checksums, and a separate checksum accompanies the ZIP.

Disable OFXR and close games using it before replacing an existing install.
Extract the archive and run OFXRBridgeTray.exe to enable it again.

OFXR Bridge V439 release 36 - DLSS FG Preset C and per-game A/C controls

OFXR Bridge V439, release 36

This release adds per-game selection of NVIDIA DLSS Frame Generation
Preset A and the new performance Preset C, with measurements from actual
Galactic Racer racing in OpenXR Simulator.

Changes

• Select the FG model in OFXR. Open Quality and performance → DLSS
  Frame Generation model → Choose game executable, then select
  Preset A (standard), Preset C (performance), or Game default.
  The selected executable survives tray restarts. Preset C requires the
  updated NVIDIA app beta FG runtime and a compatible driver.
• Preserve other NVIDIA settings. OFXR uses NVIDIA's public per-game
  profile interface and verifies its writes. Game default removes the two
  FG overrides; other profile settings are preserved. A global NVIDIA app
  override can still apply, and a game profile can cover several executables.
• Command-line control for repeatable comparisons. Run
  OFXRBridgeTray.exe --dlssg-preset A|C|default|status "full game.exe path".
• Better preset diagnostics and testing. Verbose NGX logging retains
  runtime and effective-preset messages when the game allows OFXR's logging
  callback. The new scripts/test-dlssg-preset.py compares A/C using an
  isolated temporary NVIDIA profile and retains its results and logs.

Restart required

Restart the game after changing A/C. NVIDIA caches the model within the
game process; changing the driver profile and recreating OFXR's FG feature
did not switch the active model in our test. Turning a controller upside
down still opens OFXR's existing panel, but does not provide a live A/C
toggle. FG resolution and the NVIDIA model preset remain separate settings.

Galactic Racer race results

Development-build measurements used Tatooine / King of the Racers with
the game's built-in autopilot, separate fresh game processes, an RTX 5090,
driver 617.42, NVIDIA FG runtime 310.9.16, and OpenXR Simulator at 90 Hz.
Both runs used 3004×3004 per eye, 100% native FG resolution, forced 2X,
shared stereo, and camera fit off. After warmup, each sample lasted 30 seconds.

Preset	Median stereo FG GPU time	Rendered application FPS
A	1.977 ms	45.0
C	1.180 ms	45.0

Preset C reduced measured FG GPU time by 40.3% (0.797 ms). This is GPU
headroom, not a measured overall FPS increase: 90 Hz / 2X pacing held rendered
FPS at 45. Both samples contained 1,355 GPU spans, continuously advancing
vehicle positions, active DLSS guides, and no reported OFXR control or guide
publication errors. These were separate race segments rather than identical
replays; the desktop mirror changed to fullscreen before the A sample.

Native correctness tests passed under both presets, and an isolated profile
test verified C → A → default → C while preserving an unrelated setting.
Image quality remains scene dependent; recorded replay tests showed a
performance/quality tradeoff. These simulator measurements do not establish
moving-head headset comfort or full-race visual quality.

See setup, verification, and detailed measurements.

Package and installation

The Windows x64 archive contains the tray, OpenXR and Vulkan layers,
benchmark, production NVIDIA DLSS-G runtime, documentation, and licenses.
The bundled SDK runtime is unchanged; the new Preset C model is supplied
by NVIDIA's app beta update. OpenXR Simulator is a separate project and is
not included. SHA256SUMS.txt lists the packaged files' checksums, and a
separate checksum accompanies the ZIP.

Disable OFXR and close games using it before replacing an existing install.
Extract the archive and run OFXRBridgeTray.exe to enable it again. For
Galactic Racer, select Griffin/Binaries/Win64/SWGR-Win64-Shipping.exe as
the game executable, choose the preset, and restart the game.

OFXR Bridge V439 release 35 - clearer DLSS diagnostics and opposite-hand controls

OFXR Bridge V439, release 35

This release adds clearer DLSS diagnostics, an optical-flow-only fallback,
and controls on the hand opposite the options panel.

Changes

• Hold the left controller upside down; select with the right. The
  right thumbstick navigates and changes options, and holding the right
  trigger applies them. Opening the panel on the right controller uses
  the left controller's controls instead.
• DLSS warnings explain what happened. Repeated DLSS evaluations now
  report no new frame data separately from invalid guides or broken frame
  history. Help text explains that menus and loading screens can pause DLSS.
  Size mismatches show the latest DLSS output and requested eye-image sizes.
• Optical flow only. Select Method: OFXR, then Mode: optical flow
  only in the headset, or its entry under Frame generation method in
  the tray. This bypasses game motion vectors when they cause artifacts,
  without requiring FoV changes. The setting survives restarts and stays
  synchronized between the headset and tray. Switching back to interpolate
  or hybrid enables game vectors again. Native DLSS Frame Generation still
  requires game guides.
• Clearer vector statistics. The panel says how many checked pairs
  accepted the guides. Acceptance does not establish that the motion field
  is visually correct for the displayed eye.
• Alternating-eye history. Array swapchains now retain the intervening
  raw DLSS evaluation needed by the existing conditional cross-eye motion
  correction, matching the separate-eye swapchain path.

Using the fallback

Interpolation modes can switch live from the headset. Entering or leaving
extrapolation still requires a game restart. Tray changes take effect at the
next game start. For missing vectors, first check gameplay with DLSS upscaling
enabled; menus may stop publishing the guides even when racing works.

The Control artifact report still needs a game capture to verify its cause
and the visual effect of the history correction. This release does not claim
to fix every VR mod's motion-vector convention.

Validation and package

Targeted checks cover panel/controller behavior, settings persistence,
benchmark labels, the public API, and D3D12 guide pairing and correction.
The Windows x64 archive includes the tray app, OpenXR and Vulkan layers,
benchmark, production NVIDIA DLSS-G runtime, documentation, and licenses.
SHA256SUMS.txt lists the packaged files' checksums.

Disable OFXR and close games using it before replacing an existing install.
Extract the archive and run OFXRBridgeTray.exe to enable it again.

OFXR Bridge V439 release 34 - the hybrid keeps a close character's leading edge

OFXR Bridge V439, release 34: the hybrid keeps a close character's leading edge

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• The hybrid keeps a close character's leading edge. OFXR's hybrid
  (DLSS vectors + FidelityFX flow) doubled a third-person character under
  a turning camera along the edge she moved towards: the error maps put
  it beside her, on the background she was covering. In the vectors
  branch the solve from such a pixel alternates between her and the
  background and ends on the background, whose previous-frame sample was
  then shown across the whole band, although her edge already covers half
  of it at the generated instant. That branch now looks for the covering
  surface as well, with the same two-start solve the uncovering edge
  already used, and shows it where it is visible in both frames; and two
  surfaces are told apart from a disagreement of a twentieth instead of a
  tenth. On Stellar Blade's heroine (the replay's region score over her
  head, four steady pairs): 6.71 to 6.61, the worst pair 7.21 to 7.04,
  every pair better on the whole frame too; native DLSS Frame Generation
  scores 5.54 there. No measurable GPU cost.
• Enable and Disable. The tray's "Arm bridge until manual disarm" /
  "Disarm bridge" entry is two entries, Enable and Disable, with a
  check on the one that holds; the state line, tooltip and balloons say
  enabled and disabled.
• Tests. 119 of 119 pass. The replay's saved images
  (XRFG_TEST_REPLAY_SAVE) had red and blue swapped for BGRA captures;
  fixed. A vector-map switch (XRFG_TEST_HYBRID_VARIANT=8) returns the
  vectors branch's solved vectors and endpoint validity per pixel for the
  replay to read back.

From release 33

• 3X takes the presenter where its synthetics bunch. A 3X session the
  layer serves inline hands the runtime three frames per game frame: the
  first synthetic, the second right after it (the second cycle takes the
  wait the runtime already held), and the real frame a period later. On a
  runtime that does not pace its waits the two synthetics land in one
  scanout window and the compositor keeps one of them, so the headset saw
  two frames of every three. The bunched-frame check that takes the
  presenter measured only the gap after the second synthetic, read a
  well-spaced pair and never fired: Stellar Blade at 3X on the OpenXR
  Simulator stayed inline for a whole 91 s session. It now reads a 3X pair
  by the shorter of its two gaps. The same session on this layer takes the
  presenter ten seconds in and shows RATES_PLACEHOLDER. 2X and the
  automatic multiplier are unchanged; a new call-chain test
  (xrfg_layer_triple_frame_gen_paced_inline) holds the promotion on a
  fake runtime that paces its waits.
• Stellar Blade in play at 3X and on the automatic multiplier, the
  same street, orbit and forced stalls as release 32's three-method run:
  the automatic multiplier began at 2X on the presenter, chose 3X at 17.5 s
  and ran 30 real and 60 generated frames a second with no repeats in the
  steady stretch, every stall-storm pair over the cut shown as its real
  frame; 3X's 50 ms pairs against a 33 ms median (1.5 times, under the cut)
  generated cleanly. The building notes have the rows.
• Tests. 119 of 119 pass.

From release 32

• The camera fit measures the whole motion. With DLSS Frame
  Generation camera motion on, the layer fits the camera's motion to
  each pair's vectors on the GPU and hands the result to the next pair,
  which packs its vectors less that camera's flow for NGX. The fit was
  reading the vectors as packed, that is after the subtraction, so it
  measured the motion left over and handed that on as the camera's motion
  entire. Live, a steady turn alternated pair by pair between the whole
  turn and nothing (a 67% Stellar Blade decision log: 3.8 degrees, 0.02,
  3.8, 3.8, 0.04), and every other pair reached NGX with whole vectors and
  near-identity matrices. The fit now puts the subtracted flow back before
  fitting; replayed on the forced-hitch capture, a pair's own fit equals
  the one it was handed to three decimals, at 67% and at 100%. The 67%
  ghosting that release 31 described was measured with the alternating
  fit and is to be re-measured; until then camera motion stays for 100%
  only.
• Bunched frames are not hitches. Release 31's hitch rule, keyed on
  the frames' arrival where a game gives no DLSS frame time, took a long
  gap followed by a short one for a stall and repeated a frame. Hellblade
  II at 44 frames a second on the Meta XR Simulator got 78 such repeats in
  a minute, 39 of the 46 after loading with a short gap right after the
  long one: frames arriving in a bunch, evenly stepped in content. A stall
  leaves the pair after the late frame its normal gap, so that pair is now
  skipped only when its own gap is not short (under three quarters of the
  median); the flight log writes 779 for the pairs let through. The same
  run on this layer: 29 skips and 189 let through in 98
  seconds. Games with a DLSS frame time (777) are unchanged.
• The panel says when a method could not start. Atomic Heart under
  UEVR on the simulator initialises NGX before the layer loads and ships
  no nvngx_dlssg.dll on its DLSS plugin's path, so native DLSS Frame
  Generation cannot initialise there and nothing is generated, by design
  (no silent fallback). The panel showed "Waiting for frames to generate
  from" for it; it now says "This method could not start here: pick
  another on the Method row", and the Method row switches in the running
  session.
• Six more Unreal titles under UEVR on the simulator with native DLSS
  Frame Generation selected: RoboCop: Rogue City, Hellblade II and Clair
  Obscur: Expedition 33 (which ran this time) at 45 real and 45 generated
  a second on the presenter, Black Myth: Wukong still compiling its
  shaders, Atomic Heart as above, and Trepang2 still without a back buffer
  for UEVR.
• Tests. 118 of 118 pass.

From release 31

• A pair spanning a game hitch is shown as its real frame, whatever the
  method. Release 30 gave native DLSS Frame Generation this rule; OFXR's
  own hybrid turned out to want it more. Under the same forced-hitch
  recipe in Stellar Blade (the process suspended 25 ms three times in a
  capture), the hybrid drew two half-transparent copies of the character
  side by side on a 50 ms pair, body and all, where NGX had left her face
  translucent. So the rule now sits ahead of every method: over 1.55 times
  the median of the eight pairs before, and at least six milliseconds over
  it, the pair is not generated and the real frame is shown, one repeated
  frame where the game hitched anyway. The step it judges is the game's own
  frame time where the game gives DLSS one, since that is the step that
  doubles (an engine samples its delta time at the start of a frame, so a
  stall during one frame shows in the next frame's step); without a guide
  it is the frames' arrival, taken one pair later for the same reason. A
  first build keyed on arrival alone and skipped the pair before the jump;
  the forced-hitch recipe caught it. XRFG_HITCH_SKIP=0 in the game's
  environment turns it off. Confirmed live on the hybrid and on native
  generation with the same wide recipe (see the notes).
• The in-headset panel's controls, worked row by row. Every row was
  driven live on the Meta XR Simulator from both start states: 2X to 3X,
  the method switched in the running session, flow preset and scale, both
  ways, the mode, the resolution, camera motion, the buffering and pause
  all applied, wrote the runtime ini and were in the tray's settings within
  the run. Three changes from it: a thumb rolling from one stick direction
  to another without passing the centre is a new press (it was ignored
  until a release); the trigger applies a staged choice once it has been
  held for 400 ms, once per press, and the staged line says "hold the
  trigger to apply", so a trigger pull in play with the controller turned
  over cannot change a setting; and the tray's balloon for a change made
  from the headset names it ("Mode: hybrid -> extrapolate"), with a
  headset-change line in tray-lifecycle.log. The last two are the
  answer to a report of double images on a second start that deleting
  %LOCALAPPDATA%\OFXR Bridge cleared: nothing in that folder is read
  differently on a second start, and a setting adopted from the headset
  into tray.ini is the one thing in it that makes a second run differ.
• Tests. 118 of 118 pass; the navigator test covers the hold, the
  once-per-press and the roll.

From release 30

• Native DLSS Frame Generation shows the real frame on a pair that spans
  a game hitch. At a doubled step - a 50 ms frame between 27 ms ones -
  NGX leaves a third-person character half-transparent for the one
  generated frame, with whatever passes behind her showing through.
  Measured live in Stellar Blade with forced hitches (the process
  suspended 25 ms three times in a capture, then 117 times over a wide
  run): it is NGX at that step size. The game's own DLSS-G library
  (310.1.0) and the newer one (310.9.1) both show it on a share of such
  pairs, the shared side-by-side feature less oft...

OFXR Bridge V439 release 33 - 3X takes the presenter where its synthetics bunch

OFXR Bridge V439, release 33: 3X takes the presenter where its synthetics bunch

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• 3X takes the presenter where its synthetics bunch. A 3X session the
  layer serves inline hands the runtime three frames per game frame: the
  first synthetic, the second right after it (the second cycle takes the
  wait the runtime already held), and the real frame a period later. On a
  runtime that does not pace its waits the two synthetics land in one
  scanout window and the compositor keeps one of them, so the headset saw
  two frames of every three. The bunched-frame check that takes the
  presenter measured only the gap after the second synthetic, read a
  well-spaced pair and never fired: Stellar Blade at 3X on the OpenXR
  Simulator stayed inline for a whole 91 s session. It now reads a 3X pair
  by the shorter of its two gaps. The same session on this layer takes the
  presenter ten seconds in and shows RATES_PLACEHOLDER. 2X and the
  automatic multiplier are unchanged; a new call-chain test
  (xrfg_layer_triple_frame_gen_paced_inline) holds the promotion on a
  fake runtime that paces its waits.
• Stellar Blade in play at 3X and on the automatic multiplier, the
  same street, orbit and forced stalls as release 32's three-method run:
  the automatic multiplier began at 2X on the presenter, chose 3X at 17.5 s
  and ran 30 real and 60 generated frames a second with no repeats in the
  steady stretch, every stall-storm pair over the cut shown as its real
  frame; 3X's 50 ms pairs against a 33 ms median (1.5 times, under the cut)
  generated cleanly. The building notes have the rows.
• Tests. 119 of 119 pass.

From release 32

• The camera fit measures the whole motion. With DLSS Frame
  Generation camera motion on, the layer fits the camera's motion to
  each pair's vectors on the GPU and hands the result to the next pair,
  which packs its vectors less that camera's flow for NGX. The fit was
  reading the vectors as packed, that is after the subtraction, so it
  measured the motion left over and handed that on as the camera's motion
  entire. Live, a steady turn alternated pair by pair between the whole
  turn and nothing (a 67% Stellar Blade decision log: 3.8 degrees, 0.02,
  3.8, 3.8, 0.04), and every other pair reached NGX with whole vectors and
  near-identity matrices. The fit now puts the subtracted flow back before
  fitting; replayed on the forced-hitch capture, a pair's own fit equals
  the one it was handed to three decimals, at 67% and at 100%. The 67%
  ghosting that release 31 described was measured with the alternating
  fit and is to be re-measured; until then camera motion stays for 100%
  only.
• Bunched frames are not hitches. Release 31's hitch rule, keyed on
  the frames' arrival where a game gives no DLSS frame time, took a long
  gap followed by a short one for a stall and repeated a frame. Hellblade
  II at 44 frames a second on the Meta XR Simulator got 78 such repeats in
  a minute, 39 of the 46 after loading with a short gap right after the
  long one: frames arriving in a bunch, evenly stepped in content. A stall
  leaves the pair after the late frame its normal gap, so that pair is now
  skipped only when its own gap is not short (under three quarters of the
  median); the flight log writes 779 for the pairs let through. The same
  run on this layer: 29 skips and 189 let through in 98
  seconds. Games with a DLSS frame time (777) are unchanged.
• The panel says when a method could not start. Atomic Heart under
  UEVR on the simulator initialises NGX before the layer loads and ships
  no nvngx_dlssg.dll on its DLSS plugin's path, so native DLSS Frame
  Generation cannot initialise there and nothing is generated, by design
  (no silent fallback). The panel showed "Waiting for frames to generate
  from" for it; it now says "This method could not start here: pick
  another on the Method row", and the Method row switches in the running
  session.
• Six more Unreal titles under UEVR on the simulator with native DLSS
  Frame Generation selected: RoboCop: Rogue City, Hellblade II and Clair
  Obscur: Expedition 33 (which ran this time) at 45 real and 45 generated
  a second on the presenter, Black Myth: Wukong still compiling its
  shaders, Atomic Heart as above, and Trepang2 still without a back buffer
  for UEVR.
• Tests. 118 of 118 pass.

From release 31

• A pair spanning a game hitch is shown as its real frame, whatever the
  method. Release 30 gave native DLSS Frame Generation this rule; OFXR's
  own hybrid turned out to want it more. Under the same forced-hitch
  recipe in Stellar Blade (the process suspended 25 ms three times in a
  capture), the hybrid drew two half-transparent copies of the character
  side by side on a 50 ms pair, body and all, where NGX had left her face
  translucent. So the rule now sits ahead of every method: over 1.55 times
  the median of the eight pairs before, and at least six milliseconds over
  it, the pair is not generated and the real frame is shown, one repeated
  frame where the game hitched anyway. The step it judges is the game's own
  frame time where the game gives DLSS one, since that is the step that
  doubles (an engine samples its delta time at the start of a frame, so a
  stall during one frame shows in the next frame's step); without a guide
  it is the frames' arrival, taken one pair later for the same reason. A
  first build keyed on arrival alone and skipped the pair before the jump;
  the forced-hitch recipe caught it. XRFG_HITCH_SKIP=0 in the game's
  environment turns it off. Confirmed live on the hybrid and on native
  generation with the same wide recipe (see the notes).
• The in-headset panel's controls, worked row by row. Every row was
  driven live on the Meta XR Simulator from both start states: 2X to 3X,
  the method switched in the running session, flow preset and scale, both
  ways, the mode, the resolution, camera motion, the buffering and pause
  all applied, wrote the runtime ini and were in the tray's settings within
  the run. Three changes from it: a thumb rolling from one stick direction
  to another without passing the centre is a new press (it was ignored
  until a release); the trigger applies a staged choice once it has been
  held for 400 ms, once per press, and the staged line says "hold the
  trigger to apply", so a trigger pull in play with the controller turned
  over cannot change a setting; and the tray's balloon for a change made
  from the headset names it ("Mode: hybrid -> extrapolate"), with a
  headset-change line in tray-lifecycle.log. The last two are the
  answer to a report of double images on a second start that deleting
  %LOCALAPPDATA%\OFXR Bridge cleared: nothing in that folder is read
  differently on a second start, and a setting adopted from the headset
  into tray.ini is the one thing in it that makes a second run differ.
• Tests. 118 of 118 pass; the navigator test covers the hold, the
  once-per-press and the roll.

From release 30

• Native DLSS Frame Generation shows the real frame on a pair that spans
  a game hitch. At a doubled step - a 50 ms frame between 27 ms ones -
  NGX leaves a third-person character half-transparent for the one
  generated frame, with whatever passes behind her showing through.
  Measured live in Stellar Blade with forced hitches (the process
  suspended 25 ms three times in a capture, then 117 times over a wide
  run): it is NGX at that step size. The game's own DLSS-G library
  (310.1.0) and the newer one (310.9.1) both show it on a share of such
  pairs, the shared side-by-side feature less often than a feature per
  eye, and no setting removes it. So a pair whose frame time runs over
  1.55 times the median of the eight before it is not generated: the real
  frame is shown instead, one repeated frame where the game hitched
  anyway. Confirmed on the same wide run: 53 such pairs skipped, every
  captured hitch pair exactly the real frame, every other pair generated
  as before, a 1.4-times pair and the pairs right after a hitch included.
  XRFG_NATIVE_DLSSG_HITCH_SKIP=0 in the game's environment turns it off.
  Leave DLSS Frame Generation camera motion off for such games; its
  feature per eye ghosts more of these pairs. The camera-flag change
  release 29 carried briefly is gone; it did not help.
• A test-only switch keeps a session inline (XRFG_TEST_INLINE_ONLY=1)
  on the runtimes where release 29 gave single-thread frame loops the
  presenter, so the inline rules can still be measured there. Deep Rock
  Galactic held inline: 3X at 12.7 s by the frame's-own-time rule, 2X back
  at 17 s once 3X had cost a slot, and held.
• Checked on this build: FlatOut 4 VR for 318 s on the D3D11 presenter
  the Meta rule gives it (44.6 + 44.5 a second, 38 repeats in 27,228 shown,
  no quarantine); Deep Rock Galactic on native DLSS FG on the presenter
  (44.9 + 44.9, no quarantine). A note for anyone testing UEVR games on the
  Meta XR Simulator: launch with -nohmd, or the game's own OpenXR plugin
  may open an instance before UEVR's and the simulator's input plugin
  aborts on the second; that was two crashes today, and not the layer.
• Tests. 118 of 118 pass.

...

OFXR Bridge V439 release 32 - the camera fit measures the whole motion, and bunched frames are not hitches

OFXR Bridge V439, release 32: the camera fit measures the whole motion, and bunched frames are not hitches

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• The camera fit measures the whole motion. With DLSS Frame
  Generation camera motion on, the layer fits the camera's motion to
  each pair's vectors on the GPU and hands the result to the next pair,
  which packs its vectors less that camera's flow for NGX. The fit was
  reading the vectors as packed, that is after the subtraction, so it
  measured the motion left over and handed that on as the camera's motion
  entire. Live, a steady turn alternated pair by pair between the whole
  turn and nothing (a 67% Stellar Blade decision log: 3.8 degrees, 0.02,
  3.8, 3.8, 0.04), and every other pair reached NGX with whole vectors and
  near-identity matrices. The fit now puts the subtracted flow back before
  fitting; replayed on the forced-hitch capture, a pair's own fit equals
  the one it was handed to three decimals, at 67% and at 100%. The 67%
  ghosting that release 31 described was measured with the alternating
  fit and is to be re-measured; until then camera motion stays for 100%
  only.
• Bunched frames are not hitches. Release 31's hitch rule, keyed on
  the frames' arrival where a game gives no DLSS frame time, took a long
  gap followed by a short one for a stall and repeated a frame. Hellblade
  II at 44 frames a second on the Meta XR Simulator got 78 such repeats in
  a minute, 39 of the 46 after loading with a short gap right after the
  long one: frames arriving in a bunch, evenly stepped in content. A stall
  leaves the pair after the late frame its normal gap, so that pair is now
  skipped only when its own gap is not short (under three quarters of the
  median); the flight log writes 779 for the pairs let through. The same
  run on this layer: 29 skips and 189 let through in 98
  seconds. Games with a DLSS frame time (777) are unchanged.
• The panel says when a method could not start. Atomic Heart under
  UEVR on the simulator initialises NGX before the layer loads and ships
  no nvngx_dlssg.dll on its DLSS plugin's path, so native DLSS Frame
  Generation cannot initialise there and nothing is generated, by design
  (no silent fallback). The panel showed "Waiting for frames to generate
  from" for it; it now says "This method could not start here: pick
  another on the Method row", and the Method row switches in the running
  session.
• Six more Unreal titles under UEVR on the simulator with native DLSS
  Frame Generation selected: RoboCop: Rogue City, Hellblade II and Clair
  Obscur: Expedition 33 (which ran this time) at 45 real and 45 generated
  a second on the presenter, Black Myth: Wukong still compiling its
  shaders, Atomic Heart as above, and Trepang2 still without a back buffer
  for UEVR.
• Tests. 118 of 118 pass.

From release 31

• A pair spanning a game hitch is shown as its real frame, whatever the
  method. Release 30 gave native DLSS Frame Generation this rule; OFXR's
  own hybrid turned out to want it more. Under the same forced-hitch
  recipe in Stellar Blade (the process suspended 25 ms three times in a
  capture), the hybrid drew two half-transparent copies of the character
  side by side on a 50 ms pair, body and all, where NGX had left her face
  translucent. So the rule now sits ahead of every method: over 1.55 times
  the median of the eight pairs before, and at least six milliseconds over
  it, the pair is not generated and the real frame is shown, one repeated
  frame where the game hitched anyway. The step it judges is the game's own
  frame time where the game gives DLSS one, since that is the step that
  doubles (an engine samples its delta time at the start of a frame, so a
  stall during one frame shows in the next frame's step); without a guide
  it is the frames' arrival, taken one pair later for the same reason. A
  first build keyed on arrival alone and skipped the pair before the jump;
  the forced-hitch recipe caught it. XRFG_HITCH_SKIP=0 in the game's
  environment turns it off. Confirmed live on the hybrid and on native
  generation with the same wide recipe (see the notes).
• The in-headset panel's controls, worked row by row. Every row was
  driven live on the Meta XR Simulator from both start states: 2X to 3X,
  the method switched in the running session, flow preset and scale, both
  ways, the mode, the resolution, camera motion, the buffering and pause
  all applied, wrote the runtime ini and were in the tray's settings within
  the run. Three changes from it: a thumb rolling from one stick direction
  to another without passing the centre is a new press (it was ignored
  until a release); the trigger applies a staged choice once it has been
  held for 400 ms, once per press, and the staged line says "hold the
  trigger to apply", so a trigger pull in play with the controller turned
  over cannot change a setting; and the tray's balloon for a change made
  from the headset names it ("Mode: hybrid -> extrapolate"), with a
  headset-change line in tray-lifecycle.log. The last two are the
  answer to a report of double images on a second start that deleting
  %LOCALAPPDATA%\OFXR Bridge cleared: nothing in that folder is read
  differently on a second start, and a setting adopted from the headset
  into tray.ini is the one thing in it that makes a second run differ.
• Tests. 118 of 118 pass; the navigator test covers the hold, the
  once-per-press and the roll.

From release 30

• Native DLSS Frame Generation shows the real frame on a pair that spans
  a game hitch. At a doubled step - a 50 ms frame between 27 ms ones -
  NGX leaves a third-person character half-transparent for the one
  generated frame, with whatever passes behind her showing through.
  Measured live in Stellar Blade with forced hitches (the process
  suspended 25 ms three times in a capture, then 117 times over a wide
  run): it is NGX at that step size. The game's own DLSS-G library
  (310.1.0) and the newer one (310.9.1) both show it on a share of such
  pairs, the shared side-by-side feature less often than a feature per
  eye, and no setting removes it. So a pair whose frame time runs over
  1.55 times the median of the eight before it is not generated: the real
  frame is shown instead, one repeated frame where the game hitched
  anyway. Confirmed on the same wide run: 53 such pairs skipped, every
  captured hitch pair exactly the real frame, every other pair generated
  as before, a 1.4-times pair and the pairs right after a hitch included.
  XRFG_NATIVE_DLSSG_HITCH_SKIP=0 in the game's environment turns it off.
  Leave DLSS Frame Generation camera motion off for such games; its
  feature per eye ghosts more of these pairs. The camera-flag change
  release 29 carried briefly is gone; it did not help.
• A test-only switch keeps a session inline (XRFG_TEST_INLINE_ONLY=1)
  on the runtimes where release 29 gave single-thread frame loops the
  presenter, so the inline rules can still be measured there. Deep Rock
  Galactic held inline: 3X at 12.7 s by the frame's-own-time rule, 2X back
  at 17 s once 3X had cost a slot, and held.
• Checked on this build: FlatOut 4 VR for 318 s on the D3D11 presenter
  the Meta rule gives it (44.6 + 44.5 a second, 38 repeats in 27,228 shown,
  no quarantine); Deep Rock Galactic on native DLSS FG on the presenter
  (44.9 + 44.9, no quarantine). A note for anyone testing UEVR games on the
  Meta XR Simulator: launch with -nohmd, or the game's own OpenXR plugin
  may open an instance before UEVR's and the simulator's input plugin
  aborts on the second; that was two crashes today, and not the layer.
• Tests. 118 of 118 pass.

From release 29

• A game whose frame loop runs on one thread takes the presenter on
  Meta's runtime and its simulator. Many native titles and UEVR games
  call xrWaitFrame and xrEndFrame on one thread without overlap, and on
  Meta's runtimes the layer served them inline: every synthetic frame cost
  the game's own thread a wait for the next display slot and a submission,
  so a frame a little over one period took three slots at 2X instead of
  two. Deep Rock Galactic under UEVR on the Meta XR Simulator ran 30 a
  second that way, two shown frames in three, with 10 ms of each frame
  spent waiting in the runtime. The rule Virtual Desktop already had now
  applies to Meta's runtimes as well: the presenter from the first
  generating frame, its submissions on their own thread while the game
  renders. Live, the presenter started nine seconds into Deep Rock
  Galactic, and at UEVR scale 1.0 the game ran 45 a second at exactly two
  periods, 90 submissions a second with no repeat, where inline it had run
  39.7; at scale 1.9 it ran 36 against 30. A split loop (the wait on one
  thread, the submission on another) on Meta's runtimes still goes by the
  bunched-pair measurement, as on any other runtime.
• Automatic 2X or 3X checks itself where a session stays inline
  (Pimax, a split frame loop on Virtual Desktop). There a third frame
  costs the game's thread another wait and submission a frame, and in
  Deep Rock Galactic inline that turned 33 ms frames into 44 ms ones: three
  shown frames in four at 22.5 a second agains...

OFXR Bridge V439 release 31 - the hitch rule for every method, and the panel's controls worked row by row

OFXR Bridge V439, release 31: the hitch rule for every method, and the panel's controls worked row by row

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• A pair spanning a game hitch is shown as its real frame, whatever the
  method. Release 30 gave native DLSS Frame Generation this rule; OFXR's
  own hybrid turned out to want it more. Under the same forced-hitch
  recipe in Stellar Blade (the process suspended 25 ms three times in a
  capture), the hybrid drew two half-transparent copies of the character
  side by side on a 50 ms pair, body and all, where NGX had left her face
  translucent. So the rule now sits ahead of every method: over 1.55 times
  the median of the eight pairs before, and at least six milliseconds over
  it, the pair is not generated and the real frame is shown, one repeated
  frame where the game hitched anyway. The step it judges is the game's own
  frame time where the game gives DLSS one, since that is the step that
  doubles (an engine samples its delta time at the start of a frame, so a
  stall during one frame shows in the next frame's step); without a guide
  it is the frames' arrival, taken one pair later for the same reason. A
  first build keyed on arrival alone and skipped the pair before the jump;
  the forced-hitch recipe caught it. XRFG_HITCH_SKIP=0 in the game's
  environment turns it off. Confirmed live on the hybrid and on native
  generation with the same wide recipe (see the notes).
• The in-headset panel's controls, worked row by row. Every row was
  driven live on the Meta XR Simulator from both start states: 2X to 3X,
  the method switched in the running session, flow preset and scale, both
  ways, the mode, the resolution, camera motion, the buffering and pause
  all applied, wrote the runtime ini and were in the tray's settings within
  the run. Three changes from it: a thumb rolling from one stick direction
  to another without passing the centre is a new press (it was ignored
  until a release); the trigger applies a staged choice once it has been
  held for 400 ms, once per press, and the staged line says "hold the
  trigger to apply", so a trigger pull in play with the controller turned
  over cannot change a setting; and the tray's balloon for a change made
  from the headset names it ("Mode: hybrid -> extrapolate"), with a
  headset-change line in tray-lifecycle.log. The last two are the
  answer to a report of double images on a second start that deleting
  %LOCALAPPDATA%\OFXR Bridge cleared: nothing in that folder is read
  differently on a second start, and a setting adopted from the headset
  into tray.ini is the one thing in it that makes a second run differ.
• Tests. 118 of 118 pass; the navigator test covers the hold, the
  once-per-press and the roll.

From release 30

• Native DLSS Frame Generation shows the real frame on a pair that spans
  a game hitch. At a doubled step - a 50 ms frame between 27 ms ones -
  NGX leaves a third-person character half-transparent for the one
  generated frame, with whatever passes behind her showing through.
  Measured live in Stellar Blade with forced hitches (the process
  suspended 25 ms three times in a capture, then 117 times over a wide
  run): it is NGX at that step size. The game's own DLSS-G library
  (310.1.0) and the newer one (310.9.1) both show it on a share of such
  pairs, the shared side-by-side feature less often than a feature per
  eye, and no setting removes it. So a pair whose frame time runs over
  1.55 times the median of the eight before it is not generated: the real
  frame is shown instead, one repeated frame where the game hitched
  anyway. Confirmed on the same wide run: 53 such pairs skipped, every
  captured hitch pair exactly the real frame, every other pair generated
  as before, a 1.4-times pair and the pairs right after a hitch included.
  XRFG_NATIVE_DLSSG_HITCH_SKIP=0 in the game's environment turns it off.
  Leave DLSS Frame Generation camera motion off for such games; its
  feature per eye ghosts more of these pairs. The camera-flag change
  release 29 carried briefly is gone; it did not help.
• A test-only switch keeps a session inline (XRFG_TEST_INLINE_ONLY=1)
  on the runtimes where release 29 gave single-thread frame loops the
  presenter, so the inline rules can still be measured there. Deep Rock
  Galactic held inline: 3X at 12.7 s by the frame's-own-time rule, 2X back
  at 17 s once 3X had cost a slot, and held.
• Checked on this build: FlatOut 4 VR for 318 s on the D3D11 presenter
  the Meta rule gives it (44.6 + 44.5 a second, 38 repeats in 27,228 shown,
  no quarantine); Deep Rock Galactic on native DLSS FG on the presenter
  (44.9 + 44.9, no quarantine). A note for anyone testing UEVR games on the
  Meta XR Simulator: launch with -nohmd, or the game's own OpenXR plugin
  may open an instance before UEVR's and the simulator's input plugin
  aborts on the second; that was two crashes today, and not the layer.
• Tests. 118 of 118 pass.

From release 29

• A game whose frame loop runs on one thread takes the presenter on
  Meta's runtime and its simulator. Many native titles and UEVR games
  call xrWaitFrame and xrEndFrame on one thread without overlap, and on
  Meta's runtimes the layer served them inline: every synthetic frame cost
  the game's own thread a wait for the next display slot and a submission,
  so a frame a little over one period took three slots at 2X instead of
  two. Deep Rock Galactic under UEVR on the Meta XR Simulator ran 30 a
  second that way, two shown frames in three, with 10 ms of each frame
  spent waiting in the runtime. The rule Virtual Desktop already had now
  applies to Meta's runtimes as well: the presenter from the first
  generating frame, its submissions on their own thread while the game
  renders. Live, the presenter started nine seconds into Deep Rock
  Galactic, and at UEVR scale 1.0 the game ran 45 a second at exactly two
  periods, 90 submissions a second with no repeat, where inline it had run
  39.7; at scale 1.9 it ran 36 against 30. A split loop (the wait on one
  thread, the submission on another) on Meta's runtimes still goes by the
  bunched-pair measurement, as on any other runtime.
• Automatic 2X or 3X checks itself where a session stays inline
  (Pimax, a split frame loop on Virtual Desktop). There a third frame
  costs the game's thread another wait and submission a frame, and in
  Deep Rock Galactic inline that turned 33 ms frames into 44 ms ones: three
  shown frames in four at 22.5 a second against two in three at 30. Now the
  2X interval is kept when the choice leaves for 3X, and when the 3X
  interval has run over it by 0.6 of a period for two seconds, 2X comes
  back and 3X is not tried again while the scene holds. The short rule
  inline is the frame's own time - the interval less the time blocked in
  the runtime's wait, or the GPU's or the CPU's time if longer - over 1.9
  periods, since the runtime's wait rounds a frame up to whole slots and
  reads as slack; it is the same threshold the presenter's rule implies.
• The hitch-pair ghost with DLSS Frame Generation camera motion is the
  camera option's, and still open. With DLSS Frame Generation camera
  motion on, a pair spanning a game hitch (a 50 ms frame after 27 ms
  ones) can leave the character half-transparent for one generated frame
  while a busy object passes behind her. Tested live in Stellar Blade with
  forced hitches (the process suspended 25 ms three times in a capture):
  it is not the game's DLSS-G library (310.1.0 and 310.9.1 behave the
  same), with the camera's motion off the same pairs keep her solid, and
  keeping NGX's reading of the vectors steady across the dropped pair did
  not help (tried and taken back within this release). Leave the camera's
  motion off for Stellar Blade; the option is off by default. The cuts
  still to run are in docs/BUILDING.md, with a test knob
  (XRFG_TEST_NATIVE_FIT_DROP=0) added for one of them.
• Tests. xrfg_frame_loop_meta_single and xrfg_frame_loop_meta_split
  cover the presenter rule, and xrfg_layer_auto_frames_inline_paced the
  inline check on a fake runtime whose waits are paced to the period grid:
  3X, 2X back when the interval grows by a slot, and no third switch. 118
  of 118 tests pass.

From release 28

• Automatic 2X or 3X works in sessions without the presenter thread
  too (the inline shape: many titles on Virtual Desktop and Pimax, UEVR
  games on the Meta XR Simulator). There the game's threads block in the
  runtime's wait instead of the presenter's holds, and that time is read
  as the game's slack; room to spare also needs the xrEndFrame thread's
  CPU time under 1.85 periods a frame, since a pipelined game's wait can
  overlap its render thread's work. The GPU probe runs on a thread of its
  own once a display period. D3D12 games; the D3D11 and Vulkan bridges
  keep the shape you chose.
• Slower to come down. Coming back to 2X now takes four seconds of
  light frames, going to 3X two seconds of short ones, and more than one
  shown frame in twelve a repeat count...

OFXR Bridge V439 release 30 - native DLSS Frame Generation shows the real frame on a hitch pair

OFXR Bridge V439, release 30: native DLSS Frame Generation shows the real frame on a hitch pair

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• Native DLSS Frame Generation shows the real frame on a pair that spans
  a game hitch. At a doubled step - a 50 ms frame between 27 ms ones -
  NGX leaves a third-person character half-transparent for the one
  generated frame, with whatever passes behind her showing through.
  Measured live in Stellar Blade with forced hitches (the process
  suspended 25 ms three times in a capture, then 117 times over a wide
  run): it is NGX at that step size. The game's own DLSS-G library
  (310.1.0) and the newer one (310.9.1) both show it on a share of such
  pairs, the shared side-by-side feature less often than a feature per
  eye, and no setting removes it. So a pair whose frame time runs over
  1.55 times the median of the eight before it is not generated: the real
  frame is shown instead, one repeated frame where the game hitched
  anyway. Confirmed on the same wide run: 53 such pairs skipped, every
  captured hitch pair exactly the real frame, every other pair generated
  as before, a 1.4-times pair and the pairs right after a hitch included.
  XRFG_NATIVE_DLSSG_HITCH_SKIP=0 in the game's environment turns it off.
  Leave DLSS Frame Generation camera motion off for such games; its
  feature per eye ghosts more of these pairs. The camera-flag change
  release 29 carried briefly is gone; it did not help.
• A test-only switch keeps a session inline (XRFG_TEST_INLINE_ONLY=1)
  on the runtimes where release 29 gave single-thread frame loops the
  presenter, so the inline rules can still be measured there. Deep Rock
  Galactic held inline: 3X at 12.7 s by the frame's-own-time rule, 2X back
  at 17 s once 3X had cost a slot, and held.
• Checked on this build: FlatOut 4 VR for 318 s on the D3D11 presenter
  the Meta rule gives it (44.6 + 44.5 a second, 38 repeats in 27,228 shown,
  no quarantine); Deep Rock Galactic on native DLSS FG on the presenter
  (44.9 + 44.9, no quarantine). A note for anyone testing UEVR games on the
  Meta XR Simulator: launch with -nohmd, or the game's own OpenXR plugin
  may open an instance before UEVR's and the simulator's input plugin
  aborts on the second; that was two crashes today, and not the layer.
• Tests. 118 of 118 pass.

From release 29

• A game whose frame loop runs on one thread takes the presenter on
  Meta's runtime and its simulator. Many native titles and UEVR games
  call xrWaitFrame and xrEndFrame on one thread without overlap, and on
  Meta's runtimes the layer served them inline: every synthetic frame cost
  the game's own thread a wait for the next display slot and a submission,
  so a frame a little over one period took three slots at 2X instead of
  two. Deep Rock Galactic under UEVR on the Meta XR Simulator ran 30 a
  second that way, two shown frames in three, with 10 ms of each frame
  spent waiting in the runtime. The rule Virtual Desktop already had now
  applies to Meta's runtimes as well: the presenter from the first
  generating frame, its submissions on their own thread while the game
  renders. Live, the presenter started nine seconds into Deep Rock
  Galactic, and at UEVR scale 1.0 the game ran 45 a second at exactly two
  periods, 90 submissions a second with no repeat, where inline it had run
  39.7; at scale 1.9 it ran 36 against 30. A split loop (the wait on one
  thread, the submission on another) on Meta's runtimes still goes by the
  bunched-pair measurement, as on any other runtime.
• Automatic 2X or 3X checks itself where a session stays inline
  (Pimax, a split frame loop on Virtual Desktop). There a third frame
  costs the game's thread another wait and submission a frame, and in
  Deep Rock Galactic inline that turned 33 ms frames into 44 ms ones: three
  shown frames in four at 22.5 a second against two in three at 30. Now the
  2X interval is kept when the choice leaves for 3X, and when the 3X
  interval has run over it by 0.6 of a period for two seconds, 2X comes
  back and 3X is not tried again while the scene holds. The short rule
  inline is the frame's own time - the interval less the time blocked in
  the runtime's wait, or the GPU's or the CPU's time if longer - over 1.9
  periods, since the runtime's wait rounds a frame up to whole slots and
  reads as slack; it is the same threshold the presenter's rule implies.
• The hitch-pair ghost with DLSS Frame Generation camera motion is the
  camera option's, and still open. With DLSS Frame Generation camera
  motion on, a pair spanning a game hitch (a 50 ms frame after 27 ms
  ones) can leave the character half-transparent for one generated frame
  while a busy object passes behind her. Tested live in Stellar Blade with
  forced hitches (the process suspended 25 ms three times in a capture):
  it is not the game's DLSS-G library (310.1.0 and 310.9.1 behave the
  same), with the camera's motion off the same pairs keep her solid, and
  keeping NGX's reading of the vectors steady across the dropped pair did
  not help (tried and taken back within this release). Leave the camera's
  motion off for Stellar Blade; the option is off by default. The cuts
  still to run are in docs/BUILDING.md, with a test knob
  (XRFG_TEST_NATIVE_FIT_DROP=0) added for one of them.
• Tests. xrfg_frame_loop_meta_single and xrfg_frame_loop_meta_split
  cover the presenter rule, and xrfg_layer_auto_frames_inline_paced the
  inline check on a fake runtime whose waits are paced to the period grid:
  3X, 2X back when the interval grows by a slot, and no third switch. 118
  of 118 tests pass.

From release 28

• Automatic 2X or 3X works in sessions without the presenter thread
  too (the inline shape: many titles on Virtual Desktop and Pimax, UEVR
  games on the Meta XR Simulator). There the game's threads block in the
  runtime's wait instead of the presenter's holds, and that time is read
  as the game's slack; room to spare also needs the xrEndFrame thread's
  CPU time under 1.85 periods a frame, since a pipelined game's wait can
  overlap its render thread's work. The GPU probe runs on a thread of its
  own once a display period. D3D12 games; the D3D11 and Vulkan bridges
  keep the shape you chose.
• Slower to come down. Coming back to 2X now takes four seconds of
  light frames, going to 3X two seconds of short ones, and more than one
  shown frame in twelve a repeat counts as short. On native DLSS Frame
  Generation in Stellar Blade the first release had come back on a
  two-second light view at the end of an orbit and then sat at 2.06 to 2.4
  periods with 10 to 28% repeats; a late return costs a lower game rate for
  a moment, an early one costs repeats on screen.
  Checked: Deep Rock Galactic under UEVR on the Meta XR Simulator, a
  presenter session this time, sat at its space rig for three hours at 2X
  (2.00 periods, the GPU 21% busy) without a switch; the inline rule is
  covered by its test and still wants a live session.
• Tests. xrfg_layer_auto_frames_inline runs the fake Pimax runtime,
  which stays inline: 3X after 4.2 s of slow frames and no second switch.
  115 of 115 tests pass.

From release 27

• Automatic 2X or 3X. Under Frames shown per game frame the tray now
  offers Automatic ([tray] frames_auto=1, [ofxr] frames_auto=1; the
  panel's Per frame row has it as "auto"). The layer then picks the
  shape live, through the same switch the tray's 3X uses: when the game's
  frame interval has run over 2.15 display periods for two seconds with no
  slack in the layer's waits, which is a game short of half the refresh
  rate repeating frames, it goes to 3X, where the game is paced to a third
  of the rate; when at 3X the game has more than 1.15 periods a frame to
  spare, measured both in the layer's waits and on its GPU, it goes back
  to 2X. Three seconds in a shape before leaving it, four at 3X, every
  condition held for two seconds, so a stall or a loading screen moves
  nothing. This is the answer to stutter in a game that sits between a
  third and a half of the refresh rate, extrapolation included: a 37
  frames-a-second Stellar Blade on a 120 Hz Steam Frame repeated 18% of
  what it showed at 2X. The GPU is read by a timestamp probe on the game's
  queue once a display period, because a GPU-bound game paced to a third
  of the rate has a CPU thread with time to spare and a GPU with none; a
  build without the probe flapped between the shapes every four seconds in
  Stellar Blade. It acts where the layer's presenter thread runs (SteamVR,
  the simulators) in D3D12 games, and on DLSS Frame Generation needs an
  RTX 50; elsewhere the shape you chose stays and the panel says so.
  Live in Stellar Blade on the OpenXR Simulator at the user's UEVR scale
  (3703x3703 per eye, 38 frames a second in the rain city): 3X came five
  seconds into the orbit and held for the whole of it with no repeat, 30
  real and 60 generated frames a second, the GPU read 67% busy at 22 ms a
  frame; the pause menu (12 ms a frame) brought 2X back within six seconds,...

OFXR Bridge V439 release 29 - the presenter for single-thread games on Meta's runtimes, and the automatic choice checks itself inline

OFXR Bridge V439, release 29: the presenter for single-thread games on Meta's runtimes, and the automatic choice checks itself inline

This release comes from the native-dlss-fg branch of
elliotttate/OFXR-Bridge. That
fork builds on djules75/OFXR-Bridge
v0.2.13.1 (V438), which is itself a fork of
tig3rmast3r/OFXR-Bridge.

It adds native NVIDIA DLSS Frame Generation (NGX DLSS-G) as a VR
frame-generation backend beside OFXR's own methods, two OFXR modes of its
own (a DLSS vectors + optical flow hybrid, and SpaceWarp-style
extrapolation), and a benchmark of every mode on your own PC. Native
generation and the new modes are off by default; OFXR's own algorithm
stays the default selection.

New in this release

• A game whose frame loop runs on one thread takes the presenter on
  Meta's runtime and its simulator. Many native titles and UEVR games
  call xrWaitFrame and xrEndFrame on one thread without overlap, and on
  Meta's runtimes the layer served them inline: every synthetic frame cost
  the game's own thread a wait for the next display slot and a submission,
  so a frame a little over one period took three slots at 2X instead of
  two. Deep Rock Galactic under UEVR on the Meta XR Simulator ran 30 a
  second that way, two shown frames in three, with 10 ms of each frame
  spent waiting in the runtime. The rule Virtual Desktop already had now
  applies to Meta's runtimes as well: the presenter from the first
  generating frame, its submissions on their own thread while the game
  renders. Live, the presenter started nine seconds into Deep Rock
  Galactic, and at UEVR scale 1.0 the game ran 45 a second at exactly two
  periods, 90 submissions a second with no repeat, where inline it had run
  39.7; at scale 1.9 it ran 36 against 30. A split loop (the wait on one
  thread, the submission on another) on Meta's runtimes still goes by the
  bunched-pair measurement, as on any other runtime.
• Automatic 2X or 3X checks itself where a session stays inline
  (Pimax, a split frame loop on Virtual Desktop). There a third frame
  costs the game's thread another wait and submission a frame, and in
  Deep Rock Galactic inline that turned 33 ms frames into 44 ms ones: three
  shown frames in four at 22.5 a second against two in three at 30. Now the
  2X interval is kept when the choice leaves for 3X, and when the 3X
  interval has run over it by 0.6 of a period for two seconds, 2X comes
  back and 3X is not tried again while the scene holds. The short rule
  inline is the frame's own time - the interval less the time blocked in
  the runtime's wait, or the GPU's or the CPU's time if longer - over 1.9
  periods, since the runtime's wait rounds a frame up to whole slots and
  reads as slack; it is the same threshold the presenter's rule implies.
• The hitch-pair ghost with DLSS Frame Generation camera motion is the
  camera option's, and still open. With DLSS Frame Generation camera
  motion on, a pair spanning a game hitch (a 50 ms frame after 27 ms
  ones) can leave the character half-transparent for one generated frame
  while a busy object passes behind her. Tested live in Stellar Blade with
  forced hitches (the process suspended 25 ms three times in a capture):
  it is not the game's DLSS-G library (310.1.0 and 310.9.1 behave the
  same), with the camera's motion off the same pairs keep her solid, and
  keeping NGX's reading of the vectors steady across the dropped pair did
  not help (tried and taken back within this release). Leave the camera's
  motion off for Stellar Blade; the option is off by default. The cuts
  still to run are in docs/BUILDING.md, with a test knob
  (XRFG_TEST_NATIVE_FIT_DROP=0) added for one of them.
• Tests. xrfg_frame_loop_meta_single and xrfg_frame_loop_meta_split
  cover the presenter rule, and xrfg_layer_auto_frames_inline_paced the
  inline check on a fake runtime whose waits are paced to the period grid:
  3X, 2X back when the interval grows by a slot, and no third switch. 118
  of 118 tests pass.

From release 28

• Automatic 2X or 3X works in sessions without the presenter thread
  too (the inline shape: many titles on Virtual Desktop and Pimax, UEVR
  games on the Meta XR Simulator). There the game's threads block in the
  runtime's wait instead of the presenter's holds, and that time is read
  as the game's slack; room to spare also needs the xrEndFrame thread's
  CPU time under 1.85 periods a frame, since a pipelined game's wait can
  overlap its render thread's work. The GPU probe runs on a thread of its
  own once a display period. D3D12 games; the D3D11 and Vulkan bridges
  keep the shape you chose.
• Slower to come down. Coming back to 2X now takes four seconds of
  light frames, going to 3X two seconds of short ones, and more than one
  shown frame in twelve a repeat counts as short. On native DLSS Frame
  Generation in Stellar Blade the first release had come back on a
  two-second light view at the end of an orbit and then sat at 2.06 to 2.4
  periods with 10 to 28% repeats; a late return costs a lower game rate for
  a moment, an early one costs repeats on screen.
  Checked: Deep Rock Galactic under UEVR on the Meta XR Simulator, a
  presenter session this time, sat at its space rig for three hours at 2X
  (2.00 periods, the GPU 21% busy) without a switch; the inline rule is
  covered by its test and still wants a live session.
• Tests. xrfg_layer_auto_frames_inline runs the fake Pimax runtime,
  which stays inline: 3X after 4.2 s of slow frames and no second switch.
  115 of 115 tests pass.

From release 27

• Automatic 2X or 3X. Under Frames shown per game frame the tray now
  offers Automatic ([tray] frames_auto=1, [ofxr] frames_auto=1; the
  panel's Per frame row has it as "auto"). The layer then picks the
  shape live, through the same switch the tray's 3X uses: when the game's
  frame interval has run over 2.15 display periods for two seconds with no
  slack in the layer's waits, which is a game short of half the refresh
  rate repeating frames, it goes to 3X, where the game is paced to a third
  of the rate; when at 3X the game has more than 1.15 periods a frame to
  spare, measured both in the layer's waits and on its GPU, it goes back
  to 2X. Three seconds in a shape before leaving it, four at 3X, every
  condition held for two seconds, so a stall or a loading screen moves
  nothing. This is the answer to stutter in a game that sits between a
  third and a half of the refresh rate, extrapolation included: a 37
  frames-a-second Stellar Blade on a 120 Hz Steam Frame repeated 18% of
  what it showed at 2X. The GPU is read by a timestamp probe on the game's
  queue once a display period, because a GPU-bound game paced to a third
  of the rate has a CPU thread with time to spare and a GPU with none; a
  build without the probe flapped between the shapes every four seconds in
  Stellar Blade. It acts where the layer's presenter thread runs (SteamVR,
  the simulators) in D3D12 games, and on DLSS Frame Generation needs an
  RTX 50; elsewhere the shape you chose stays and the panel says so.
  Live in Stellar Blade on the OpenXR Simulator at the user's UEVR scale
  (3703x3703 per eye, 38 frames a second in the rain city): 3X came five
  seconds into the orbit and held for the whole of it with no repeat, 30
  real and 60 generated frames a second, the GPU read 67% busy at 22 ms a
  frame; the pause menu (12 ms a frame) brought 2X back within six seconds,
  45 + 45 with no repeat. The build before the GPU probe had flapped between
  the shapes 35 times in the same orbit.
• Tests. xrfg_layer_auto_frames paces a fake game: 25 ms frames at a
  10 ms period went to 3X after 3.0 s, 2 ms frames came back to 2X 4.2 s
  later. 114 of 114 tests pass. Five games were run on the previous
  release's layer on the Meta XR Simulator after the upstream merge
  (FlatOut 4 VR on the D3D11 bridge, Hubris, Kayak VR, Moss II, RoboQuest
  VR), all generating.

From release 26

The five fixes of djules75's 0.2.13.2 (V439 to V443) are now in this fork,
as their own commits, with one adaptation:

• No prime hold on SteamVR (djules75 V439). MSFS 2024 at 3X on SteamVR
  ran at 16 to 26 frames a second with the one-frame hold every presenter
  prime had since V438, SteamVR's own half-rate flag on most frames. SteamVR
  is the one runtime whose presenter frames do not come at a steady cadence,
  so the hold is not the one-period hold it is elsewhere; a SteamVR prime is
  released as soon as it is handed over again.
• The D3D11 bridge releases at the game's xrEndFrame (V440). IL-2 Great
  Battles releases one eye 3.8 ms before its xrEndFrame and drew into it
  after, so the bridge's copy missed the end of the frame and that eye
  stuttered. A bridged release now waits for the game's xrEndFrame, where
  copy and capture both see the finished image. Adapted here: the deferred
  release pairs its image with the DLSS evaluation that was published when
  the game released it, not with whatever was published by xrEndFrame, so a
  game with a swapchain per eye keeps each eye's own vectors. The bridge
  tests cover the deferral; a D3D11 game with a swapchain per eye and DLSS
  was not at hand to try live. Checked live on the Meta XR Simulator:
  hello_xr on the D3D11 bridge (every release deferred, generation at 2X),
  hello_xr D3D12 with the panel, and Lies of P under UEVR with its DLSS
  vectors.
• A busy history slot is waited for, not reset (V441). Skyrim VR on a
  Steam Frame cycled through primes when a capture found its ring slot
  still in use on the GPU; the capture now waits up to a display period for
  it (the fl...