diff options
Diffstat (limited to 'wiki')
| -rw-r--r-- | wiki/.publish-manifest.json | 120 | ||||
| -rw-r--r-- | wiki/Execution-Frontier.md | 29 | ||||
| -rw-r--r-- | wiki/Execution-Plane.md | 18 | ||||
| -rw-r--r-- | wiki/FAQ.md | 16 | ||||
| -rw-r--r-- | wiki/Graphics-Execution.md | 70 | ||||
| -rw-r--r-- | wiki/Host-Module.md | 12 | ||||
| -rw-r--r-- | wiki/OpenGL.md | 35 | ||||
| -rw-r--r-- | wiki/Physical-GPU-Backend.md | 12 | ||||
| -rw-r--r-- | wiki/Project-Goals.md | 4 | ||||
| -rw-r--r-- | wiki/Project-Plan.md | 20 | ||||
| -rw-r--r-- | wiki/Project-Status.md | 17 | ||||
| -rw-r--r-- | wiki/System-Overview.md | 23 |
12 files changed, 217 insertions, 159 deletions
diff --git a/wiki/.publish-manifest.json b/wiki/.publish-manifest.json index 98ed37a..a62c613 100644 --- a/wiki/.publish-manifest.json +++ b/wiki/.publish-manifest.json @@ -64,11 +64,11 @@ }, "FAQ": { "file": "FAQ.wiki", - "new_revid": 24017, - "old_revid": 23968, - "source_sha": "c1c84bf09feb6acb", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:29Z", + "new_revid": 24035, + "old_revid": 24017, + "source_sha": "74cf2eadde0ef110", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:41Z", "title": "FAQ" }, "GMMU Multi-Tenant Protection": { @@ -127,11 +127,11 @@ }, "Graphics Execution": { "file": "Graphics-Execution.wiki", - "new_revid": 24004, - "old_revid": null, - "source_sha": "c3418a7220f62d10", - "summary": "New page (2026-10-30 wiki refresh): Graphics Execution", - "timestamp": "2026-10-30T17:04:57Z", + "new_revid": 24036, + "old_revid": 24004, + "source_sha": "ec7b481243e5a975", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:41Z", "title": "Graphics Execution" }, "Guest Driver Lifecycle: A Field Guide": { @@ -190,11 +190,11 @@ }, "Main Page": { "file": "Main-Page.wiki", - "new_revid": 24030, - "old_revid": 24025, - "source_sha": "73ae8e2c1f093423", - "summary": "2026-10-30 wiki refresh: add Project Plan page (phases, gates, workstreams, next steps)", - "timestamp": "2026-10-30T17:12:04Z", + "new_revid": 24043, + "old_revid": 24030, + "source_sha": "629ce3a5aac9608e", + "summary": "2026-11-09 status refresh: display/KMS working; GL stack live, first rendered frame is the frontier", + "timestamp": "2026-11-09T17:57:47Z", "title": "Main Page" }, "MediaWiki:Sidebar": { @@ -226,11 +226,11 @@ }, "OpenGL": { "file": "OpenGL.wiki", - "new_revid": 24005, - "old_revid": null, - "source_sha": "9b1bdc8f09c43277", - "summary": "New page (2026-10-30 wiki refresh): OpenGL", - "timestamp": "2026-10-30T17:04:59Z", + "new_revid": 24038, + "old_revid": 24005, + "source_sha": "dc2983b55ae26367", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:42Z", "title": "OpenGL" }, "Performance": { @@ -244,38 +244,38 @@ }, "Physical GPU Backend and Guest Wiring": { "file": "Physical-GPU-Backend.wiki", - "new_revid": 24015, - "old_revid": 23999, - "source_sha": "059030d7cb01f248", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:26Z", + "new_revid": 24046, + "old_revid": 24015, + "source_sha": "976895b03fd0c7f5", + "summary": "2026-11-09 wiki refresh: display/KMS live, direct-GL submissions, X/GLX completion wall", + "timestamp": "2026-11-09T17:59:28Z", "title": "Physical GPU Backend and Guest Wiring" }, "Project Goals": { "file": "Project-Goals.wiki", - "new_revid": 24003, - "old_revid": null, - "source_sha": "8392f8beadbe9b45", - "summary": "New page (2026-10-30 wiki refresh): Project Goals", - "timestamp": "2026-10-30T17:04:55Z", + "new_revid": 24039, + "old_revid": 24003, + "source_sha": "0a87371b6fc44cb4", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:43Z", "title": "Project Goals" }, "Project Plan": { "file": "Project-Plan.wiki", - "new_revid": 24029, - "old_revid": null, - "source_sha": "0440c98d1b4927fa", - "summary": "2026-10-30 wiki refresh: add Project Plan page (phases, gates, workstreams, next steps)", - "timestamp": "2026-10-30T17:12:02Z", + "new_revid": 24040, + "old_revid": 24029, + "source_sha": "aa338c0be00b8706", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:44Z", "title": "Project Plan" }, "Project Status": { "file": "Project-Status.wiki", - "new_revid": 24011, - "old_revid": 23997, - "source_sha": "eb7a5ff2ceed506d", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:21Z", + "new_revid": 24041, + "old_revid": 24011, + "source_sha": "171dd044bf49b267", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:44Z", "title": "Project Status" }, "RPC Message Format": { @@ -289,11 +289,11 @@ }, "System Overview": { "file": "System-Overview.wiki", - "new_revid": 24016, - "old_revid": 23990, - "source_sha": "262f756d3638e4a4", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:28Z", + "new_revid": 24042, + "old_revid": 24016, + "source_sha": "87ae4585a875643b", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:45Z", "title": "System Overview" }, "Template:About message": { @@ -325,11 +325,11 @@ }, "The Execution Frontier": { "file": "Execution-Frontier.wiki", - "new_revid": 24012, - "old_revid": 23996, - "source_sha": "b204f91275834f9f", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:22Z", + "new_revid": 24044, + "old_revid": 24033, + "source_sha": "f1b71722ae3acdbd", + "summary": "2026-11-09 wiki refresh: display/KMS live, direct-GL submissions, X/GLX completion wall", + "timestamp": "2026-11-09T17:59:26Z", "title": "The Execution Frontier" }, "The Guest Stack and CUDASW": { @@ -343,20 +343,20 @@ }, "The Host Module (vgsp.ko)": { "file": "Host-Module.wiki", - "new_revid": 24021, - "old_revid": 23981, - "source_sha": "e2af9d5d4ca0d65f", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:35Z", + "new_revid": 24037, + "old_revid": 24021, + "source_sha": "3c51bf95d79d3055", + "summary": "2026-11-09 wiki refresh: display/KMS bring-up (NvKms, /dev/dri, GL 4.6), direct-GL channel submissions, current X/GLX completion wall", + "timestamp": "2026-11-09T17:57:42Z", "title": "The Host Module (vgsp.ko)" }, "The vGSP Execution Plane (vEP)": { "file": "Execution-Plane.wiki", - "new_revid": 24013, - "old_revid": 23967, - "source_sha": "f6df28da809fbc57", - "summary": "2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces", - "timestamp": "2026-10-30T17:06:23Z", + "new_revid": 24045, + "old_revid": 24034, + "source_sha": "9442e74fb7126236", + "summary": "2026-11-09 wiki refresh: display/KMS live, direct-GL submissions, X/GLX completion wall", + "timestamp": "2026-11-09T17:59:27Z", "title": "The vGSP Execution Plane (vEP)" }, "UVM in the Guest": { diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md index c8d42cc..e8efcc3 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-10-30, tree `master @ b4930168`. +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories are labelled as such. @@ -95,14 +95,16 @@ breadth and hardening around it: ### A parallel frontier: 3D graphics Graphics execution shares this page's submission and completion machinery but -runs a different engine workload. The story so far: the X server and GLX run -on the emulated vGPU; the emulation captures the X server's graphics-class -stream and the engine executes it — both as a verbatim 3D method-stream replay -and as a synthesized launch that retires real `sm_75` SASS — and the guest -Vulkan pipeline runs end to end (device → command buffer → fence → readback). -What is missing is **rendered pixels**: every frame is still black, and the -program-delivery/program-VA-mapping pair is the working frontier. The full -picture lives on [`Graphics-Execution.md`](Graphics-Execution.md). +runs a different engine workload. The display and GL stacks now run end to +end in the guest: the emulated display engine serves the modeset push buffers, +nvidia-modeset/NvKms registers (`/dev/dri`), X settles, `glxinfo` reports +OpenGL 4.6.0 with direct rendering, and GZDoom obtains a real GL context; the +direct GL client's GR and CE channels submit and retire, and the X server's +DDX kick channel is decoded. What is missing is **rendered pixels**: the +remaining wall is the X GLX context-creation completion (with the client's +kick-slot word), and every frame is still black. The guest Vulkan pipeline +runs end to end but its inline-to-memory upload arm remains the named gap. +The full picture lives on [`Graphics-Execution.md`](Graphics-Execution.md). No breadth beyond these is claimed: Windows guests, migration and performance numbers remain planned. @@ -158,10 +160,11 @@ different emulated VRAM sizes and multiple guests coexist at the device level (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress. -**Issue D — the graphics pixel frontier.** The engine executes graphics method -streams, but no rendered (non-black) frame has been produced yet; program -delivery and program-VA mapping are the named blockers -([`Graphics-Execution.md`](Graphics-Execution.md)). +**Issue D — the graphics pixel frontier.** The display/KMS stack and the GL +client now run end to end (NvKms registers, X settles, GL 4.6, direct-GL +channels submit and retire), but no rendered (non-black) frame has been +produced yet; the X GLX context-creation completion and the client kick-slot +word are the named blockers ([`Graphics-Execution.md`](Graphics-Execution.md)). ## 6. Lines of investigation (live) diff --git a/wiki/Execution-Plane.md b/wiki/Execution-Plane.md index 10e3379..03a7bc9 100644 --- a/wiki/Execution-Plane.md +++ b/wiki/Execution-Plane.md @@ -8,7 +8,7 @@ > when the two disagree, the docs tree wins. Front door: > [`../docs/README.md`](../docs/README.md). -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented, default-off or parameter-gated; `[wip]` partial; `[wall]` current blocker; `[target]` named success latch; `[planned]` designed, not built. @@ -142,11 +142,14 @@ guest: push + QMD + GPFIFO entry + doorbell (BAR0 0x88704) * **Multiple clients and per-guest isolation.** Two guests with different emulated VRAM sizes coexist at the device level; per-guest execution isolation for simultaneous CUDA guests is in progress. -* **The graphics pixel frontier.** Graphics work now rides this plane in two - lanes (verbatim 3D method-stream replay and synthesized launches) and the - engine retires real graphics streams — but no rendered (non-black) frame - has been produced yet. Program delivery and program-VA mapping are the - named blockers; the lanes and the ladder are on +* **The graphics pixel frontier.** Graphics work rides this plane in three + shapes (verbatim 3D method-stream replay, synthesized launches, and the + direct GL client's own GR/CE channels, which now submit and retire). The + display/KMS path is served by the emulated display engine (modeset push + buffers plus the notifier/`UPDATE` completion), so NvKms registers, X + settles and GL 4.6 is live. No rendered (non-black) frame has been produced + yet: the X GLX context-creation completion and the client kick-slot word are + the named blockers; the lanes and the ladder are on [`Graphics-Execution.md`](Graphics-Execution.md). ## 6. Portability @@ -169,7 +172,8 @@ near-native performance program. The unsolved future classes — multi-tenant fairness, fault replay/cancel, context switching between tenants, hostile-guest hardening, and version drift — each have a proactive design direction in the canonical document. 3D graphics reuses this pipeline and now executes across -two lanes ([`Graphics-Execution.md`](Graphics-Execution.md)); it adds engine +three shapes, including the direct GL client's own GR/CE channels +([`Graphics-Execution.md`](Graphics-Execution.md)); it adds engine breadth (video/image), more channels and synchronisation volume, and a much larger method vocabulary, but not a new plane. diff --git a/wiki/FAQ.md b/wiki/FAQ.md index 35554e5..4fa79aa 100644 --- a/wiki/FAQ.md +++ b/wiki/FAQ.md @@ -5,7 +5,7 @@ > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md); > the docs tree wins on disagreement. -Status: 2026-10-30, tree `master @ b4930168`. +Status: 2026-11-09, tree `master @ 4acc81e8`. ## Project and positioning @@ -37,12 +37,14 @@ progress). This is the project's known status, not a misconfiguration — see [`Execution-Frontier.md`](Execution-Frontier.md). **Can I run OpenGL or Vulkan applications in the guest?** -Partially, and it is an active frontier. The X server and GLX come up on the -emulated vGPU with the stock driver, the engine executes real GL method -streams (verbatim 3D replay plus synthesized launches), and the guest Vulkan -pipeline runs end to end (device → command buffer → fence → readback). -Rendered (non-black) frames are the remaining wall — see -[`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and +Partially, and it is an active frontier. The display/KMS stack and the X +server now run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms +registers (`/dev/dri`), `glxinfo` reports OpenGL 4.6.0 with direct rendering, +GZDoom obtains a real GL context, and the direct GL client's GR and CE channels +submit and retire; the guest Vulkan pipeline runs end to end (device → command +buffer → fence → readback). Rendered (non-black) frames are the remaining wall +— the X GLX context-creation completion and the client kick-slot word are the +current gates — see [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and [`Graphics-Execution.md`](Graphics-Execution.md). **How fast is it?** 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. diff --git a/wiki/Host-Module.md b/wiki/Host-Module.md index dbbe68c..3f2276a 100644 --- a/wiki/Host-Module.md +++ b/wiki/Host-Module.md @@ -6,7 +6,7 @@ > source: [`../docs/03-architecture/06-host-module-and-hybrid-model.md`](../docs/03-architecture/06-host-module-and-hybrid-model.md); > the docs tree wins on disagreement with this page. > -> Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` observed with +> Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` observed with > the stock guest driver; `[wip]` demonstrated live, being productized; > `[gated]` implemented default-off behind supervised gates; `[wall]` known > blocking limit; `[target]` designed, not built; `[planned]` roadmap. @@ -108,9 +108,17 @@ firmware as the resource-manager server**, with emulation as the control plane. CE copies, release and fault relay are implemented default-off and verified live [gated]; forwarded guest CUDA launches execute on the engine with engine-authored completions relayed to the guest, and graphics method -streams execute in two lanes ([`Execution-Frontier.md`](Execution-Frontier.md), +streams execute in three shapes, including the direct GL client's own GR/CE +channels ([`Execution-Frontier.md`](Execution-Frontier.md), [`Graphics-Execution.md`](Graphics-Execution.md)). +The same plane carries the display/modeset path [live in the campaign +configuration]: the module serves the guest display engine's push-buffer +channels (core `0xc57d`, window `0xc57e`, immediate/window `0xc57b`), authors +the notifier/`UPDATE` completion (with a force-retry for a deferred event), +and lets nvidia-modeset/NvKms register (`/dev/dri`), X settle and GL clients +obtain a real GL context. The display-capability seam is parameterised. + ## 6. Debug parameters `/sys/module/vgsp/parameters/*` makes guest memory and the emulated device diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md index 8264620..cc35fe6 100644 --- a/wiki/OpenGL.md +++ b/wiki/OpenGL.md @@ -12,7 +12,7 @@ > [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md) > (the guest stack). The docs tree wins on disagreement. -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` observed with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` observed with the stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]` defined success state. @@ -41,9 +41,12 @@ Two forms of operation exist, and both are visible in the guest: which executes it against its own GL context. Here the X server's channel carries the graphics stream. -On the emulated vGPU the readable command source today is the **X server's -channel**, whose graphics-class (`0xC597`, `TURING_A`) sections the emulation -captures and executes ([`Graphics-Execution.md`](Graphics-Execution.md) §3). +On the emulated vGPU the readable command sources today are the **direct GL +client's own channels** — the GR channel `0xbeef0100` and its CE siblings +`0xbeef0101`/`0xbeef0102` — and the **X server's channels**, whose +graphics-class (`0xC597`, `TURING_A`) sections the emulation captures and +whose DDX kick channel (`0xbfef0002`) is decoded from its ring head +([`Graphics-Execution.md`](Graphics-Execution.md) §3). ## 2. What an NVIDIA GL frame involves (observed shapes) @@ -55,9 +58,10 @@ captures and executes ([`Graphics-Execution.md`](Graphics-Execution.md) §3). data, and draw-issuing methods that drive the fixed-function pipeline (vertex fetch, primitive assembly, rasterisation, fragment work, ROP). * **Program/descriptor delivery** — the driver uploads shader code and - descriptors through its copy/utility-channel inline-data path; this upload - is the piece the emulation must materialise for the engine to run *real* - programs ([`Vulkan.md`](Vulkan.md) has the mirror-image of the same gap). + descriptors through its copy/utility-channel inline-data path. The GL draw + path decodes these uploads and the engine executes the draw; Vulkan's + inline-to-memory arm is the remaining mirror-image gap + ([`Vulkan.md`](Vulkan.md)). * **Present** — the X server's present/readback path runs as light 2D-class and copy-engine operations; the emulator decodes and executes those shapes. @@ -68,14 +72,16 @@ Rated honestly, against the milestone ladder in the plan: | Item | State | |---|---| | X server initialises on the emulated vGPU (driver push-DMA sanity test, ScreenInit) | `[live]` | -| `glxinfo -B` reports the NVIDIA renderer (OpenGL 4.6.0, driver 570.144) | `[live]` | +| nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`); `nvidia-smi -L` enumerates | `[live]` (campaign configuration) | +| `glxinfo -B` reports the NVIDIA renderer (OpenGL 4.6.0, driver 570.144, direct rendering) | `[live]` | | The X driver's RC-watchdog channel registers and its notifier is authored | `[live]` | -| GZDoom launches and runs on the emulated vGPU | `[live]` (menu/frames black) | +| GZDoom obtains a real GL context; windowed GZDoom reaches renderer startup | `[live]` (menu/frames black) | | X server's `0xC597` graphics section captured and decoded | `[live]` | | Engine executes a launch built from the captured section (real `sm_75` SASS retired) | `[live]` | | Verbatim 3D method-stream replay retired by the engine, no MMU fault | `[live]` | -| Direct GL client: device-init gate handled; client channels allocate; readback path returns with no GL error | `[wip]` | -| Direct GL client submits its per-frame draws | `[wall]` (no submissions observed) | +| Direct GL client: device-init gate handled; client channels allocate; readback path returns with no GL error | `[live]` | +| Direct GL client submits and retires its per-frame draws (GR `0xbeef0100`, CE `0xbeef0101`/`0xbeef0102`); DDX kick channel decoded | `[live]` | +| X GLX context-creation completion and the client kick-slot word | `[wall]` | | Non-black rendered frames through the emulated vGPU | `[wall]` | | 60 fps sustained, no forcing (M-GL4) | `[target]` | @@ -96,8 +102,11 @@ The graphics plan defines M-GL1 (client context-init decodes and executes; the client leaves its retry loop), M-GL2 (`glxgears` non-black), M-GL3 (GZDoom GL non-black through the mdev), M-GL4 (60 fps, no forcing), M-GL5 (two VMs, two mdevs), M-GL6 (split-screen video). The project sits **between M-GL1 and -M-GL2**: the interface work is done — the client creates its channels and its -readback path is clean — and pixels are the gate. +M-GL2**: the interface and execution work is done — the display/KMS stack +registers, X settles, the client submits and retires its GR/CE channels, and +the engine authors stores — and the remaining gate is the X GLX +context-creation completion plus the client kick-slot word before the first +rendered frame. ## 6. What is not claimed diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md index 976430d..8f1a02b 100644 --- a/wiki/Physical-GPU-Backend.md +++ b/wiki/Physical-GPU-Backend.md @@ -5,7 +5,7 @@ > guest-facing emulation. Canonical sources: [`../docs/03-architecture/08-physical-gpu-integration.md`](../docs/03-architecture/08-physical-gpu-integration.md) > and [`../docs/03-architecture/11-physical-backend-guest-wiring.md`](../docs/03-architecture/11-physical-backend-guest-wiring.md); the docs tree wins on disagreement. -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented default-off; `[wip]` partially built; `[wall]` current blocker; `[target]` planned end state. @@ -109,7 +109,7 @@ FAIL a failed mutating operation parks the device in a locked fail-safe; | Host RM client and first real engine work (static config, real objects, 4 KiB CE copy) | done `[live]` | | Guest-copy forwarding, deferred release, hardware-primary copies, engine-authored relay, fault relay | verified live (seams parameterised and fail-open); the staged-transfer class is under repair `[live]` | | CUDA kernel execution (`vectorAdd` and further clients) | done `[live]` — stock guest CUDA clients (vector-add, matrix-multiply, transformer) execute on the physical engine with verified results and engine-authored completions relayed to the guest | -| Graphics method-stream execution (verbatim 3D replay, synthesized launches) | `[wip]` — the engine retires real graphics streams and launched kernels; rendered pixels are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) | +| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and the direct GL client's GR/CE channels submit; rendered pixels are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) | ## 7. The execution frontier @@ -119,9 +119,11 @@ engine: the inline launch descriptor installs and is read, the grid dispatches, the engine authors the completion, the host relays it, and the guest's synchronisation wait resolves — verified on fresh boots with the vector-add, matrix-multiply and transformer clients. Graphics work rides the -same machinery in two lanes (a verbatim 3D method-stream replay and -synthesized launches) and executes on the engine; producing rendered pixels -is the graphics frontier. The remaining compute work is the staged-transfer +same machinery in three shapes (a verbatim 3D method-stream replay, +synthesized launches, and the direct GL client's own GR/CE channels) and +executes on the engine; the display/KMS stack registers and X settles, so the +remaining graphics gate is the X GLX context-creation completion before +rendered pixels. The remaining compute work is the staged-transfer class (under repair), the every-boot acceptance campaign, and per-guest execution isolation — see [`Execution-Frontier.md`](Execution-Frontier.md) and diff --git a/wiki/Project-Goals.md b/wiki/Project-Goals.md index bbce3e3..2ba2e40 100644 --- a/wiki/Project-Goals.md +++ b/wiki/Project-Goals.md @@ -10,7 +10,7 @@ > [`Execution-Frontier.md`](Execution-Frontier.md) and > [`Graphics-Execution.md`](Graphics-Execution.md). -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` working with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` working with the stock guest driver; `[wip]` in progress; `[planned]` designed, not built; `[target]` bring-up ahead; `[non-goal]` explicitly out of scope. @@ -51,7 +51,7 @@ drivers, no license.** | Stock guest driver initialisation | The unmodified driver probes, initialises and enumerates as on bare metal (`nvidia-smi`) | `[live]` — TU104 reference platform | | Full CUDA driver-API surface | Context creation, allocation, copies, free, destroy complete with correct results | `[live]` — the driver-API smoke prints `ALL OK`; the 64-byte payload round-trips | | CUDA kernel execution on real hardware | Verified guest kernels execute on the physical GPU, with engine-authored completions waking the guest | `[live]` — vector-add, matrix-multiply and transformer clients green on fresh boots; the staged-transfer class, the every-boot acceptance campaign and per-guest isolation are in progress ([`Execution-Frontier.md`](Execution-Frontier.md)) | -| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — Xorg/GLX run, the engine executes GL method streams (verbatim 3D replay + synthesized launches); rendered pixels are the frontier ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run (NvKms registers, `glxinfo` OpenGL 4.6.0 direct, GZDoom obtains a real GL context), and the direct GL client's GR/CE channels submit and retire; the X GLX context-creation completion and the first rendered frame are the frontier ([`OpenGL.md`](OpenGL.md)) | | Vulkan | Stock guest Vulkan applications render real pixels | `[wip]` — the pipeline runs end to end (device → command buffer → fence → readback); frames are black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) | | Windows guests (DirectX, CUDA) | A stock WDDM driver and stock D3D/CUDA applications run in Windows guests | `[target]` — not started; same emulation target ([`DirectX.md`](DirectX.md)) | | Video (NVENC/NVDEC) | Encode/decode through the emulated device | `[planned]` | diff --git a/wiki/Project-Plan.md b/wiki/Project-Plan.md index 697e95f..1a10eec 100644 --- a/wiki/Project-Plan.md +++ b/wiki/Project-Plan.md @@ -15,7 +15,7 @@ > [`../docs/06-portability/03-device-validation-and-porting-sequence.md`](../docs/06-portability/03-device-validation-and-porting-sequence.md); > the docs tree wins on disagreement. -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[done]`, `[active]`, +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[done]`, `[active]`, `[ahead]` — the plan's own state vocabulary, distinct from the goal tags. ## 1. How the plan works @@ -44,7 +44,7 @@ itself: |---|---|---|---| | **P0 — Platform** | Emulated vGPU device, GSP boot and GSP-RM emulation, stock guest driver initialisation | Driver-API smoke green (`ALL OK`) = evaluation rung 2 | `[done]` | | **P1 — First execution (compute)** | Guest CUDA kernels executing on the physical GPU, with engine-authored completions; then hardening | Verified clients + engine-authored completion = rung 3 core; hardening: staged-transfer class, every-boot acceptance, per-guest isolation | `[active]` — execution green; hardening in progress | -| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2; the pixel walls are named | +| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2; the display/KMS and direct-GL channel work is live; the X GLX completion and first rendered frame are the walls | | **P3 — Sustained and multi-tenant** | Frame rates without assistance; multiple VMs sharing the GPU with measured fairness; soak-stable operation | Graphics M-GL4 (60 fps, no forcing) and M-GL5 (two VMs, two mdevs); CUDA battery + soak; per-guest execution isolation = rungs 4/5 | `[ahead]` | | **P4 — Breadth** | Video (NVENC/NVDEC), Windows/DirectX guests, live migration, non-KVM hypervisor transports | Per-case bring-up gates plus the matrix's evidence expectations | `[ahead]` | | **P5 — Scale and portability** | New GPU generations and driver families carried forward; published performance programme | A profile + measured delta per version, validated on hardware; A/B numbers published per the measurement contract | `[ahead]` | @@ -57,10 +57,10 @@ available (P5 runs across the whole plan). Ranked, in dependency order: -1. **Graphics pixels (P2).** Three walls, each with a named next fix: the GL - client's submissions; program (SASS) delivery plus program-VA mapping; then - non-black frames. Full detail: - [`Graphics-Execution.md`](Graphics-Execution.md) §6. +1. **Graphics pixels (P2).** The client and display stacks execute; the + named walls are the X GLX context-creation completion (`_nv018351rm` plus + the X DDX/GLX reply), the client kick-slot word, then non-black frames. + Full detail: [`Graphics-Execution.md`](Graphics-Execution.md) §6. 2. **Compute hardening (P1).** The staged-transfer class (failure modes proven, fixes in flight); the every-boot acceptance campaign; per-guest execution isolation. Detail: @@ -72,9 +72,11 @@ Ranked, in dependency order: evidence, and only then moves in the matrix. Recently closed, as evidence the gates work: the boot-poisoning defect and the -post-reboot client-stall defect (compute reproducibility); the X/GL wall (the -X server and GLX run on the emulated vGPU); the engine executing the real GL -method stream; and the guest Vulkan pipeline running end to end. +post-reboot client-stall defect (compute reproducibility); the display/KMS +bring-up (NvKms registers, X settles, GL 4.6 and a real GZDoom GL context); +the UVM channel-pool tracker; the direct-GL GR release and CE ring discovery; +the X DDX kick-channel decode; and the guest Vulkan pipeline running end to +end. ## 4. The gates diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 944e525..96e55db 100644 --- a/wiki/Project-Status.md +++ b/wiki/Project-Status.md @@ -10,7 +10,7 @@ > (the execution frontier). When this page and the docs disagree, the docs tree > wins. -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented, default-off or behind supervised gates; `[wip]` partially implemented; `[wall]` current blocker; `[target]` named success state; `[planned]` designed, not built. @@ -25,9 +25,10 @@ named success state; `[planned]` designed, not built. | Stock guest driver probe and `nvidia-smi` (TU104) | `[live]` working | | CUDA userspace init and the driver-API smoke (`cuInit`, device enumeration, `cuCtxCreate`, allocation, copies, free, destroy) | `[live]` working — the smoke prints `ALL OK` and the 64-byte payload round-trips exactly | | Guest CUDA kernel execution on real hardware | `[live]` working — verified green on fresh boots: the vector-add (`VADD n=32768 bad=0`), matrix-multiply (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, `FFN4 layers=4 bad=0`) clients print `STATUS OK`, engine-authored completions relay to the guest and its synchronisation waits resolve. A ring-block ownership defect that could stall the first client after a reboot was root-caused and fixed. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; the failure modes are proven and under repair) and per-guest execution isolation for simultaneous CUDA guests | -| Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend, and graphics method streams execute on the engine in two lanes ([`Graphics-Execution.md`](Graphics-Execution.md)) | +| Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend, and graphics method streams execute on the engine ([`Graphics-Execution.md`](Graphics-Execution.md)) | +| Display and KMS on the emulated vGPU (nvidia-modeset/NvKms, `/dev/dri`, X) | `[live]` in the campaign configuration — the emulated display engine serves the guest's display push-buffer channels (notifier plus `UPDATE -> FINISHED`), nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`), `nvidia-smi -L` enumerates and X settles; the display-capability seam is parameterised ([`Graphics-Execution.md`](Graphics-Execution.md)) | | Multi-tenant isolation (mdev per VM, per-context page directories) | `[wip]` device-level coexistence works — multiple mediated devices with different emulated VRAM sizes and multiple guests coexist (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress | -| OpenGL (3D graphics) | `[wip]` — the X server and GLX run on the emulated vGPU with the stock driver, the engine executes real GL method streams (verbatim 3D replay plus synthesized launches), and a direct GL client creates its channels and readback path; rendered (non-black) frames are the frontier ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers and X settles; `glxinfo` reports OpenGL 4.6.0 with direct rendering; GZDoom obtains a real GL context; the direct GL client's GR and CE channels submit and their releases land. **No rendered pixels yet:** the remaining gate is the X GLX context-creation completion (the X server spins in its RM ioctl path) plus the client kick-slot word; fullscreen GZDoom's mode set still wedges X, so the campaign uses a settled X + windowed GZDoom ([`OpenGL.md`](OpenGL.md)) | | Vulkan (3D/compute) | `[wip]` — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback) and the engine executes translated launches; frames are still black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) | | DirectX / Windows guests | `[planned]` (target) — no Windows guest booted yet; the architecture is the same emulation target ([`DirectX.md`](DirectX.md)) | | Video (NVENC/NVDEC) | `[planned]` | @@ -64,8 +65,8 @@ The project's definition of done for CUDA requires all of the following Until every gate holds, the honest formulation is: **initialization, the driver-API path and kernel execution on the physical GPU work and verify; -the staged-transfer class, per-guest isolation and the graphics pixel -frontier remain.** +the staged-transfer class, per-guest isolation and the graphics +GLX-completion/first-frame frontier remain.** ## 3. How to see it yourself @@ -73,8 +74,10 @@ The reference setup takes about half an hour from a fresh host ([`Install-and-First-Run.md`](Install-and-First-Run.md)); the current expected outcome is exactly the ladder above — driver probe, `nvidia-smi`, the full driver-API smoke, and guest CUDA kernels executing and verifying on the -physical GPU. On the graphics side the same setup brings up the X server and -GLX on the emulated vGPU ([`OpenGL.md`](OpenGL.md)). The +physical GPU. On the graphics side the same setup brings up the display/KMS +stack and the X server on the emulated vGPU (`glxinfo` reports OpenGL 4.6.0 +with direct rendering); rendered pixels remain the frontier +([`OpenGL.md`](OpenGL.md)). The risc-v-gsp-rm-debugger workbench ([`Riscv-GSP-RM-Debugger.md`](Riscv-GSP-RM-Debugger.md)) is the host-side tooling used to study the firmware side of that frontier. diff --git a/wiki/System-Overview.md b/wiki/System-Overview.md index 685926c..5f5b8dc 100644 --- a/wiki/System-Overview.md +++ b/wiki/System-Overview.md @@ -7,7 +7,7 @@ > and [`../docs/03-architecture/10-interaction-and-scheduling.md`](../docs/03-architecture/10-interaction-and-scheduling.md) > for the full picture); the docs tree wins on disagreement. -Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented default-off; `[wip]` partial; `[wall]` current blocker; `[target]` designed end state. @@ -133,14 +133,19 @@ RPC from the guest to "firmware": 5. CE-class copies are forwarded to the physical copy engine (default off) with engine-authored semaphore releases and a fault relay. For GR (graphics/compute), forwarded guest CUDA launches execute on the engine - with engine-authored completions relayed to the guest, and graphics - method streams execute in two lanes - ([`Graphics-Execution.md`](Graphics-Execution.md)); rendered 3D pixels are - the graphics frontier ([`Execution-Frontier.md`](Execution-Frontier.md)). -6. On the graphics side, the X server and GLX come up on the emulated vGPU - with the stock driver (`glxinfo` reports the NVIDIA renderer); the guest - Vulkan pipeline runs end to end; rendered (non-black) frames are the open - frontier ([`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md)). + with engine-authored completions relayed to the guest; the direct GL + client's GR and CE channels submit and retire, and graphics method streams + execute in three shapes ([`Graphics-Execution.md`](Graphics-Execution.md)); + rendered 3D pixels are the graphics frontier + ([`Execution-Frontier.md`](Execution-Frontier.md)). +6. On the graphics side, the emulated display engine serves the modeset push + buffers and the display notifier/completion, so nvidia-modeset/NvKms + registers (`/dev/dri`), X settles and `glxinfo` reports OpenGL 4.6.0 with + direct rendering; GZDoom obtains a real GL context, the direct GL client's + channels submit, and the guest Vulkan pipeline runs end to end. The + remaining gate is the X GLX context-creation completion and the first + rendered (non-black) frame ([`OpenGL.md`](OpenGL.md), + [`Vulkan.md`](Vulkan.md)). ## 6. Where the detail lives |