diff options
Diffstat (limited to 'wiki/Physical-GPU-Backend.md')
| -rw-r--r-- | wiki/Physical-GPU-Backend.md | 23 |
1 files changed, 14 insertions, 9 deletions
diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md index bbca084..976430d 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-20, tree `master @ 16291c72`. Tags: `[live]` proven with the +Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented default-off; `[wip]` partially built; `[wall]` current blocker; `[target]` planned end state. @@ -107,20 +107,25 @@ FAIL a failed mutating operation parks the device in a locked fail-safe; | Power domain held active across the ownership window | verified across supervised cycles `[live]` | | Real GSP boot by the module, through init-done and clean release | done, no reboot on clean cycles `[live]` | | 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 large-buffer staged-transfer class is under repair `[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)) | ## 7. The execution frontier The RM client ladder reaches the compute engine (a GR0 channel plus a -compute-class object). Forwarded guest CUDA launches now execute on the +compute-class object). Forwarded guest CUDA launches execute on the 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. The leading edge is the -large-buffer staged-transfer class (under repair), reproducibility across -fresh boots, and per-guest execution isolation — see -[`Execution-Frontier.md`](Execution-Frontier.md). +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 +class (under repair), the every-boot acceptance campaign, and per-guest +execution isolation — see +[`Execution-Frontier.md`](Execution-Frontier.md) and +[`Graphics-Execution.md`](Graphics-Execution.md). A failed mutating operation on the backend parks the device in a locked fail-safe that is never auto-retried; recovery is a supervised step. @@ -154,8 +159,8 @@ fail-safe that is never auto-retried; recovery is a supervised step. interface, and tenant policy is a later layer on top ([`GMMU-Multi-Tenant-Protection.md`](GMMU-Multi-Tenant-Protection.md)). * Multiple mediated devices with different emulated VRAM sizes and multiple - guests already coexist at the device level; per-guest execution isolation - for simultaneous CUDA guests is in progress. + guests already coexist at the device level (two guests demonstrated); + per-guest execution isolation for simultaneous CUDA guests is in progress. ## 10. Open questions |