fix(client/present): log the surface's actual present modes, and document the VRR opt-in
"AMD's Windows driver offers no MAILBOX" is the premise the FIFO glass gate is built on, and it has been carried in a code comment rather than measured. Present modes are a property of the (surface, device) pair — they vary by platform surface, driver version and fullscreen state — so the only way to settle it is to read them back from real machines. One unconditional log line makes every field log answer the question. First reading, .21 (NVIDIA 610.43.03, GNOME/Wayland): surface present modes available=[MAILBOX, 1000361000, FIFO] Two things fall out. No IMMEDIATE and no FIFO_RELAXED on this surface, which is why a PUNKTFUNK_PRESENT_MODE=immediate run reported mode=fifo — the pin was not offered and the ladder fell through; previously that looked like a puzzling result and is now evidence. And 1000361000 is VK_PRESENT_MODE_FIFO_LATEST_READY_EXT: FIFO's tear-free vblank pacing that presents the LATEST READY image instead of draining a queue — the driver-native version of what the glass gate emulates in software, and a candidate to replace it wherever the driver exposes it (needs VK_EXT_present_mode_fifo_latest_ready enabled at device creation, so a work package rather than a tweak). Also documents PUNKTFUNK_VRR_FIFO, which the previous commit introduced without a docs entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -836,6 +836,16 @@ fn pick_present_mode(
|
||||
"PUNKTFUNK_PRESENT_MODE not offered by this surface — falling back"
|
||||
);
|
||||
}
|
||||
// What the surface ACTUALLY offers, logged unconditionally. "AMD's Windows driver
|
||||
// has no MAILBOX" is the premise the FIFO glass gate is built on, and it has been
|
||||
// carried in comments rather than measured — present modes are a property of the
|
||||
// (surface, device) pair, so they vary by platform surface, driver version and
|
||||
// fullscreen state, and the only way to settle it is to read it back from real
|
||||
// machines. One line here makes every field log answer the question.
|
||||
tracing::info!(
|
||||
available = ?modes,
|
||||
"surface present modes"
|
||||
);
|
||||
let chain = present_mode_chain(pref);
|
||||
let chosen = chain
|
||||
.iter()
|
||||
|
||||
@@ -243,6 +243,7 @@ A few knobs are read by the native **clients**, not the host:
|
||||
| `PUNKTFUNK_NO_AEC` | `1` | Turn the microphone's echo cancellation off for this run, whatever **Echo cancellation** says in [client settings](/docs/client-settings#audio). One-way: it can only switch the processing off, never back on, and the setting is the normal way to control it. Linux and Windows clients. |
|
||||
| `PUNKTFUNK_PRESENT_MODE` | `mailbox` *(default)* · `fifo` · `immediate` · `fifo_relaxed` | How decoded frames meet the display (the Vulkan present mode). The default prefers MAILBOX — tear-free without queueing behind the vertical refresh — and falls back to FIFO (classic vsync) where the driver doesn't offer it. **AMD's Windows driver offers no MAILBOX**, so those clients run FIFO, which adds a standing frame-pacing wait (up to one refresh interval). `immediate` removes that wait but can tear; `fifo_relaxed` only tears when a frame is late. If your latency floor matters more than tearing, try `immediate` and judge by eye. |
|
||||
| `PUNKTFUNK_PRESENTER` | `arrival` | Turn the frame-pacing engine off for this run: frames present the instant they decode, exactly as they did before the **Prioritize** setting existed. A diagnostic — if a pacing change is suspected of causing judder or added delay, this switches it off without reinstalling anything. Linux and Windows clients. |
|
||||
| `PUNKTFUNK_VRR_FIFO` | `1` | Opt into the presentation mode intended for **variable-refresh (VRR / FreeSync / G-Sync) displays**, where each frame is shown as the panel is ready for it rather than on a fixed cadence. Off by default: on a *fixed*-refresh display this mode measured substantially worse (about 27 ms more display latency than the default), and its benefit on a real VRR panel has not yet been confirmed. Try it if you have a VRR display and run fullscreen; check the Detailed [stats overlay](/docs/stats) — `vrr yes` means the panel really is following the stream. Linux and Windows clients. |
|
||||
| `PUNKTFUNK_PRESENT_DEBUG` | `1` | Log the presenter's own 1-second summary (display mode, buffer drops, pacing counters) every second, even when nothing is going wrong. Without it the line appears only when there is something to report. |
|
||||
| `PUNKTFUNK_ABR_PROBE_KBPS` | kbps, e.g. `900000` | The startup link-capacity probe's burst target (default 2 Gbps — deliberately above any plausible link so the burst measures the link, not itself). Lower it on links the burst shouldn't slam, or when the measured ceiling comes out wrong for your setup. |
|
||||
| `PUNKTFUNK_ABR_PROBE` | `0` | Skip the startup link-capacity probe entirely. The adaptive-bitrate climb ceiling then stays at the negotiated starting rate — a blunt instrument; prefer `PUNKTFUNK_ABR_MAX_MBPS`. |
|
||||
|
||||
Reference in New Issue
Block a user