Hardware-verify #328: submit-time view count from the ACTIVE mode (merged untested on hardware)

[dfattal]

Why this issue exists

#328 (dxr_prov_submit_frame derives the projection layer's viewCount from the ACTIVE rendering mode at submit time instead of the swapchain-creation latch; native~/displayxr_extensions.h mirrored to display_info v19; macOS bundle rebuilt) was merged on CI green for all three platforms only — the submit-time change has not been exercised on hardware. The runtime contract it targets (PRIMARY_STEREO accepts exactly 2, or 1 only while the active mode is 1-view AND XR_DXR_display_info is enabled; a 1-view submission in a 2-view mode is now XR_ERROR_VALIDATION_FAILURE instead of a silent flat-blit) is on runtime main but not yet in a released runtime. Do not cut a plugin release until (a) a runtime release containing runtime#1500 exists and (b) the legs below pass against it.

Test legs (Windows box, dev runtime built from runtime main ≥ c1e4fe00d; displayxr-unity-samples desktop-avatar + one single-pass sample)

For each leg quote the runtime log loaded from: line and the provider log's count/latch lines (capped at 8 — confirm it never exceeds that).

1. 2D ↔ 3D toggle, repeatedly (V key / xrRequestDisplayRenderingModeDXR), sim-display and Leia SR — zero XR_ERROR_VALIDATION_FAILURE in the runtime log across ≥20 toggles; the frame after each 1→2-view flip is accepted (the race fix(provider): submit the ACTIVE mode's view count + mirror display_info spec v19 (runtime#1486) #328 closes). Compare against the previous plugin build, which must show the silent flat-blit on the same sequence.
2. Minimised / 0-size window then restore (the ps_reconcile_primary() early-out path) — no rejected frames on restore.
3. Genuine 1-view mode — submits 1 (the existing Provider: live tile realloc on window/zone resize + render-mode change (handle-app parity) #172 P4 behaviour), accepted.
4. Zones sample (desktop-avatar) — per-zone swapchains unaffected; no regression in tile realloc.
5. macOS — load the rebuilt bundle (displayxr_unity.bundle, verified changed on disk 301,488 → 302,944 bytes) in a sample and confirm it initialises; the render-thread vs main-thread mode poll noted in fix(provider): submit the ACTIVE mode's view count + mirror display_info spec v19 (runtime#1486) #328 is exercised by leg 1 there too if a mac 3D display is available (otherwise record NOT tested).

Report

Post raw results per leg here (pass/fail, log excerpts) and a NOT tested list. Close when legs 1–4 pass on Windows; if any fails, revert or fix-forward before the runtime release ships.

Refs #328, DisplayXR/displayxr-runtime#1486, DisplayXR/displayxr-runtime#1519.

[dfattal]

win box — legs 1–4, Windows, runtime v2.16.37-41-gc1e4fe00d (main, via HKLM repoint; every run's loaded from: stamp checked), PreferredPlugin=sim-display

Binary under test: the #328 CI artifact displayxr_unity-windows-x64 (run 35368635246, DLL SHA-256 4d8e0049…, contains the new one-shot string) overlaid on the URP single-pass sample player (…_Data\Plugins\x86_64\displayxr_unity.dll). No C# changed v2.19.2 → v2.19.3 → #328 (only package.json, a shader resource, native), so the Sep-14 player + this DLL is the merged content. Negative control = the same player with the v2.19.3 DLL (fb5439d3…). Keys injected with the real scancode (keybd_event with MapVirtualKey scan — scan 0 never reaches Unity's raw-input keyboard).

Leg 1 — 2D↔3D toggle ×20 (SIM_DISPLAY_OUTPUT=sbs, V every 3 s): FAIL as specified — 1 rejected xrEndFrame per 2D→2-view flip, identical with and without #328

V cycles 1→2→3→4→0→1 (Anaglyph → Cropped SBS → Squeezed SBS → Quad → 2D → Anaglyph). 20 presses = 21 mode changes (the sample requests mode 1 at startup) = 4 crossings 0→1. Runtime log:

DLL	mode changes	XR_ERROR_VALIDATION_FAILURE	where
#328 4d8e0049…	21	4	one per 0 -> 1 flip, same millisecond as the mode-change event
v2.19.3 fb5439d3… (control)	21	4	same

[16:31:10.873] OXR EVENT: Rendering mode changed 0 -> 1
[16:31:10.873] XR_ERROR_VALIDATION_FAILURE: xrEndFrame(frameEndInfo->layers[0]->viewCount == 1) XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO accepts exactly 2 views (an app that enabled XR_DXR_display_info may submit 1 while the active mode is 1-view; this instance enabled it and the active mode has 2); N-view needs XR_VIEW_CONFIGURATION_TYPE_PRIMARY_MULTIVIEW_DXR

(and at 16:31:26.236, 16:31:41.567, 16:31:56.919 — every flip). The other 16 transitions (2-view↔2-view, 2-view→4-view, 4-view→2D) produce nothing. The provider's new one-shot submit views %u (active mode) != swapchain latch %u line never fired (0 of 8) in any run — at that submit ps_active_view_count() still read 1, i.e. the cached active_mode_index had not seen the event yet; the frame in flight was begun 1-view and lands after the runtime already switched. So the residual "event-delivery latency" window the #328 comment names is the whole observable here; the latch paths it closes (skipped reconcile) were not what bit in this sequence. Note the control shows a rejection, not a silent flat-blit — on this runtime (#1486) the old build is rejected too; the flat-blit is pre-#1486-runtime behaviour and cannot be reproduced against c1e4fe00d. Provider realloc: submit views 2 -> 1 / 1 -> 2 (mode switch …) lines fire on every 2D crossing in both runs.

Leg 2 — minimise / restore ×3 (SW_MINIMIZE 4 s, SW_RESTORE 4 s, in SBS): PASS

Zero XR_ERROR, zero rejections. Provider reallocs the primary target 800x450 -> 1920x1080 -> 800x450 on each cycle (primary swapchain+bridge recreated … (OK)).

Leg 3 — genuine 1-view (SIM_DISPLAY_FORCE_MODE=0): PASS

Provider: swapchain: 1600x900 arraySize=2 submit=1-view (2D) · submit_frame[0]: xrEndFrame layers=2 (views n=1). Runtime: VALIDATION_FAILURE=0 XR_ERROR=0; sim ignores the sample's OUTPUT_MODE=1 request (pinned).

Leg 4 — zones sample (desktop-avatar, v2.19.1 player + #328 DLL, SBS, V ×6): zones intact, same flip race

display-zones caps: result=0x0 supported=1 maxZones3D=32 -> ACTIVE, swapchain sized to 3D-zone recommended view 840x970 re-applied on every switch, realloc: submit views 2 -> 1 / 1 -> 2 ×3, 50 zone lines, no zone error. Here V toggles 2D↔Anaglyph directly (sequence 2>1 1>0 0>1 1>0 0>1 1>0 0>1): 3 crossings 0→1, 2 VALIDATION_FAILURE viewCount == 1 (one crossing landed clean) — the same race, timing-dependent.

NOT tested

• Leia SR arms of legs 1/3 (sim-display only; the Leia panel run is David's eyeball leg).
• Leg 5 (macOS bundle) — no mac in this session.
• A pre-#1486 runtime (to show the old flat-blit) — not on this box.

Reading

Legs 2–4 pass. Leg 1's stated pass criterion ("zero VALIDATION_FAILURE across ≥20 toggles; the frame after each 1→2-view flip is accepted") is not met, and #328 makes no measurable difference on this path (4/4 vs 4/4). Two ways to close it, either side: provider — on XrEventDataRenderingModeChanged (or when ps_active_view_count() disagrees with the frame's begun count) drop/resubmit that one frame with 2 views instead of 1; runtime — accept the single already-begun 1-view frame across a 1→2 switch (a grace frame at the mode edge) since the app could not have known. Raw logs kept on the box (rt_unity_l1_x20.log, rt_unity_l1_ctrl.log, prov_unity_l1_*.log, rt_unity_l2_min.log, rt_unity_l4_zones.log).

[dfattal]

Leg 1's one-frame rejection per 2D→3D flip is a runtime defect, not the provider's: the frame is begun and rendered under the 1-view mode and judged at xrEndFrame against the mode after the switch (same-millisecond timing; identical count with the v2.19.3 control). Filed as displayxr-runtime#1528 — the runtime will latch the mode at xrBeginFrame and grant the in-flight frame. Leg 1 should be re-measured on that fix (expect 0/4 rejections); legs 2–4 stand as passed. Keep this issue open until then.

[dfattal]

win box — leg 1 re-measured on runtime PR #1529 (aba496130, v2.17.0-2-gaba496130): 0 rejections on every 2D→3D crossing

Same harness and DLLs as above. desktop-avatar + #328 DLL, V×6: 3 crossings, 0 VALIDATION_FAILURE (was 2/3 on c1e4fe00d). desktop-avatar + its original v2.19.1 DLL (control): 3 crossings, 0 (the grace is runtime-side, so the old build is fixed too). URP + #328 DLL started in 2D: startup 0→1 crossing, 0. Full table on runtime#1529.

New, samples-side: with #1519 now on runtime main, the URP sample's V cycle gets stuck at Quad — mode 4 is denied for a PRIMARY_STEREO session (DENYING rendering mode 4 … view configuration (0x00000002) reports 2 views, 18× in a 20-press run) and DisplayXRInputController.cs:95 keeps re-requesting it instead of skipping to the next mode, so the URP player can no longer reach 2D via V. desktop-avatar (direct 2D↔3D toggle) is unaffected. The sample needs to skip unfillable modes or handle XrEventDataDisplayModeRequestDeniedDXR.

Leg 1's pass criterion is met once #1529 merges; the Leia SR arm and macOS remain NOT tested here.

[dfattal]

Released as v2.19.4

#328 is now shipped: v2.19.4 — com.displayxr.unity-2.19.4.tgz + the upm branch / upm/v2.19.4 tag, with the Windows displayxr_unity.dll Leia-EV-signed.

Windows: legs 1–4 PASSED (evidence in the comments above) — 0 rejected frames across repeated 2D→3D mode toggles against runtime v2.17.1. dxr_prov_submit_frame now reads the active mode directly and clamps to the allocated slices, so a 1-view submission can only be emitted while the mode actually says 1-view.

Requires runtime v2.17.1. The provider-side fix narrows the 1-view-in-2-view-mode window but cannot close it — the mode can still flip between the provider reading it and the runtime validating the submission. DisplayXR/displayxr-runtime#1528's mode-switch grace (shipped in runtime v2.17.1) absorbs that last frame. Against an older runtime a toggle can still surface XR_ERROR_VALIDATION_FAILURE at xrEndFrame.

NOT tested — why this issue stays open

• Leia SR arm — all verification was on the sim/non-SR path. No hardware-weaving run.
• macOS — the .bundle was rebuilt for this release and has had no runtime verification pass. Note the macOS-specific risk this fix was partly aimed at: the mode event is polled on the main thread (DisplayXRProviderDriver.LateUpdate) while submit runs on the render thread.

Known limitation (samples side, not the provider)

DisplayXR/displayxr-unity-samples#17 — a sample V-cycle can re-request a >2-view mode the runtime denies. Unity's stereo topology is fixed at 2 views, so no provider-side change can satisfy it; cycling past the denied mode is harmless and the sample stays on the last granted mode.

Leaving this open for @dfattal to close once the Leia SR and macOS arms are covered.