diff options
Diffstat (limited to 'wiki/Execution-Frontier.md')
| -rw-r--r-- | wiki/Execution-Frontier.md | 43 |
1 files changed, 26 insertions, 17 deletions
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md index f5bfa9d..5af5e6d 100644 --- a/wiki/Execution-Frontier.md +++ b/wiki/Execution-Frontier.md @@ -14,7 +14,7 @@ > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md); > the docs tree wins on disagreement. -Status: 2026-11-12, tree `master @ 800c108f`. +Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories are labelled as such. @@ -104,10 +104,15 @@ replay executes; the **first non-black GPU-rendered output** landed: a pbuffer probe returns `pixel=ff0000ff`, the off-screen path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11, a 50 s capture on 2026-11-12), and GZDoom reaches `V_Init: allocate screen` -with its GL 4.6.0 context when the shared nvClip `modeNum` is even. What is -missing is **window/screen pixels through the NVIDIA path**: the direct-GL -client's own 59,556-byte setup push is not yet resolvable/readable host-side -under the client's page-directory churn, so its draw sections never reach the +with its GL 4.6.0 context when the shared nvClip `modeNum` is even. The X +side of the path was hardened in the 11-12/11-13 wave (DDX idle-DMA/ScreenInit, +USERD-latch, re-probe, kernel-mode spin and flip-event walls closed; X green +for more than 10 minutes), captured GL sections now execute on the engine, and the +direct-GL push bodies decode as real GR method streams above 10 GiB through +the VAS walk. What is missing is **window/screen pixels through the NVIDIA +path**: the direct-GL payload VAs (`0x4001004` setup push, +`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because +their user/UVM VAS is never registered, so its draw sections never reach the engine, glxgears' window is black, and a synchronous window draw wedges X on some boots. The guest Vulkan pipeline's inline-to-memory upload arm is its gap. The full picture lives on @@ -170,13 +175,17 @@ CUDA guests is in progress. **Issue D — the graphics pixel frontier.** The display/KMS stack and the GL client now run end to end (NvKms registers, X settles, the stock GLX path is fully green with glxinfo 4.6.0 and ~520 FPS glxgears, the DDX 3D replay -executes, the first non-black GPU-rendered frames and videos are captured -off-screen, and the direct-GL ring/USERD machinery is substantially hardened); -but the direct-GL client's 59,556-byte setup push is not yet readable/ -resolvable host-side under its page-directory churn, so its draw sections -never open on the engine, glxgears' window is black, and a window draw wedges -X on some boots. Command-stream delivery, the window/screen present and X -screen-init stability are the named blockers +executes, the X DDX/ScreenInit stability walls are closed with X green >10 +minutes, captured GL sections execute on the engine, the first non-black +GPU-rendered frames and videos are captured off-screen, and the direct-GL +ring/USERD machinery is substantially hardened); client push bodies now +decode as real GR method streams above 10 GiB via the VAS walk. The remaining +gap is registration: the direct-GL payload VAs (`0x4001004` setup push, +`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because +their user/UVM VAS is never registered, so its draw sections never open on +the engine, glxgears' window is black, and a window draw wedges X on some +boots. Command-stream delivery, the window/screen present and the X +first-generation screen-init lottery are the named blockers ([`Graphics-Execution.md`](Graphics-Execution.md)). ## 6. Lines of investigation (live) @@ -191,11 +200,11 @@ screen-init stability are the named blockers 4. **Hold the acceptance battery** — vector-add, matrix-multiply and the transformer kernel; each entry is accepted only on its own verification output (`bad=0` + `STATUS OK`). -5. **The graphics pixel frontier** — make the direct-GL client's command - stream (the 59,556-byte setup push and its ring/CE siblings) resolve and - execute host-side, make the window/screen present land, and stabilise X - screen-init across boots so the proven off-screen frames become window - pixels; the lanes, the walls and the milestone ladder are on +5. **The graphics pixel frontier** — register the direct-GL payload user/UVM + VAS (or pin the payload set from the guest pagemap) so the setup push and + draw pushes resolve, make the window/screen present land, and reduce the X + first-generation screen-init lottery so the proven off-screen frames + become window pixels; the lanes, the walls and the milestone ladder are on [`Graphics-Execution.md`](Graphics-Execution.md). ## 7. Theories, resolved |