2.5 KiB
CORRECTION to PERF-PROFILE-7c6f6886.md §5 — run-ahead removes much less of the fill than §4 implied
§4 is right that an unbarriered verb skips the residual fill. It is wrong to treat
MGPipeValidateForVerb's whole 18.03% as fill. The call tree under it (inproc, client thread,
percentages relative to that subtree) says otherwise:
| share of the subtree | child | skipped under run-ahead? |
|---|---|---|
| 22.05% | MGPipeTracker::Update |
no — the tracker walk runs regardless |
| 20.48% | MGPipeShaderBufferEmitter::EmitClass |
no — emitters PRODUCE records, which is the whole of what an unbarriered verb hands the server |
| 19.76% | MGPipeFillAccess::CopyField |
yes |
| ~6.7% | the sampler / vertex-input / program / framebuffer emitters | no |
| remainder | self, including the unconditional prologue | partly |
PipeFill.cpp:3226-3231 says this in words: "What still runs, unchanged, is the tracker walk and the
emitters (steps 2 and 3): those PRODUCE RECORDS, which is the whole of what an unbarriered verb is
allowed to hand the server." So only about a fifth of that 18.03% goes away, i.e. 3.6 – 4.5% of the
client thread, not 18%.
The corrected prediction
| now | predicted after run-ahead | |
|---|---|---|
| client GL thread | 6.1 ms/frame | ~3.9 ms/frame (the 31.8% wait, plus ~4% of fill) |
| apply thread | 5.3 ms/frame | ~2.0 ms/frame |
| bound by | client | client |
| implied fps | ~164 | ~250 |
| monolith, same session | 3.9 – 4.8 ms/frame | 208 – 256 fps |
The honest claim is PARITY, not past it. The split arm should land level with monolith, with the apply thread holding roughly 2 ms of headroom.
Going beyond parity is separate work, and §2 of the profile already names its targets: the emitters and the encode path, which is where the client's remaining ~3.9 ms lives. The wait is not one of them any more once run-ahead lands.
§5 of the profile note is left in place rather than edited, so the error is visible: it double-counted the tracker walk and the emitters as removable and produced ~3.0 ms / ~330 fps. This file supersedes it.
Why this matters beyond the number
The first estimate was built by subtracting whole inclusive percentages of a symbol whose name suggested it was all fill. That is the same class of error the previous phase recorded after attributing an idle poll's cost to backend lock contention: a percentage next to a plausible name is not an attribution. The call tree was three commands away and it changed the conclusion from "comfortably ahead" to "level". Take the tree.