diff options
Diffstat (limited to 'wiki/OpenGL.md')
| -rw-r--r-- | wiki/OpenGL.md | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md index c499967..7445d12 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-11-09, tree `master @ bb802909`. Tags: `[live]` observed with the +Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` observed with the stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]` defined success state. @@ -80,17 +80,17 @@ Rated honestly, against the milestone ladder in the plan: | 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]` | -| CB-DIAG decodes the draw's fixed-CB stream (1492 `0x3800` offsets, 1092 words) | `[live]` | -| Beef GR channel `0xbeef0100` captures real GL draw sections | `[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]` | +| RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[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 submits and retires its per-frame draws (GR `0xbeef0100`, CE `0xbeef0101`/`0xbeef0102`); DDX kick channel decoded | `[live]` | | X server survives the run on a 12 GB guest (the DDX's 4 GB sysmem allocation forces the size) | `[live]` | -| Beef GR ring resolves deterministically; fixed-CB scan runs every cycle | `[wall]` | -| Fixed-CB image's `0x80` MVP block becomes non-zero | `[wall]` | -| Render-target bind matches the copy-out page | `[wall]` | +| Direct-GL channel `0xbfef0002` submits a captured draw (`ops_runs>0`) | `[wall]` | +| Window/screen present completes without wedging X (ivshmem frame path) | `[wall]` | +| X startup/RM stability (`0x51`, vmalloc 96 GB) | `[wall]` | | NVIDIA Vulkan ICD creates a device | `[wall]` | -| Non-black rendered frames through the emulated vGPU | `[wall]` | +| Non-black screen rendered frames through the emulated vGPU | `[wall]` | | 60 fps sustained, no forcing (M-GL4) | `[target]` | ## 4. How OpenGL runs are verified @@ -112,18 +112,18 @@ 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 and execution work is done — the display/KMS stack registers, X settles, the client submits and retires its GR/CE channels, and -the guest's GL draws forward and execute on the physical GPU and X is -reliable. The remaining gates are the beef GR ring resolution, the fixed-CB -image's zero MVP block, and the render-target bind before the first rendered -frame. +the first real GPU readback is proven (pbuffer `pixel=ff0000ff`). The +remaining gates are the direct-GL client's draw submission/capture on +`0xbfef0002` and the window/screen present path (a window draw currently +wedges X) before the first rendered screen frame. ## 6. What is not claimed * No OpenGL frame from the emulated vGPU has produced real rendered pixels - yet; every capture so far is black. glxgears completes swaps and its GL - draws execute on the physical GPU, but the replayed draw still writes 0 - pages: the beef ring, the fixed-CB image's zero MVP block and the - render-target bind are unresolved. + yet; every screen capture so far is black. The pbuffer probe renders and + reads back a red pixel, but the direct-GL client still emits only + setup/notify kicks, and a synchronous window draw wedges X. Those are the + current walls. * No frame-rate or latency numbers. * The published two-VM GZDoom demo videos used the labelled `virtio-gpu`/ `virgl` path, not the emulated vGPU. |