A short day, spent on the instrument rather than on the frame rate.
Why a tool
Two things from earlier in the week made the existing numbers hard to trust. A visible window on the development machine froze in ways the same shots did not when rendered offscreen. And the first frames of any run are dominated by shader compiles and buffer uploads: readings of 180 to 270 ms per frame turned out to be warm-up, not cost.
The new tool, perf.ps1, runs the church's camera shots with no window, skips the warm-up, and averages the steady state over 150 frames per shot. It can apply console-variable experiments to a run, print a per-pass GPU table, clean up after itself, and append every result to a log so runs can be compared later.
The baseline
At the Low tier, steady state, the enemy yard shot costs 62 ms and the nave shot 69 ms. It reproduced those on repeat runs, which is the property that matters: any change smaller than the run-to-run spread is not a result.
A batch that did not hold
The first experiments varied render resolution, upscale filter and how soon lights fade, and they seemed to show something odd: the cost did not fall smoothly with resolution, and the guess was that level-of-detail selection was reacting to the smaller view.
That batch cannot be relied on. Passing several commands to a single run turns out to apply only the first of them, so any experiment that combined settings was measuring less than it claimed to, and the tool now splits them correctly. Later runs, one setting at a time, showed cost falling steadily with resolution, with no odd step. The lesson is the same one the day's tool was built to enforce: before trusting a measurement, confirm that the thing you changed is the thing that changed.