`LP_MODE` cached the resolved VAAPI entrypoint (full-feature `EncSlice` vs low-power
`EncSliceLP`/VDEnc) in a process-global array indexed by codec alone. That is not a
staleness bug, it is a session-killer, because the cache is load-bearing: once a mode
is latched the open tries exactly ONE mode and the `[false, true]` fallback is gone.
Latch low-power on an Intel Arc (Gen12+ removed the full-feature entrypoints, so it
is the only one that works there), then switch the web-console GPU preference to an
AMD dGPU. `render_node()` follows that preference, so every VAAPI open now goes to
radeonsi passing `low_power=1`, which it rejects — with no full-feature retry, for
the process lifetime. `probe_can_encode` reports all-false (so the advertisement
silently falls back to the static superset) AND the session's own encoder open fails.
Now keyed on (render node, codec, bit depth):
- The render node because the entrypoint is a property of the DEVICE libva opens,
and it is literally what `render_node()` hands libva — so key and device cannot
describe different GPUs. Deliberately not `pf_gpu::selection_key()`, which can
name a different adapter than the node actually opened.
- The bit depth because Main10 and 8-bit can resolve to different entrypoints on
the same device; one shared slot let an 8-bit answer pin the 10-bit open, i.e.
HDR under-advertisement.
Verified `-D warnings --all-targets` + tests on Linux (default; shipped
nvenc,vulkan-encode,pyrowave). The multi-GPU switch itself needs a box with two
VAAPI-capable adapters — owed on-glass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
enricobuehlerandClaude Opus 5
087a3e358a