diff options
Diffstat (limited to 'wiki/Graphics-Execution.md')
| -rw-r--r-- | wiki/Graphics-Execution.md | 70 |
1 files changed, 45 insertions, 25 deletions
diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md index 48423f8..59196d5 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-10-30, tree `master @ b4930168`. Tags: `[live]` observed end to +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` observed end to end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined success state; `[planned]` designed, not built. @@ -82,11 +82,14 @@ fidelity: faults across repeated launches. This proved engine-side dispatch before the verbatim lane existed. The program itself is still a development stand-in at this rung — execution proof, not pixels. -3. **Forwarding the client's own pushes** `[wall]`. The goal state: the GL - client's own GPFIFO ring and method streams are read, decoded and executed - with the client's real per-draw state. The GL client's channel is created - today, but it never submits — its pushes have not been made readable — and - this lane is gated on the ring/push-readability work (§6). +3. **Forwarding the client's own pushes** `[wip]`. The GL client's own + channels now register, submit and retire: the direct-GL GR channel + (`0xbeef0100`) and its CE siblings (`0xbeef0101`/`0xbeef0102`) are + discovered, their rings and releases are decoded, and the X server's DDX + kick channel (`0xbfef0002`) is decoded from its ring head with its + class-2D notification authored. What remains is completing the GLX + context-creation handshake and the client's kick-slot wait (§6), not + making the pushes readable. ## 4. The channel and object picture @@ -95,9 +98,17 @@ fidelity: module traps. Channels are typed by engine: a graphics channel carries 3D state and draws; copy-class channels carry memory movements. * **The graphics object class** the guest's 3D stream binds is the Turing - graphics class, `0xC597`. The stream the emulation can capture today comes - from the **X server's channel** (`OpenGL`); the 2D present/readback work + graphics class, `0xC597`. Streams now come from both the **X server's + channel** and the **direct GL client's own channels** (`0xbeef0100` GR plus + the `0xbeef0101`/`0xbeef0102` CE siblings); the 2D present/readback work rides lighter 2D-class and copy-engine shapes. +* **Display and modeset** `[live]`. The guest's modeset path is served by an + emulated display engine: the display push-buffer channels (core `0xc57d`, + window `0xc57e`, immediate/window `0xc57b`) are registered, their push + buffers parsed, and the notifier/`UPDATE` completion authored. This is what + lets nvidia-modeset/NvKms register (`/dev/dri`), X settle and GLX clients + obtain a real GL context. The display-capability seam is parameterised in + the campaign configuration. * **Cells of state**: 3D streams are long—hundreds of method words per draw — and mix state binds (viewport, render target, ZS, blend/ROP), program and constant binds, vertex/index streams and draw-issuing methods. The capture @@ -117,6 +128,10 @@ release group wakes the client. The emulation relays engine completions into guest-observable memory (MSI-X plus a poller), and the guest resumes from there. +For the display path, completion is the notifier write and `UPDATE -> +FINISHED`; a completion event deferred by the reply path is force-retried +until it posts, so the X server's mode set finishes. + 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 natural completion path is being finished. The 60-fps milestone explicitly @@ -124,20 +139,18 @@ requires it switched off, along with any external poke. ## 6. Where the frontier is (ranked walls) -1. **The GL client's submissions** `[wall]`. The client's channel exists but - never submits: direct measurement shows the client process writes no put - pointer in any mapping the service can see, and its pushes are not yet - reachable. Everything downstream waits on this. -2. **Program (SASS) delivery** `[wall]`. Graphics programs reach the device - through the driver's copy/utility-channel uploads; those inline-data - writes are not yet materialised for the GL/Vulkan clients, and the program - page the engine fetches is empty. With the data-set gate bypassed, the - engine fetches the launch and MMU-faults (`FAULT_PDE`) at the program VA — - proof the channel and context are alive, and that mapping + content are - the missing pair. -3. **Non-black frames** `[wall]`. Once draws execute with real state and real - programs, the capture must show motion; every frame captured so far is - black. +1. **The X GLX context-creation completion** `[wall]`. With the UVM + channel-pool and direct-GL submission walls closed, the X server spins in + its RM ioctl path (`_nv018351rm`) while a GL client's GLX context request + waits on the X reply. The X DDX's own channels and the GLX reply are the + current named objects. (Fullscreen GZDoom's client-triggered mode set can + still wedge X; the campaign path is a settled X plus windowed GZDoom.) +2. **The client kick-slot word** `[wall]`. The GL client polls a kick-slot GPU + address for its completion; the RM notifier page is a different object, so + the completion must be authored at the client's kick-slot address. +3. **Non-black frames** `[wall]`. Once the GLX context completes and the + client's kick wait resolves, the capture must show motion; every frame + captured so far is black. 4. **Sustained frame rate, and two VMs** `[target]`. The defined end state: 60 fps in one VM with no forcing, then two VMs on two mediated devices with non-black frames in both. @@ -147,19 +160,26 @@ requires it switched off, along with any external poke. | Capability | State | |---|---| | X server initialises on the emulated vGPU (driver DMA sanity push, ScreenInit) | `[live]` | -| `glxinfo` enumerates the emulated GPU with the NVIDIA renderer | `[live]` | -| GZDoom launches and runs on the emulated vGPU | `[live]` (pixels frontier) | +| 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]` | +| GZDoom obtains a real GL context; windowed reaches renderer startup | `[live]` (pixels frontier) | | GL section capture: the X server'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]` | | 2D screen fills and copy-engine present ops execute | `[live]` | -| Direct GL client: device-init gate handled, channels allocate, readback path returns clean | `[wip]` (client submissions not yet) | +| Direct GL client: device-init gate handled, channels allocate, readback path returns clean | `[live]` | +| Direct GL client channels submit and retire (GR `0xbeef0100`, CE `0xbeef0101`/`0xbeef0102`); DDX kick channel decoded | `[live]` | +| X GLX context-creation completion and the client kick-slot word | `[wall]` | | Non-black pixels from the emulated vGPU's 3D pipeline | `[wall]` | | Windows/DirectX guests | `[planned]` | ## 8. What is not claimed * No non-black pixel has been produced by the emulated vGPU's 3D pipeline yet. +* Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a + rendered-frame claim; the GLX context-creation and kick-slot completions are + the current walls. * No frame-rate or latency numbers: the scheduled measurement is defined (60 fps over 60 s, no forcing) but not yet met. * The `virgl`-based demo videos are a different, labelled path — not this one. |