Repository navigation
feat(example_dp): hardware-weaving (FPGA/ASIC) shape + weave-scope declaration - #4
Merged
Merged
Conversation
Not every 3D display expects final woven subpixels. A display that weaves in its own FPGA/ASIC is fed an ordinary video frame and does the weave during scanout, so its plug-in emits a PACKED frame instead of a woven one. The template only demonstrated the GPU-weaver shape, which left a whole class of vendor with nothing to fork. Two additions: - DXR_EXAMPLE_WEAVE_MODE=hardware selects a passthrough process_atlas. That looks too simple until you notice the compositor already lays the views out as a tile_columns x tile_rows grid at panel size — so once the declared tile geometry matches the chip (2x1 = side-by-side half, 1x2 = top-and-bottom, NxM = quilt), the atlas IS the packed frame and there is nothing left to rearrange. - get_scanout_caps declares how much of the panel the output transform covers. The runtime cannot infer it, and it decides what presentations can be correct: REGION takes a rect (windowed apps work), SCANOUT transforms the whole frame (only a fullscreen, panel-scoped presentation can be). Driven here by DXR_EXAMPLE_WEAVE_SCOPE so the routing is exercisable with no hardware; a real plug-in returns a constant. The slot is #ifdef-guarded on XRT_DP_D3D11_HAS_SCANOUT_CAPS, the coupled-ABI-addition pattern, so the template keeps building against a DXR_RUNTIME_GIT_TAG that predates it (v2.7.1 today). Bumping the pin turns it on with no other change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dfattal
added a commit
that referenced
this pull request
Aug 24, 2026
… v2.12.0 (#5) Follow-up to #4, which covered the D3D11 stub only. Three gaps a vendor forking for a hardware-weaving (FPGA/ASIC) display would have hit: 1. The VK DP had no get_scanout_caps, so a Vulkan-first vendor got no example and no hint that declaring scope is mandatory for them too. Added with the pointer-type trap called out: every other method in that file takes the GENERIC base, but this slot is on the VK VARIANT (dp->base, not dp->base.base) because the variant embeds the base by value and growing it would shift every appended slot (ADR-020). 2. example_device.c said nothing about hardware weaving — yet it is the file that decides the pack. The tile geometry declared there IS the layout the chip receives, which is exactly why process_atlas can be a passthrough. Documented the three common packs, the XRT_MAX_VIEWS=8 ceiling, and why the existing 1x1 @ 1.0,1.0 + 2x1 @ 0.5,1.0 pair is worth keeping even for an SBS-only product: it is the only shape that makes BOTH modes fill the worst-case swapchain envelope, the sole condition for zero-copy (ADR-030). 3. The runtime pin was v2.7.1, which predates the slot — so everything added in #4 was compiled out and a fresh fork saw inert code. Bumped both coupled pins (CMakeLists DXR_RUNTIME_GIT_TAG + workflow RUNTIME_REF, enforced together by the Rule-5 drift check) to v2.12.0, the first release carrying it. Checked before bumping: both tags are ABI major v5, and the vcpkg commit this template pins is byte-identical between them, so nothing else in CI has to move. Verified: all three stubs syntax-check clean against v2.12.0 headers with the guards ON. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The template only demonstrated the GPU-weaver shape — a plug-in that computes final woven subpixels. A whole class of vendor doesn't work that way: their display weaves in its own FPGA or ASIC on the scaler board, fed an ordinary video frame carrying a packed layout. Those vendors had nothing here to fork.
What
1.
DXR_EXAMPLE_WEAVE_MODE=hardwareselects a passthroughprocess_atlas.That looks too simple until you notice why it's correct: the compositor already lays the views out as a
tile_columns × tile_rowsgrid at panel size. Once the declared tile geometry matches what the chip expects —2×1 @ 0.5,1.0= side-by-side half,1×2= top-and-bottom,N×M= quilt — the atlas already is the packed frame, at exactly the target's dimensions. There is nothing left to rearrange. A real plug-in adds only its signalling: a watermark row stamped inprocess_atlas, or a sideband command fromrequest_display_mode.2.
get_scanout_capsdeclares how much of the panel the output transform covers. The runtime cannot infer it and it decides what presentations can be correct —REGIONtakes a rect (windowed apps work),SCANOUTtransforms the whole frame (only a fullscreen, panel-scoped presentation can be correct). Driven here byDXR_EXAMPLE_WEAVE_SCOPEso the routing is exercisable with no hardware; a real plug-in returns a constant.Pin compatibility
The slot is
#ifdef-guarded onXRT_DP_D3D11_HAS_SCANOUT_CAPS— the coupled-ABI-addition pattern the runtime headers use — so this template keeps building against the currently pinnedDXR_RUNTIME_GIT_TAG(v2.7.1), which predates the slot. Bumping the pin turns it on with no other change. Every reference to the new symbols is inside the guard; only a prose comment mentions it unguarded.Depends on DisplayXR/displayxr-runtime#1186 for the pin bump to be worth making.
Verification
v2.7.1pin, which is the case that must not regress.Note for whoever picks this up:
scripts\build-windows.bathas no ninja/vcvars discovery of its own, so on a box withdepot_toolsonPATHCMake picks up itsninjashell wrapper and configure fails withCMAKE_C_COMPILER not set. Unrelated to this change, but it makes a clean local build harder than it should be — worth a follow-up.