diff options
Diffstat (limited to 'wiki/Graphics-Execution.md')
| -rw-r--r-- | wiki/Graphics-Execution.md | 123 |
1 files changed, 68 insertions, 55 deletions
diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md index eea0574..38eab6c 100644 --- a/wiki/Graphics-Execution.md +++ b/wiki/Graphics-Execution.md @@ -12,7 +12,7 @@ > [`../docs/04-implementation/04-real-render-walls.md`](../docs/04-implementation/04-real-render-walls.md) > (the measured walls); the docs tree wins on disagreement. -Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` observed end to +Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` observed end to end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined success state; `[planned]` designed, not built. @@ -81,14 +81,19 @@ fidelity: green, and a guest pbuffer `glClear(red)+glFinish+glReadPixels` probe returns a real pixel (`pixel=ff0000ff`): the replay and readback machinery works. The off-screen frame path then produced **500/500 non-black 640x480 - animated frames** and a captured 45.4 s video. The direct-GL **GR ring - `0xbeef0100` now resolves** (`4acac093`: beef-family always-probe, - per-channel promote backoff, rank-collision fallback, parked-candidate - eviction); its releases advance frame by frame and GZDoom reaches - `V_Init: allocate screen` with its GL 4.6.0 context. The direct-GL **CE - ring `0xbeef0101` never resolves**, so the client's CE work does not - execute and the guest wedges ~90 s after `V_Init`; window/screen present - is still the frontier (§6). + animated frames** per run and captured videos (45.4 s on 2026-11-11; a + 50 s 640x480 h264 capture on 2026-11-12). X and the stock NVIDIA GLX path + are fully green (`glxinfo -B` returns 0, OpenGL 4.6.0 direct, `glxgears` + ~520 FPS), and GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 + context whenever the shared nvClip `modeNum` is even. The direct-GL + ring/VAS anchor and USERD machinery are substantially hardened (verified + page-directory discovery, per-rank content scans, eager push pins, + client-allocated USERD resolution, foreign-USERD skip, aperture-aware + fallback, wrapped-PUT acceptance). What remains for the client's own + stream is **delivery**: its 59,556-byte setup push (GPU VA `0x4024004`) is + still not resolvable/readable host-side while the client's page-directory + incarnation churns, so no draw section opens and the window stays black; + window/screen present is still the frontier (§6). ## 4. The channel and object picture @@ -139,13 +144,16 @@ DDX's reserve loop. For a windowed GL client the present is a kick; the GSP event-IRQ fix now sets the RISC-V SWGEN0 IRQSTAT/IRQMASK/IRQDEST and latches the CPU-tree leaf, so the guest services the event and glxgears completes swaps, and the GR backend no longer times out (the pair-close/pair-safe -replay fixes are default ON; draws retire in 3-2400 ms). The DDX 3D replay -renders and reads back a pbuffer pixel (`pixel=ff0000ff`), the off-screen -frame path produced non-black animated frames and a 45.4 s video, the -RM write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed -(`df6e71bb`), and the direct-GL GR ring now resolves with advancing releases. -The next step is the direct-GL CE ring `0xbeef0101` and the window/screen -present path. + replay fixes are default ON; draws retire in 3-2400 ms). The stock GLX + path is fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 direct + rendering; `glxgears` renders ~520 FPS; the Xorg channel-idle WAIT count is + zero), the DDX 3D replay renders and reads back a pbuffer pixel + (`pixel=ff0000ff`), the off-screen frame path produced non-black animated + frames and captured videos (45.4 s and 50 s), the RM write-lock holder + (Xorg in the DDX vidheap scrub wait) is fixed (`df6e71bb`), and the + direct-GL ring/USERD machinery is hardened. The next step is delivering the + direct-GL client's own **setup push** (59,556 bytes at VA `0x4024004`) and + then the window/screen present path. During bring-up the module also carries a **diagnostics-only mirror** for apps that spin on a shared progress word; it exists so a run can proceed while the @@ -154,35 +162,37 @@ requires it switched off, along with any external poke. ## 6. Where the frontier is (ranked walls) -1. **Direct-GL CE ring resolution** `[wall]`. The GR ring `0xbeef0100` - resolves and its releases advance, but the CE ring `0xbeef0101` - (`gpfifo=0x4100000`) never maps: `VAS-PROMOTE` walks a parked candidate and - returns `rc=-2`, then `NOT mapped by any registered VAS` every ~7 s. The - client's CE work never executes and GZDoom wedges ~90 s after `V_Init`. - Next: walk all parked candidates regardless of owner VAS and/or keep at - least two fresh same-VAS parks. -2. **Window/screen present and the GLX lottery** `[wall]`. The pbuffer and - off-screen frame paths are proven (`pixel=ff0000ff`, 500/500 non-black - frames, 45.4 s video), but glxgears' window is black and the GLX - probe/frames path is a per-window lottery (hang/black/BadValue). A - synchronous window draw wedges X; screen capture must use the ivshmem - frame path and the present must be made to land. -3. **X startup / stability** `[wall]`. X startup is a per-boot lottery: on - 3/6 boots window creation wedges Xorg in an unkillable kernel RM spin - (`_nv052600rm+0x7b`); `Failed to initialize DMA`, push-buffer `0x51`, - `Wait for channel idle timed out` and occasional vmalloc failures also - appear. A fresh cycle clears it. The shared nvClip `modeNum` must be even - for the GL client's state init to succeed; the odd value is the guest - kernel's nvKms deferred close, not module-induced. -4. **The X DDX footprint** `[wall]`. The DDX allocates 4 GB of system pages at - startup; an 8 GB guest has no headroom once GZDoom's own footprint lands - and both are OOM-killed. Current runs use a 12 GB guest; the allocation is - a suspected emulation gap (a 512 MiB emulated VRAM falling back to a 4 GB - sysmem allocation) to fix. -5. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once - the CE ring, the window/screen present and X stability land, the capture - must show motion in a window, then 60 fps in one VM with no forcing, then - two VMs on two mediated devices with non-black frames in both. +1. **Direct-GL command-stream delivery** `[wall]`. The direct-GL ring/VAS + anchor is substantially hardened (verified-pair page-directory discovery, + per-rank content scans, eager push pins at the ring latch, client-allocated + USERD resolution with a foreign-USERD skip, aperture-aware wire fallback and + wrapped-PUT acceptance), but the client's own **59,556-byte setup push** + (GPU VA `0x4024004`) is still not resolvable or readable host-side while + the client's page-directory incarnation churns — the pages live in the + emulated FB aperture beyond the visible window, and the CE ring sibling + (`0xbeef0101`) resolves only intermittently. Until the setup push decodes, + no GL draw section opens and no `GR LAUNCH` is submitted for the direct + client: GZDoom spins in its GL pipeline after `V_Init` and the window stays + black. +2. **Window/screen present** `[wall]`. The pbuffer and off-screen frame paths + are proven (`pixel=ff0000ff`, 500/500 non-black frames, captured videos), + but a windowed present does not land: glxgears' window is black, the DDX + shared-surface `gpuRefCount`/`lastKickoffRefCount` poll (W1) must be + satisfied through a verified surface VA, and a synchronous window draw + wedges X. +3. **X screen-init and stability** `[wall]`. X startup is still a per-boot + lottery: the DDX can fail its idle-DMA check (`Failed to idle DMA` -> + `Failed to allocate notification memory` -> `Failed to allocate push + buffer` -> `ScreenInit failed`), and the shared nvClip `modeNum` must be + even for the GL client's state init to succeed (an odd value is guest + userspace X-driver state, cleared by one X restart — not a host bug). + Wrapped PUTs and the kick-idle marker/GET publication are handled; a guest + kernel panic after a wedge is recovered by an offline filesystem check. +4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once + the command-stream delivery, the window/screen present and X screen-init + land, the capture must show motion in a window, then 60 fps in one VM with + no forcing, then two VMs on two mediated devices with non-black frames in + both. ## 7. What is proven today @@ -192,24 +202,26 @@ requires it switched off, along with any external poke. | Display engine serves the modeset push buffers; notifier plus `UPDATE -> FINISHED` | `[live]` (campaign configuration) | | nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`); `nvidia-smi -L` enumerates | `[live]` | | `glxinfo` reports the emulated GPU with the NVIDIA renderer (OpenGL 4.6.0, direct rendering) | `[live]` | -| X green on attempt 1 in three consecutive cycles (`ebf3130f`) | `[live]` | +| X green on attempt 1 in three consecutive cycles (`ebf3130f`); X + stock GLX fully green on the current stack (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears` ~520 FPS, Xorg WAIT 0) | `[live]` | | GSP event-IRQ fix wakes the guest poll; glxgears completes swaps | `[live]` | | 2D path end-to-end: accelerated X fills read back via `xwd` | `[live]` | | Guest's real GL draws forward and execute on the physical GPU (`work_gr backend_ok=5-7`) | `[live]` | | GR backend timeouts fixed (`backend_timeout=0`; draws retire in 3-2400 ms) | `[live]` | | DDX 3D replay executes (`section captured` + `GR LAUNCH` on `0x1000014`, 12 launches/cycle) | `[live]` | | First real GPU readback: pbuffer `glClear(red)+glReadPixels` -> `pixel=ff0000ff` | `[live]` | -| First non-black GPU-rendered frames: 500/500 off-screen frames; 45.4 s video captured (`r1769`) | `[live]` | -| Direct-GL GR ring `0xbeef0100` resolves; releases advance (`4acac093`) | `[live]` | +| First non-black GPU-rendered frames: 500/500 off-screen 640x480 frames per run; 45.4 s video (`r1769`) and a 50 s capture (2026-11-12) | `[live]` | +| Direct-GL GR ring `0xbeef0100` resolves; releases advance; ring/VAS anchor hardened (verified page-directory discovery, eager push pins, per-rank scans) | `[live]` | +| Client-allocated USERD resolved from the channel's memory objects (`hUserdMemory`/`userdOffset`); foreign-USERD adoption skipped; aperture-aware wire fallback | `[live]` | +| Guest adapter init with the all-sysmem instance configuration (`RMInstLoc`) — the BAR2-verify trap | `[live]` | | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` | | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` | | GL section capture: the X channel's `0xC597` stream decoded | `[live]` | | Verbatim 3D method-stream replay retired by the engine (no MMU fault) | `[live]` | | Synthesized launch executes real `sm_75` SASS; Turing `V3` program header accepted | `[live]` | -| X server survives the run on a 12 GB guest (the DDX's 4 GB sysmem allocation forces the size) | `[live]` | -| Direct-GL CE ring `0xbeef0101` resolves and the client's CE work executes | `[wall]` | +| Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` | +| Direct-GL command-stream delivery (the 59,556-byte setup push at VA `0x4024004`; the CE ring `0xbeef0101`) | `[wall]` | | Window/screen present produces non-black window pixels | `[wall]` | -| X startup/stability (`_nv052600rm` soft-lock, `0x51`, vmalloc) | `[wall]` | +| X screen-init/stability (idle-DMA ScreenInit lottery, modeNum parity) | `[wall]` | | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` | | Windows/DirectX guests | `[planned]` | @@ -217,13 +229,14 @@ requires it switched off, along with any external poke. * No **window/screen** pixel has been produced by the emulated vGPU's 3D pipeline yet; every screen capture so far is black. The proven non-black - frames and the 45.4 s video come from the off-screen pbuffer path - (pbuffer -> sysmem -> kvmfr ivshmem -> host reader), not from a windowed X - screen capture. + frames and the videos (45.4 s and 50 s) come from the off-screen pbuffer + path (pbuffer -> sysmem -> kvmfr ivshmem -> host reader), not from a + windowed X screen capture. * Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a rendered-frame claim. GZDoom reaching `V_Init: allocate screen` proves the client's GL init and the direct-GL GR lane, not the game loop or a - presented frame; the direct-GL CE ring still does not resolve. + presented frame; the direct-GL setup push does not yet decode, so the + client's draws do not reach the engine. * No frame-rate or latency numbers: the scheduled measurement is defined (60 fps over 60 s, no forcing) but not yet met. |