[jamesbraid]

With raster = "wgpu" and the wgpu window, the VPro display composes and presents on the GPU. Until now only an open window ran that path. Nothing in CI could catch it going back to composing every frame, and at an idle IRIX greeter that cost 21 billion display-thread instructions a minute. Hosted runners have no GPU and no display. Screenshots force the CPU path, so they can't see it either.

This makes the display compose only when something it reads may have changed, makes the window's path run with no window, and has the display report what it did:

• odyssey: compose the display only after a command or drawing. The idle fix, reworked after review (below). The display composes when the board has processed a command or register store, the raster unit has finished a job, or the GPU unit has submitted or uploaded; a store to board memory no longer marks anything.
• odyssey: count the display's frames for the monitor. vpro frames [reset] reports frames composed, left unchanged and presented (and how many from the GPU), plus frame time.
• wgpu: present the window's frames into a texture in ci mode. Presenter can draw into an offscreen texture instead of a surface, with the same pipelines and pass. WgpuRenderer keeps its window handles in an optional WindowLink. ci mode with renderer = "wgpu" installs the same renderer offscreen, so Odyssey::frame runs update_on_gpu, present_gpu, present_gpu_frame and Presenter::present. Only acquiring and presenting the surface texture are left out. The default renderer is gl, so other ci runs are unchanged.
• ci: run the wgpu display path on lavapipe. A new wgpu.yml installs Mesa's software Vulkan on ubuntu-24.04 and runs cargo ci-gpu: the wgpu layer, the presenter and the VPro display tests. The tests assert frame counts, not pictures.
• ci: run the IMPACT raster tests on lavapipe, and ci: run the wgpu tests on Windows through lavapipe and on Metal (see CI coverage below).

How the review comment was addressed

The review said that counting every framebuffer write is costly and possibly wrong, because pixels written during rendering may never be shown (the hardware can render to a pbuffer), and asked for compose to trigger when a raster command has been processed or a display register has been updated. That is what the first commit now does, rebased onto the new compose path (prepared readers, compose straight into the screen):

• The per-store mark is gone. VramPtr::store is a plain store again, and the span fill's store_quiet and its mark after the loop are removed.
• One flag, Vram::drawn, set with one store by: write_dispatch after each store to the board's command FIFO or registers; the raster thread after each job, and again when the pipeline has run dry, since a draw's pixels can land after its job; the GPU unit after each batch submit, copy, upload and memory clear. Display registers, the mode and the displayed buffer keep the generations the reader already compared.
• It works the same with the raster unit and the compose on the CPU or the GPU: update_to and update_on_gpu read the same flag. The GPU scan-out no longer forces a compose every frame.
• The mark is a release store taken by an acquire swap before the display reads anything, so a frame composed for a mark sees the drawing it follows. That removed the extra "settling" frame, and its counter in vpro frames.

Worth a close look:

• RasterQueue::mark_drawn and where the raster thread calls it, in particular the mark when the pipeline runs dry. No test pins that one: removing it still passed three runs of the module tests.
• The mark after write_dispatch is per store to the board, not per pixel. Its cost on the draw path was not measured separately.
• Presenter::present's two targets, and the wait on the previous submission that keeps at most two offscreen frames in flight.
• The ci branch in main.rs, and whether the paths filter on wgpu.yml is the right scope.

Evidence

x86-64, RTX 4090 over Vulkan, release build with thin LTO. V12 Tezro (2 CPUs, jitv2) at the IRIX greeter in ci mode with no window, raster = "wgpu", renderer = "wgpu". 60 s idle, then 28 s with 40 pointer moves. User instructions of the display thread by perf stat -e instructions:u, runs ordered A B B A A B B A, one guest at a time. A is current main (9605704), B is this branch.

	idle minute	40 pointer moves, 28 s
main, 4 runs	21.426, 21.424, 21.412, 21.420 G	9.995, 9.999, 9.992, 9.996 G
this branch, 4 runs	243.6 to 244.2 M	132.5 to 133.0 M

Main has no offscreen present, so it composes and reads back on the CPU path every frame; the branch runs the window's path. Two controls with the same build:

• Branch with the skip for unchanged frames disabled (the same path as the branch): idle 2.901 and 2.896 G, pointer window 1.355 and 1.353 G, all 3905 frames composed and presented.
• First commit alone, CPU readback path, against main (A E E A): idle 3.905 M against 21.43 and 21.41 G; pointer window 235.4 and 235.3 M against 10.00 and 9.99 G.

vpro frames on the branch: idle minute 0 composed, 3904 unchanged, 650 presented, all from the GPU. 40 pointer moves compose exactly 40 of 2108 frames. Screenshots at the greeter, after typing three characters and after Enter (the greeter changes its window), and 20 s later hash identically on main and on the branch in all 8 runs; typing composed 6 frames and Enter 3 more, and the screen changed each time.

Checks:

• cargo check --workspace --all-targets passes at each of the six commits with default features, --features iris/jitv2 and --features iris/wgpu.
• The odyssey, wgpu and ui module tests pass, default and with the wgpu feature (that run has no GPU, so the GPU tests skip).
• VPRO_GPU=1 WGPU_BACKEND=vulkan cargo ci-gpu on the RTX 4090: all selected tests pass.
• With the skip disabled, the_offscreen_wgpu_renderer_presents_on_the_gpu_only_what_changed and the_gpu_scanout_composes_only_a_changed_frame fail. Removing the mark in write_dispatch fails two display tests, and removing the raster thread's marks fails a_finished_raster_job_marks_the_display.

Not verified:

• cargo ci-gpu on lavapipe was not run after the rework. It passed on an earlier version of this branch, and the workflow has never run on GitHub.
• No real window was opened, so surface acquire and present, Fifo pacing and how the window looks are still manual checks.
• arm64 is unmeasured. Each mark is a release store, one per job or per store to the board, which is stlrb there.
• The counters' own cost was measured on the earlier compose rule (4.58 M to 5.16 M instructions in an idle minute, about 160 a frame).
• With VPRO_GPU=1, two VPro golden scenes differ from their goldens by one colour step, as they do on main. The CI profile leaves them out.

CI coverage

The job also runs the IMPACT raster tests (dev::mgras::wgpu), which compare the GPU raster unit with the interpreter on random draws. They run one at a time in a nextest test group. At four at a time, three of them timed out at the 30 s GPU wait on their first submission, which builds the raster pipelines: lavapipe starts a thread per core in every test process and the processes fight over four cores. Two at a time passed both probe runs but timed out once on this pull request; one at a time passed every run (about 145 s for the set). The wait is unchanged.

Two more jobs run the same ci-gpu set. On windows-latest, lavapipe comes from the mesa-dist-win 26.2.6 release (pinned by sha256) and its manifest is registered under HKLM\SOFTWARE\Khronos\Vulkan\Drivers, because the loader ignores VK_DRIVER_FILES when the runner is an administrator. 45 tests pass in 76 s. The raster tests are left out there: each sweep takes 30 to 40 s (3 to 5 s on Linux), and in parallel their first wait times out. On macos-26 wgpu gets a real Metal adapter ("Apple Paravirtual device") and all 57 tests pass in 107 s. First runs without a build cache took about 7 minutes on Linux, 12 on Windows and 15 on macOS; pull requests restore main's cache.

[techomancer]

counting every framebuffer write is very costly. and possibly incorrect. we dont really know if the pixels written during rendering are actually used by next frame or not, because the hardware could very well render to pbuffer
we should trigger compose if any command has been processed for raster. or if any display register has been updated. this is much simpler logic. runs at much lower frequency and is independent on whether gpu or cpu rendering or composition is used.