mirror of
https://github.com/storytold/photocraft.git
synced 2026-10-25 10:27:07 -06:00
skylar taylor-barrick
5c7c847923
`composite_ms` measures encoding and submitting a composite, not running it: on a 24 MP refresh it read 7.7 ms for work the GPU spent ~171 ms on, so nothing in the app could see a regression that moved work onto the GPU. A timestamp is written on the GPU timeline at the start and end of every command encoder a refresh submits, and the spans are summed and read back asynchronously. Nothing waits, so a measurement arrives a frame or two later and carries the pixel count of the refresh it belongs to. It is reported as a new `Option<f64>` `perf.gpu_ms`; `composite_ms` keeps its meaning, so its consumers are untouched. At 24 MP it reports 83.9 ms against a waited wall clock of 88.4 ms, where the app previously said 3.1 ms. What it leaves out, documented in the module: queue-level uploads, which wgpu runs in its own command buffer ahead of ours, and the end-of-batch writeback after the last timestamp. That is ~5 % of the reported time here and proportional to the composite, against the ~22x of the number it replaces. Unavailable rather than wrong: without TIMESTAMP_QUERY and TIMESTAMP_QUERY_INSIDE_ENCODERS the timer is never built and `gpu_ms` is None — on older drivers, the CPU compositor, wasm, and Apple silicon, whose GPUs support counter sampling only at stage boundaries. `PHOTOCRAFT_NO_GPU_TIMING` suppresses both the timer and the feature request. Pass-boundary timestamps would cover Apple silicon and need only TIMESTAMP_QUERY, but they capture 70-78 % of the encoder-level span here and the shortfall grows with document size, so they were measured and rejected. D3D12 is exercised: device creation, a 100 ns/tick period and the full write/resolve/map round-trip succeed with no validation errors, including across a flushed three-buffer refresh. Numbers throughout are from an integrated Intel GPU on Mesa/Vulkan and a software D3D12 adapter; no vendor Windows driver and no Apple hardware was tested.