Untracked weave outputs transparent black (~22 frames every ~1983 ms) when the weave runs on the Intel scanout adapter

[dfattal]

Runtime-side counterpart: DisplayXR/displayxr-runtime#1134 (full evidence chain there).

What the runtime observes

On a hybrid box (render = NVIDIA dGPU, scanout = Intel iGPU), when the runtime's output-device
split (DXR_WEAVE_ON_SCANOUT=1) puts the weave on the scanout adapter, and no face is
tracked, leia_dp_d3d11_process_atlas writes a fully (0,0,0,0) transparent-black output for
~22 consecutive frames every ~1983 ms — ~366 ms of black every 2 s.

On the render adapter (split off) the same untracked state is rendered correctly, every frame.
So this is adapter-dependent, not a general untracked-path defect.

What the runtime can rule out

The runtime instrumented the call site (DXR_SPLIT_COVER_DIAG, DisplayXR/displayxr-runtime@d627a9edb)
and can state the following about the frames that come out black:

• The DP covers the target. The compositor clears the back buffer to magenta immediately before
  process_atlas; on the black frames not one of five sampled points is still magenta. The DP is
  not returning early — it draws, and what it draws is (0,0,0,0).
• The atlas handed in is correct, on the correct device. Dumped and inspected on a black frame:
  a clean 1280x360 2x1 stereo atlas, opaque, dark-navy background, cube present in both tiles.
• Every parameter is invariant across the good/black boundary. Same tile_columns/tile_rows
  (2x1), same view dims (640x360), same output dims, same atlas encoding, same transparency mode
  (client_presents=false, opaque), same context and device.
• set_frame_timing is not implicated: measured R = 15.8 ms on the black frames and on the
  good ones alike, i.e. the split does not inflate the prediction horizon here.
• Predicted eyes are constant: get_predicted_eye_positions returns valid=1 count=2 with the
  pair fully collapsed, L = R = (0.000, 0.100, 0.600) — the plug-in's own untracked signature
  (is_tracking = (dx²+dy²+dz²) > 1e-6 → false) — and it does not move across the boundary.

So nothing the runtime supplies changes at that ~2 s period. The cycle is internal DP / SR SDK
state.

Discriminating hint

Because the inputs are invariant, the ~2 s cycle has to be driven from inside. Two suspicions,
neither verified:

1. The untracked pulse / "seeking viewer" animation's own render pass silently failing on Intel
   — a shader, blend, viewport or state assumption that holds on NVIDIA and not on the iGPU. An
   output of exactly (0,0,0,0) rather than garbage smells like a pass that ran and wrote nothing
   but transparent, or a clear that was not followed by its draw.

2. An adapter-dependent resource in the untracked path. Worth checking that everything the
   untracked branch touches is created on the device that is actually weaving. Two asymmetries were
   noticed while reading (both fine when the runtime passes a matching pair, but worth confirming
   under this configuration):

   • the SR weaver renders on the create-time cached sr->d3d11_context
     (leia_sr_d3d11.cpp CreateDX11Weaver / srCreateWeaverDX11), while the DP's own passes use
     the per-call context; leiasr_d3d11_weave takes no context parameter at all;
   • every lazily-created D3D11 resource uses ldp->device cached at factory time
     (leia_display_processor_d3d11.cpp), never ctx->GetDevice().

   The runtime does pass a matching device/context pair here (the DP is created with the split's
   out device and process_atlas is called with the same out context), so neither is wrong in
   this configuration — but both mean "which adapter" is decided once at create time, which is the
   shape of bug that shows up only on the second adapter.

Also noticed while reading, unrelated to this bug but against the repo's own invariant:
w_weave() (leia_sr_d3d11.cpp) calls the v1 weaver->weave() with no try/catch, on the
per-frame path, into a C caller that cannot catch. Same omission in the D3D12 arm.

Repro

Any scanout-split session, no face in front of the camera, ~2 s period:

set DXR_WEAVE_ON_SCANOUT=1
test_apps\build\bin\cube_handle_d3d11_win.exe          REM in-process
REM or, for the service path: start the service with the same var, then
REM set XRT_FORCE_MODE=ipc and launch the same exe

Confirm weave placement: ... weave/present on the SCANOUT adapter in the log, then step out of
the camera's view for ~30 s.

Needs a hybrid render/scanout box; on the reference machine the panel is driven by the Intel UHD
while rendering happens on the RTX 3080.

The runtime can help

DXR_SPLIT_COVER_DIAG=2 (service direct path) reports, per tick, whether the DP covered the target,
whether its input was black, whether its output was black, the predicted eyes, the measured R, and
burst edges with wall-clock deltas. DXR_WEAVE_PROBE=1 plus a %TEMP%\dxr_woven_trigger file dumps
the in-process back buffer exactly as the DP left it. Happy to add whatever else would narrow this
from the runtime side — including dumping the DP input and output on the same frame, which is
already wired.

[dfattal]

Cross-link: runtime-side issue is DisplayXR/displayxr-runtime#1134 (full evidence chain, correlation matrix, and the in-process vs service arms). Epic DisplayXR/displayxr-runtime#918.

[dfattal]

Diagnosed. The fault is SDK-side; the fix is tracked in LeiaInc/LeiaSR#189. Nothing to change in this plug-in.

Mechanism

The black frames are drawn by the SR SDK's untracked pulse shader, and its animation clock is the bug.

dx11weaver2.cpp:1154 sets bufferData.time = (float)GetTickCount() / 1000.0f — seconds since boot — and blit2.hlsl:79-141 feeds that straight into sin, cos and fmod. This machine's uptime during the runs was 565,564 s, well past the range some GPUs' trigonometric instructions define a result for. The pass yields NaN, atan2 propagates it through every glow term, and a UNORM render target stores NaN as 0. RGB goes to zero; alpha does not, because the pulse's dim (color = color * 0.8, blit2.hlsl:81) is applied before the block that computes the colour.

How that was proven

The alpha names the shader. Decoding the existing probe dump: all 921,600 pixels of the black frame are exactly (0, 0, 0, 204). 204 = 0.8 × 255, and × 0.8 appears in exactly one place in the stack — the pulse branch. So the pulse branch ran, and its texture fetch succeeded and returned an opaque texel (alpha arrived as 1.0 and got dimmed).

That last point retires the whole "bad input" family of hypotheses in one step, including both source asymmetries flagged in this issue. Neither the create-time cached sr->d3d11_context nor the factory-time cached ldp->device is implicated — a cross-device or unbound SRV would have returned (0,0,0,0), not an alpha the shader could dim. The paired input dump agrees: a clean 1280×360 SBS atlas, alpha 255 everywhere, navy background, cube in both tiles.

A correct pulse cannot be black. Re-implementing the pulse arithmetic in double precision over the full frame gives a minimum channel value of ~0.0375 and a bright rotating rim glow for any clock value. Uniform zero over a non-black atlas is unreachable when that shader executes as written.

The ~2 s cadence was not the bug

Burst starts are metronomic at 1983.0 / 1983.2 / 1982.9 ms — 2.000 s quantised to whole 60 Hz frames — with bursts of 22–23 frames, 91 of them in one run. That is the SDK's eye predictor rebuilding its filter history and briefly reporting a zero inter-eye distance, which flips isTracking (dx11weaver2.cpp:653) and drops the weaver into the pulse branch (:662). Every pulse frame was black; pulse frames were ~18% of untracked frames, which is the 18–23% black rate measured. Tracked frames are unaffected because the weave shader never touches that clock and forces alpha = 1.0.

Why the runtime's "nothing changes at that period" evidence held and still misled

get_predicted_eye_positions returns the weaver tracker's pair, while the SDK's isTracking branch reads a different tracker. The reported pair sat at exactly (0, 0.100, 0.600) m all session because that is the weaver tracker's fixed no-data fallback — (0, 100, 600) mm, the SDK's default weaver position. It was blind to the 2 s cycle by construction. The runtime's instrumentation was correct; the inference from it was not available.

Which binary this is

C:\Program Files\LeiaSR\Platform\bin\SimulatedRealityDirectX.dll, FileVersion v1.37.0+1494.812c51044c — built from exactly the source above (blit2.hlsl is baked into that DLL). LeiaSR_runtime.dll's v2 entry point is a thin pass-through (sr_runtime_weaver.cpp:38 → base->weave()). Nothing plug-in-compiled is on this path.

Predictions and mitigation

The fault is uptime-dependent, not fundamentally vendor-specific — it should disappear shortly after a reboot and should eventually reach any adapter whose trig range-reduction gives up. On a box that cannot take an SDK update, show_left_view_when_not_tracking = on in the device's sr_config.ini selects the plain-blit branch, which never touches the clock; it costs the searching animation, so it is a workaround, not the fix.

Landing here

• docs(drv_leia): #178 evidence chain — untracked pulse renders black (fix is SDK-side, LeiaSR#189) #180 — the evidence chain plus the reusable diagnostics as docs/untracked-fallback.md (who owns the untracked frame, the two-trackers trap, and the alpha fingerprint table for identifying which SDK shader drew a bad frame).
• fix(drv_leia): guard the v1 weave() on the per-frame path #179 — unrelated hardening found on the same path: try/catch around the v1 weave() per-frame call in the D3D11, D3D12 and GL arms.

A verification kit (the instrument, the pulse reference model, a 40-sample pass/fail oracle with its controls, and the artefacts above) is staged on the reference box at ~/.claude/dxr-tools/dxr178/ for when a fixed SDK build is available. Target: 0/40, against 8/40 today.

[dfattal]

SDK fix verified on the repro box: 0/40 fault frames (pre-fix 8/40) against installed SR 1.37.0+1498 (LeiaInc/LeiaSR@68087f05a, ST-5686), uptime repro condition intact. Runtime-side known-issue displayxr-runtime#1134 closed. This issue can close with your release process whenever the fix ships in a public SR Platform build.