diff options
| -rw-r--r-- | docs/04-implementation/04-real-render-walls.md | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md index 3744891..b080732 100644 --- a/docs/04-implementation/04-real-render-walls.md +++ b/docs/04-implementation/04-real-render-walls.md @@ -1030,3 +1030,24 @@ shader writes position and reads the attribute stream; why the client's own upload accounting still reports zero applied bytes; whether the vertex fetch bases hold the geometry the guest writes; and a positive control that draws a constant-position full-screen triangle with a colour pixel shader. + +The shader-content wall was then broken open: the driver's real program +images were recovered from the init-push payload (the guest had already freed +the page, so the bytes were read from the host RAM backing store). Disassembly +of the 128-byte SPH headers plus SASS shows a genuine pixel shader (IPA/MUFU/ +FMUL/EXIT) and two genuine vertex shaders (ALD attribute loads, FFMA/FMUL, +MUFU.RSQ transform path; 1408 and 1536 bytes). Feeding the pixel image through +the existing per-stage program path (`ps_hex`) and switching the synthesized +viewport to raw scale/offset words produced the first engine render-target +writes on record: three of the 900 render-target pages changed, three pages +were copied back from the bounce buffer, the whole-vidmem page hash saw a +launch-page change, and the captured root window contains a handful of +non-black pixels. The pipeline now runs vertex -> raster -> pixel -> render +target end to end; what remains is coverage - the viewport/clip transform +collapses the geometry to a few isolated pixels - plus a delivery detail: a +window whose vertex-shader upload was never captured has an empty VTG page, +and a vertex image applied only to the host shadow is lost when the window-0 +shadow is re-copied from the guest page. The next work is to deliver the +captured vertex image into the guest page for every window and to calibrate +the viewport against the client's own CALL(33) arguments or a synthetic +full-screen control draw. |