71 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	ead37d066f	perf(encode/nvenc-linux): drop the bring-up probe left on the per-frame blend path ... `33121ece` added a block explicitly labelled "TEMP KWin composite probe (DROP BEFORE MERGE)" to prove the cursor blend was dispatching. It merged, and has been running on every blended frame since: an atomic fetch_add per frame plus a `tracing::info!` with seven computed fields every 512 frames, on the submit hot path of the default-on Linux direct-NVENC backend. The signal it existed for is already covered — the failure arm above it warns once with the dispatch error, and the `else` arm warns when an overlay arrives with no blend at all. What is deleted is only the success-path telemetry. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc,vulkan-encode,pyrowave), and `clippy --features vulkan-encode,pyrowave` on real AMD RDNA3 hardware. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 03:48:59 +02:00
enricobuehlerandClaude Opus 5	310b85f155	fix(encode): a forced-Vulkan pref must not advertise codecs that arm will refuse ... With `PUNKTFUNK_ENCODER=vulkan`, `open_video_backend`'s vulkan arm bails outright for anything that is not HEVC/AV1 ("the Vulkan Video encoder supports HEVC + AV1; the session negotiated {codec:?}"). But `host_wire_caps` for that same pref fell through to the VAAPI probe / static superset, which includes H.264 — so the host advertised H.264, a client could negotiate it, and the session died at encoder open. The pref now contributes a CEILING that is intersected with the device probe, never a replacement for it. That distinction is the whole fix: pinning a static HEVC|AV1 would have ADDED AV1 on the AMD/Intel hosts whose probe currently withholds it (pre-RDNA3, pre-Arc), re-creating this very bug for a different codec. Intersecting can only ever narrow. Without the `vulkan-encode` feature the pref cannot open anything at all — that arm bails with "requires a build with --features vulkan-encode" — so the ceiling is empty there rather than optimistic. Costs nothing on the handshake path: a `&str` match plus a const-folded `cfg!`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 03:17:45 +02:00
enricobuehlerandClaude Opus 5	087a3e358a	fix(encode/vaapi): key the entrypoint cache on the device, not just the codec ... `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>	2026-07-25 03:17:44 +02:00
enricobuehlerandClaude Opus 5	4d9f94e0a4	docs(encode): record why the production loops must not call Encoder::flush ... `flush` looked dead — the only caller in the host is the `spike` dev subcommand — so an audit sweep filed it as "wire it in or delete it". Both are wrong, and without this note the next sweep will re-file it. Wiring it in is refuted by control flow: both encode loops reach their exit only AFTER the transport is gone (client disconnected, or the session stopped), so the AUs a flush would recover have nowhere to go. And flush is the one call on this trait that can BLOCK on a wedged encoder, on exactly the teardown path a stopped session needs to finish promptly — the Linux direct-SDK NVENC retrieve-thread join is untimed, so flushing there could hang a session that is already ending. Deleting it is refuted by real consumers: `spike` encodes a FINITE clip and wants the tail, and the `#[ignore]`d hardware smoke tests across the backends assert the drain contract on real GPUs. Those are finite-stream users; a live session is not one. Doc only, no behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	ef239691df	feat(encode): make cursor blending a queryable capability, not an assumption ... `open_video`'s `cursor_blend` argument was a request with no answer: lib.rs did `let _ = cursor_blend;` and only three backends ever read `CapturedFrame::cursor`. So a session could ask for a composited pointer, get a backend that silently discards it, and stream with no mouse cursor and nothing in the logs. Two separately-confirmed audit findings — the VAAPI dmabuf path and the libav-NVENC CUDA path — are symptoms of that one hole. `EncoderCaps::blends_cursor` makes it a fact each backend states. The four exhaustive `EncoderCaps { .. }` constructors mean adding the field is a compile error until every backend answers, which is the enforcement mechanism for future backends rather than a side effect. Vulkan Video answers from its ACTUAL configured source rather than statically: only the CSC path composites (`prep_cursor` feeds the compute shader), while the RGB-direct/EFC front-end and the native-NV12 source have no compositing stage at all and merely warn once that the pointer is being dropped. `open_video` warns when a session asked for blending and the opened backend cannot deliver it. A warning is deliberately all it does: `open_video` cannot re-plan capture, so refusing would trade a missing pointer for a dead session. The host owns `plan.cursor_blend` and is the only layer that can fall back to capturer-side compositing — this gives it something to base that on. Enforcement is NOT included. The reviewed design proposed refusing the client's host-composite flip to keep the client drawing its own pointer, but `CursorRenderMode` is client->host only: there is no host->client counterpart, so refusing yields no pointer at all — the same failure it claimed to prevent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	ab63e0dad3	fix(encode/nvenc-windows): fail safe when nobody sets the input ring depth ... `set_input_ring_depth` is a DEFAULTED trait method, so a caller that forgets it fails silently — and one did. The GameStream loop opens an encoder (gamestream/stream.rs:671 and the rebuild at :831) and never called it, while the Windows IDD-push capturer declares a ring of 2 and `async_inflight_cap()` defaults to 4. With PUNKTFUNK_NVENC_ASYNC=1 a Moonlight session therefore pipelined four encodes against a two-texture ring, letting the capturer rotate a texture out from under a live encode: torn or mixed frames, never an error — precisely the corruption the cap exists to prevent, and precisely what the trait doc warns "fails silently and intermittently". Guarded at the single point of CONSUMPTION rather than by plumbing the setter into every loop: `input_ring_depth` has exactly one reader in the workspace, so one fail-safe covers every caller including ones not yet written, whereas fixing N call sites only fixes the N someone remembered. An unconfigured ring is now treated as the shallowest any capturer here declares, so the unconfigured path degrades to less pipelining — a latency cost, not corruption. The two GameStream sites also pass the REAL depth, because the fail-safe is a floor, not a substitute: `idd_depth` is configurable and a deeper ring is free pipelining the fallback would forfeit. Default (sync) sessions are unaffected — the cap is only read while the async retrieve thread exists, and that is opt-in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Fable 5	78fe77b049	feat(host/encode): de-escalate the latency escalation once cadence holds clean ... Escalate-and-hold's missing half. The contention escalation (capture depth, then the NVENC pipelined retrieve) was permanent: one sustained overrun — even one CAUSED by the ABR overdrive's rebuild storms — cost the session its depth-1 latency and its sub-frame streaming forever, and `encode_us` reported queue depth instead of ASIC time for the rest of the session. - The leaky bucket now keeps scoring after escalation. A sustained every-frame-on-cadence run (~5 s at 120 fps) winds back one stage in reverse order: pipelined retrieve first (its rebuild restores the IO-stream binding and sub-frame chunked streaming), then capture depth back to 1. Attempts are paced by an exponential backoff (1 → 5 → 25 min, capped) — a workload that truly needs the escalation converges to keeping it, but never a permanent latch. - NVENC (Linux) implements `set_pipelined(false)`: a `want_sync` latch handled at the same drained safe point as the engage side (`maybe_disengage_async` mirrors `maybe_engage_async`); the lazy sync re-init re-arms everything and opens on an IDR. The stream loop polls until the switch lands, then re-runs the escalation warmup so the wind-back's own stall can't re-escalate it. `PUNKTFUNK_NVENC_ASYNC=1` (operator-pinned async) refuses the wind-back; the trait doc now specifies the two-way contract. - While escalated, `cadence_degraded` stays latched (bitrate climbs refused) even with the bucket drained: the headroom is spent, and climbs resuming mid-escalation would saw against it and starve the clean run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Fable 5	c1d54b835b	fix(encode/nvenc): cache the level ceiling, expose the applied bitrate, force 2-way split at 4K120 ... Three encode-time fixes from the 4K120 field analysis (sessions pinned ~107 of 120 fps, 14-15 ms reported encode): - Ceiling truth: the codec-level bitrate clamp (binary search at session open) now records its result in a process-lifetime advisory cache keyed by GPU/config, so an ABR overshoot opens — or in-place reconfigures — straight AT the ceiling instead of re-running the ~6-open search (and a full rebuild + IDR) on every overshoot. New `Encoder::applied_bitrate_bps()` exposes the post-clamp rate so the session loop can stop pacing/acking a phantom requested rate (consumed host-side in a follow-up). - Clamp-search hygiene: only NVENC parameter/caps rejections steer the search now (`NvCallError` keeps the raw status downcastable); a transient failure (busy engine, session limit, OOM, driver skew) propagates instead of shrinking into — and now caching — a bogus ceiling. The floor fallback also records the split mode it actually opened with, so a later reconfigure re-presents the real session params. - Split-frame selection: one shared `resolve_split_mode` replaces the two byte-identical direct-SDK copies; the force-2-way threshold moves to `SPLIT_FORCE_PIXEL_RATE` (950 Mpix/s, shared with the libav path) because 4K120 = 995,328,000 px/s missed the old `> 1e9` gate by 0.47% and stayed on AUTO — which never engages at 2160 px height, leaving the second NVENC engine idle in exactly the mode the threshold existed for. The Linux session-ready info! line now carries the final split mode (journals are INFO+; this was undiagnosable from user logs). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Opus 5	42e5f5ad1e	fix(encode/windows): two dead items the new lint leg exposed in the shipped combo ... 09aa2db3 turned on `-p pf-encode --all-targets -D warnings` for Windows and removed the crate-wide `allow(dead_code)`; together those surfaced two genuinely-dead items in `nvenc,amf-qsv,qsv` — the combination the installer ships — and CI went red on my own step. - `WinVendor::Amf`: native AMF replaced the libavcodec AMF path in production, so the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]` latency A/B in amf.rs — test code, so the lib target constructs it nowhere. The module header already says this machinery is kept deliberately for that measurement, so it gets a targeted `#[allow(dead_code)]` naming the reason rather than deletion. - `probe_can_encode`: `lib.rs`'s only caller is under `cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native VPL backend compiled in `qsv::probe_can_encode` answers instead. Gated `#[cfg(not(feature = "qsv"))]` to match its call site. Both are real findings the blanket allow had been hiding; neither is a behaviour change. WHY THIS ESCAPED MY PRE-PUSH CHECKS, since that is the useful part: the Windows runner I verify on has no FFmpeg dev tree, so `amf-qsv` could not build there and `ffmpeg_win.rs` was compiled by NOTHING in my matrix — the same class of blind spot this whole audit is about, reproduced by me. CI's own FFmpeg turns out to be cached on that box at C:\Users\Public\ffmpeg, so the verification recipe now sets FFMPEG_DIR and covers `nvenc,amf-qsv,qsv` (the CI command and my new step) plus `amf-qsv` without `qsv` — the combo that still uses `probe_can_encode`. All three clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 01:04:04 +02:00
enricobuehlerandClaude Opus 5	09aa2db37c	fix(encode): probe Vulkan encode before committing capture to producer-native NV12 ... `linux_native_nv12_ok` is the verdict the host threads into capture negotiation (session_plan -> OutputFormat::nv12_native -> ZeroCopyPolicy::native_nv12_session -> pf-capture's prefer_native_nv12). Its doc claimed "the backend must be eligible to open", but it asked only three static questions — codec is H265/AV1, an env default, and a pref denylist — and never whether this GPU has an encode queue at all. It could not: vulkan_video.rs exposed no probe. That verdict is uniquely load-bearing. Once the producer has been asked for two-plane NV12 there is NO fallback: open_video deliberately makes a failed Vulkan open FATAL for an NV12 capture rather than degrading to libav VAAPI, because VAAPI would import that buffer as packed RGB and stream silent garbage. So on a gamescope host whose Mesa lacks Vulkan HEVC encode the session died at its first frame, while the same host with PUNKTFUNK_PIPEWIRE_NV12=0 streamed fine — and the comment promising such a device "degrades gracefully to the old backend rather than breaking the stream" was stale on every gamescope host. Two changes: 1. The gate. The third conjunct was a denylist of the EXPLICIT prefs that skip Vulkan Video ("nvenc"|"nvidia"|"cuda"|"pyrowave"), which silently missed the one that matters: the DEFAULT encoder_pref is "", and "" resolves to auto, which on an NVIDIA box opens NVENC. A stock NVIDIA host passed this gate. It now consults `linux_zero_copy_is_vaapi`, which layers the pref on top of the same auto decision open_video makes — what the note on `linux_auto_is_vaapi` says a capability probe must use, and what the downstream consumer of this very verdict already uses. This alone was worth fixing; a probe added behind the old gate would have opened a Vulkan instance on every NVIDIA handshake. 2. The probe. `vulkan_video::probe_encode_support` runs the FIRST check open_inner performs and hard-fails on — the physical-device + encode-queue-family scan for this codec's op — and nothing more, so it is provably no stricter than the open and can never talk a working host out of the fast path. The scan is now a shared `find_encode_device` used by BOTH, because a probe that mirrors a dispatch goes stale the first time the dispatch grows a case (the failure open_video's backend-label note already records). Cost: one instance plus physical-device queries — no logical device, no video session, no VRAM — cached per (selected GPU, codec) in the can_encode_10bit idiom, with the probe run outside the lock. Per codec, not once: codec_op_for selects a different queue-family bit for AV1, and HEVC-encode-without-AV1-encode is the common VCN/ANV configuration. Later stages (create_device, create_video_session, the capability query) can still fail for reasons the probe does not model. Those are harmless: the capture format is only committed once the probe says yes, and everything after keeps the ordinary packed-RGB negotiation. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). The behaviour needs an on-glass check on the bazzite RADV box — including the negative case, which `RADV_DEBUG=novideo` reproduces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	4063ddc93d	perf(encode/nvenc-linux): swscale the packed 3-bpp expand instead of a per-pixel loop ... `submit_cpu`'s RGB24/BGR24 → rgb0/bgr0 expand ran `w*h` iterations per frame, each building two bounds-checked sub-slices for a 3-byte copy plus a pad-byte store — a shape LLVM will not vectorise into the byte shuffle it actually is. At 3840x2160 that is 8.3M iterations on the encode thread, per frame. It is not an edge case. The module header says the portal commonly negotiates packed 24-bit RGB, and pf-capture offers `VideoFormat::RGB` first because wlroots commonly fixates it — so this was the mainstream CPU path, running roughly an order of magnitude slower than the 4-bpp sibling branch (a plain row memcpy) purely because of how it was written. swscale's packed-RGB expanders are SIMD, the sibling VAAPI backend already routes RGB24/BGR24 through them, and this file already owned the `sws_getContext` / `sws_freeContext` lifecycle — so this is net subtractive rather than new machinery: the existing CSC condition widens to include `expand`, and the hand-written loop goes away. No new field, no second context, nothing added to `Drop`: `expand` is false whenever `want_444` (see the `nvenc_pixel`/`expand` binding), so the three users are mutually exclusive and one context serves whichever applies. The `expand` field itself is gone with its only reader. `sws_setColorspaceDetails` is now applied ONLY for the 4:4:4/HDR users. The expand is a pure byte shuffle — NVENC does the RGB→YUV itself downstream — and handing it a matrix and range would have silently range-converted every packed-RGB session, which is exactly what the module header promises does not happen. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). The pixel path itself is unverifiable without an NVIDIA box: `nvenc_hdr10_smoke` and friends are #[ignore]d, so the channel order and the pad byte want an on-glass check on the CachyOS 5070 Ti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	c7081b2a82	fix(encode/nvenc-linux): stop leaking the SwsContext on open's early returns ... `sws_getContext` hands back a raw pointer whose only `sws_freeContext` lives in `Drop for NvencEncoder` — and `Drop` needs a CONSTRUCTED `Self`, which does not exist on either of `open`'s early returns: the intra-refresh-unsupported path (which recurses into `Self::open`) and the plain error return. Both sit between the context's creation and the `Ok(NvencEncoder { … })` that would give it an owner, so every failed open leaked one. That is not a once-per-process wart. `open_nvenc_probed` walks an EINVAL bitrate ladder — requested rate, then the codec-level cap, then ×3/4 down to 50 Mb/s — re-entering `open` at each step, so a GPU that refuses the requested bitrate leaks a context per step (up to ~10). The intra-refresh retry adds one more. Fixed structurally rather than with a guard: the block depends only on values known before the encoder open (`want_444`, `want_hdr10`, `cuda`, `format`, `nvenc_pixel`, the dimensions, `full_range_444`), so moving it BELOW `video.open_with(opts)` — to just above the struct construction, with nothing fallible in between — makes the leak unrepresentable instead of merely handled. No behaviour change: same context, same colourspace details, same field. Found while designing the WP1.4 swscale expand, which would have promoted this from a 4:4:4/HDR-only leak (the only sessions that build a context today) to one on every packed-RGB session. Fixing it first is the prerequisite for that change. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	6be174dc9c	fix(encode/windows): the encode bit depth must follow the pixels, not the negotiation ... All three Windows backends derived it the same wrong way — `bit_depth >= 10 || matches!(format, P010 | Rgb10a2)` at ffmpeg_win.rs:154, amf.rs:1275 and qsv.rs:777 — so the NEGOTIATED depth could force a 10-bit encoder over an 8-bit capture. That combination is not hypothetical. A client advertises 10-bit, the handshake negotiates bit_depth=10, and then enabling advanced colour on the IDD virtual display fails — at which point the capturer says exactly that and delivers 8-bit NV12 anyway ("10-bit HDR was negotiated but enabling advanced color on the virtual display FAILED — encoding 8-bit SDR"). Every vendor then lost the session, each in its own way: - native AMF and native QSV derived `expected = P010`, saw Nv12, and bail!'d at open; - the libavcodec path accepted the open, built a P010 encoder, and then failed EVERY submit forever, because its per-frame check recomputes the depth from the frame and never matches. reset() could not help: the rebuild re-derived the same wrong depth from the same stored bit_depth. The host burned MAX_ENCODER_RESETS and ended the session. The last one is the worst of the three because it IS the fallback: native QSV correctly refuses this input at open, and lib.rs then falls back to the ffmpeg path "for robustness" — which accepted it and died per frame instead. Since the duplication was the bug, the fix is one shared `ten_bit_input()` in codec.rs that all three call, and it follows the delivered pixels. That also keeps the stream HONEST rather than merely alive: the depth selects the colour signalling (BT.2020 PQ vs BT.709) and the staging surface format, so an 8-bit capture now produces an 8-bit stream that says it is SDR — which is what the capturer already reported it was sending. It warns when the negotiated depth is discarded. The negotiated depth stays an upper bound. The session LABEL may still claim HDR; that mismatch lives in the negotiation, not in the encoder, and is not addressed here. `is_10bit_format` keeps its (now format-only) definition and is used by submit_d3d11's per-frame check, so the predicate the encoder was built from and the one it re-checks per frame cannot drift. That check can now only fire on a genuine mid-stream depth change. Verified `--all-targets -D warnings` on Windows (no features / pyrowave / qsv / nvenc,qsv; 31 tests) and Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	6c97c00add	fix(encode/pyrowave): the RDO block-index cap must cover 4:2:0, not just 4:4:4 ... The vendored rate controller packs the 32x32 block index into the low 16 bits of `RDOperation::block_offset_saving` (pyrowave-sys patches/0002). Past u16::MAX the index collides with the `saving` field, the resolve over-credits, and the emitted payload can overshoot the buffer `pyrowave_encoder_packetize` writes into — whose only bounds check is an `assert` that the Release (NDEBUG) vendored build compiles out. There is no Rust-side guard behind it. All three callers of `pyrowave_mode_fits_rdo` hardcoded 4:4:4, leaving 4:2:0 unchecked — but 4:2:0 overflows too, just later: 8192x6144 is 73728 blocks and 8192x8192 is 98304, while `Codec::PyroWave.max_dimension()` permits 8192 per axis, so both are reachable from a client-requested `mode=WxHxFPS`. Worse, the host's only use of the helper (native/handshake.rs) is a 4:4:4 -> 4:2:0 downgrade, so an oversized mode was actively routed INTO the unguarded branch. The cap now lives in `validate_dimensions`, checked against 4:2:0 — the most permissive chroma, so a mode that cannot fit there fits no PyroWave session at any chroma. That is the single chokepoint both the negotiator (handshake.rs:180) and `open_video_backend` already run. Both encoder opens additionally check the chroma actually being opened: the 4:4:4 half, plus defence in depth for the `PUNKTFUNK_ENCODER=pyrowave` lab override. Not dormant: punktfunk-host has `default = ["pyrowave"]` and no build passes `--no-default-features`, so these backends ship in every host binary. Tests pin the arithmetic (8192x6144 = 73728, 8192x8192 = 98304, 7680x4320 still fits) and assert the cap does not leak to H.265/AV1, which have no such controller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	07348c0175	refactor(encode): drop the crate-wide allow(dead_code) ... Inherited from the pre-extraction host crate root as scaffolding for backend paths defined ahead of the build that used them. A census across every feature combination on both platforms (flip it to `warn`, rebuild) found it was hiding exactly two items — so it bought nothing while blinding the crate to future rot: - `vaapi::fourcc` — superseded by `pf_frame::drm_fourcc`; no call sites left. - `vulkan_video::open_opts` — test-only (the smoke tests use it to pass the RGB-direct request explicitly rather than through the env), now `#[cfg(test)]`. Removing it surfaced a real latent defect the Linux census could not see: `amf.rs`'s `percentile` / `drive_and_measure` helpers are used only by the `#[cfg(feature = "amf-qsv")]` latency A/B benchmark, so a `--features nvenc,qsv` build compiled the helpers with their caller gated out. They now carry the same gate as their caller. Verified `--all-targets -D warnings` on Linux (no features; shipped nvenc+vulkan-encode+pyrowave) and Windows (no features; pyrowave; qsv; nvenc,qsv). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	e30551b1e2	fix(encode/nvenc-linux): unrot the direct-NVENC test module ... All ten `NvencCudaEncoder::open` call sites in the `#[cfg(test)]` module passed 9 arguments to a 10-parameter function: `cursor_blend` was added to `open` and the tests were never updated. The module has been uncompilable ever since — `cargo clippy -p pf-encode --features nvenc --all-targets` fails with 10x E0061. Nothing in CI noticed because no job compiles this crate's feature-gated test targets: ci.yml lints/tests with default features (which do not include `nvenc`), and windows-host.yml lints `-p punktfunk-host`, which builds pf-encode as a dependency and so never builds its test targets. The CI commit below closes that gap; this has to land first or that leg starts red. `false` is what these tests exercised before `cursor_blend` existed: every frame they build sets `cursor: None`, and there is no cursor-blend test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Fable 5	925130d1f9	feat(vdisplay): compositor-embedded pointer for sessions without the cursor channel (Phase B) ... Since the cursor-channel work, every Linux virtual output was created in metadata pointer mode — making ALL sessions depend on host-side cursor compositing, including the ones that can never use the channel (Moonlight/ GameStream, legacy clients, capture-mode starts). Those sessions paid the blend bring-up per session and, whenever a visible cursor was composited, the loss of NVENC's stream-ordered submit — for a strictly worse cursor than the compositor's own. Mirror the Windows no-regression gate: the already-wired per-session set_hw_cursor(cursor_forward) now drives the Linux backends too. A cursor-channel session gets metadata (shapes forwarded, composite flip blends host-side — today's validated path, unchanged); every other session gets the pointer compositor-EMBEDDED at creation (KWin zkde pointer=2, Mutter cursor-mode=1, wlroots/hyprland portal CursorMode::Embedded — their pre-channel default; the portal pair also gains the Metadata arm for channel sessions, wired but untested on-glass). SessionPlan.cursor_blend narrows to cursor-forward sessions and rides into the direct-SDK NVENC open, which skips the Vulkan slot-blend bring-up entirely when off — embedded sessions ring on plain CUDA surfaces and pay zero cursor cost, per-session or per-frame. The keep-alive registry's reuse key grows the created pointer mode (new VirtualDisplay::hw_cursor getter): a kept embedded display has no cursor metadata for a channel session to forward, and a kept metadata display would leave a channel-less session with no pointer in its frames. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	d2c46eaf3c	feat(encode/nvenc): SPIR-V cursor blend over Vulkan-allocated input slots — retire the PTX kernels ... A vendored PTX blob is JIT'd against the driver's ISA ceiling, so the cursor-blend module silently dies on drivers older than the generating toolkit (CUDA_ERROR_UNSUPPORTED_PTX_VERSION/INVALID_PTX, 222/218 — the KWin leg's invisible composite cursor on driver 595/CUDA 13.2 vs a CUDA 13.3 blob). SPIR-V has no such coupling, and the in-tree precedent already exists twice (vulkan_video's CSC blend, VkBridge's exportable OPAQUE_FD → cuImportExternalMemory bridge). New pf_zerocopy::vkslot::VkSlotBlend: the direct-SDK NVENC encoder now allocates its input ring as exportable Vulkan buffers CUDA-imports (same contiguous InputSurface layouts, pitch = row bytes rounded to 256), and the cursor composite is a compute dispatch over the cursor's rectangle (cursor_blend.comp, vendored .spv; spec-constant selects ARGB/NV12/YUV444; BT.709 limited, matching the retired .cu). The surface SSBO is uint[] with every invocation owning whole words — no 8-bit-storage device dependency. Cursor-bearing frames force the existing CPU-synced submit path so the CUDA copy → Vulkan dispatch (fence-waited) → NVENC encode ordering is CPU-established; cursorless frames keep the stream-ordered fast path untouched. Any bring-up/alloc/registration failure falls back wholesale to plain pitched CUDA surfaces (never a mixed or short ring): sessions always encode, composite mode just loses the cursor, warned once. cursor_blend.cu / cursor_blend.ptx and the CursorBlend PTX loader are deleted. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	33121ece4d	chore(kwin-composite): TEMP blend-path probes — DROP BEFORE MERGE ... Rate-limited journal logging bracketing the silent segment of the Linux composite path: what overlay (if any) the encode loop's composite arm hands the encoder, and whether the NVENC cursor-blend kernel launches and with what geometry. On-glass (KWin leg) the blend module loads yet the composite cursor stays invisible — these two probes attribute it to no-overlay / stripped-en-route / kernel-draws-nothing. The module-loaded INFO line is permanent (success must be as attributable as failure); everything else in this commit is temporary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	09113c9899	fix(encode/nvenc): cursor-blend PTX must carry a driver-portable ISA version ... The vendored cursor_blend.ptx was regenerated with the CUDA 13.3 toolkit, which stamps '.version 9.3' — and a driver whose JIT predates that ISA refuses the whole module with CUDA_ERROR_UNSUPPORTED_PTX_VERSION (222), silently killing host-side cursor compositing (on-glass: composite-mode cursor invisible on driver 595.58, KWin leg). The kernels use only baseline arithmetic, so hand-lower the version directive to 8.0 (CUDA 12.0), which every supported Turing+ driver JITs. Both files now warn that an nvcc regeneration re-stamps the version and must be re-lowered. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	42198eb1b6	feat(linux/vulkan-encode): default-on native NV12 capture + RGB true-extent ... Flip both zero-copy levers from opt-in to default: - The capture negotiation now PREFERS gamescope's producer-side NV12 pod by default (PUNKTFUNK_PIPEWIRE_NV12=0 restores the packed-RGB negotiation). Codec-aware gating rides a new OutputFormat::nv12_native -> ZeroCopyPolicy::native_nv12_session edge resolved by the host facade from the session plan (pf_encode::linux_native_nv12_ok): only H265/AV1 sessions whose backend can open the raw Vulkan Video encoder ever see the NV12 pod -- an H264/Moonlight session (libav VAAPI, which would misread the two-plane buffer) keeps today's BGRx negotiation, as do the GameStream-resolve and portal-mirror paths, PyroWave, and NVENC prefs. - RGB-direct's unaligned modes default to the true-extent direct import (PUNKTFUNK_VULKAN_RGB_TRUE_EXTENT=0 restores the padded-copy staging). Guarded-tested on Van Gogh with the kernel journal watched: clean, and at 5.38 ms p50 the fastest 1080p encode path measured on that hardware. The EFC only exists on Mesa >= 26, where the codedExtent-driven session_init padding is guaranteed (verified back to Mesa 24.2). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 14:01:28 +02:00
enricobuehlerandClaude Fable 5	b4fbc94e36	feat(linux/vulkan-encode): PUNKTFUNK_VULKAN_RGB_TRUE_EXTENT bring-up gate ... Opt-in alternative to RGB-direct's padded-copy staging at unaligned modes: direct-import the visible-size capture and declare the TRUE-SIZE source codedExtent. RADV has derived the VCN session_init firmware padding from srcPictureResource.codedExtent since Mesa 24.2, so the EFC is told the source lacks the alignment rows and the hardware edge-extends them internally -- which also reframes the 2026-07-20 field GPU reset: that crash passed the ALIGNED extent as the source codedExtent (firmware padding zero) over a visible-size buffer. Off by default until a guarded live test proves the EFC front-end honors the padding like the YUV fetch path does; the padded-copy staging remains the shipped behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 14:01:28 +02:00
enricobuehlerandClaude Fable 5	004f0cacb8	perf(linux/vulkan-encode): true-size headers make native NV12 zero-copy at every mode ... Drop the padded-copy staging for producer-native NV12 and direct-import the visible-size buffer at unaligned modes (1080p) too. Safe by the driver's own contract rather than by allocation luck: native sessions now author the H265 SPS / AV1 sequence header at the RENDER size and pass the matching codedExtent on every picture resource. RADV rounds the bitstream SPS up itself (with a conformance window -- radv_video_patch_encode_session_parameters, per the VK_KHR_video_encode_h265 proposal's "implementations may override" clause) and programs the VCN session_init with the true extent plus nonzero firmware padding, so the hardware edge-extends the alignment rows internally and never fetches past the source's real extent -- the exact mechanism VAAPI/radeonsi has always used to encode 1080p. The driver-emitted header NALs already carry the patched SPS, so the wire format is unchanged. The CSC and RGB-direct paths keep the app-aligned convention (their sources genuinely cover the aligned extent); RGB padded-copy staging is untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 14:01:28 +02:00
enricobuehlerandClaude Fable 5	428bd2519c	test(qsv): converter→ring-profile-P010→encoder live e2e (the RTV-written seam) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	87d7eceabf	fix(encode/qsv): write the colour VUI unconditionally + Intel-lane colour diagnostics ... The native QSV encoder only attached mfxExtVideoSignalInfo on HDR sessions — an SDR stream carried no colour description at all (NVENC writes 709-limited unconditionally; qsv.rs now mirrors it). Diagnostics for the field-reported blue/magenta Intel-host colours: - hdr-p010-selftest takes an optional WxH + GPU vendor (intel|nvidia|amd) and prints which adapter it tested — 64x64 on the default GPU proved nothing on dual-GPU boxes, and the field heights (1080/1400) are not 16-aligned. - pf-capture: ignored live test running the converter at 1920x1080 pinned to the Intel adapter. - pf-encode: qsv_live_p010_1080_colorbars_dump — known P010 bars through the UNALIGNED-height ingest copy (1080 src -> align16 1088 pool, the seam no 640x480 test exercises) to Main10 HEVC, dumped for off-box decode checks. - dxgi.rs: drop the stale 'falls back to the R10 path' claim (no such path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	1d4795666e	feat(linux/vulkan-encode): opt-in gamescope producer-native NV12 encode source ... With PUNKTFUNK_PIPEWIRE_NV12=1 (bring-up gate), the PipeWire negotiation offers an NV12 LINEAR DMA-BUF pod (BT.709 limited pinned MANDATORY) ahead of the BGRx one, and gamescope's producer-side RGB->YUV pass replaces the host CSC entirely: the encoder imports the two-plane buffer as a profiled VIDEO_ENCODE_SRC image and the VCN encodes it directly. Contributed measurements: encode p99 2.9 ms (from ~4-4.5 ms via EFC RGB-direct), 60 fps capture, 0 send drops. Hardening on top of the contributed patch: - unaligned modes (1080p!) stage through a padded aligned NV12 copy (edge rows/columns duplicated, transfer-only) instead of direct-importing the visible-size buffer -- a direct import would make the VCN read past the producer allocation, the exact OOB class behind the 2026-07-20 field GPU reset; the encode extents return to the aligned coded extent everywhere - the UV plane layout honors the producer's plane-1 chunk (offset/stride) when the SPA buffer carries one (same-BO verified by inode), with the contiguous-plane contract as fallback - PyroWave sessions are excluded from the gate (their Vulkan compute CSC ingests packed RGB), and a native-NV12 session that resolves to libav VAAPI (H264 codec, PUNKTFUNK_VULKAN_ENCODE=0, feature off, or a failed Vulkan open) refuses at open instead of streaming garbage chroma - pad staging images carry TRANSFER_SRC (the width-padding pass self-copies the staging image -- previously missing on 1366-wide modes) - metadata-cursor one-shot warn (parity with RGB-direct) and a padded-NV12 PUNKTFUNK_PERF split label; the padded RGB copy gets its timestamps too Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 11:57:42 +02:00
enricobuehlerandClaude Fable 5	67b7981096	feat(encode/nvenc-linux): LN1 phase-3 — multi-slice sub-frame encode DEFAULT-ON for Linux direct-NVENC ... Gates recorded (nvenc-subframe-slice-output.md Phase 3): loss-harness curve identical streamed-vs-whole; adversarial security review clean; live .21 3-leg A/B — streamed 0 corrupted frames, p99 8527→5363 µs vs sliced-whole, first_slice_us ~500 µs of a ~1250 µs encode reaching the send thread; wire bytes rate-governed under CBR + 1-frame VBV (the ~1-2 % slice-header cost is absorbed by rate control, not added to the wire). GameStream: plane has zero code diff (own RTP packetizer; shares only untouched send_pacing); a live Moonlight re-test joins the standing owed Moonlight item. - resolve_slices(codec, default): env 1..=32 wins (1 = the NEW explicit single-slice escape), else the backend default — 4 on Linux direct-NVENC, 1 elsewhere. resolve_subframe(default_on): PUNKTFUNK_NVENC_SUBFRAME tri-state (0 = never, 1 = force, unset = backend default). - Linux nvenc_cuda: resolves both ONCE in query_caps — the sub-frame default is gated on the GPU's SUBFRAME_READBACK cap so an unsupporting GPU never has enableSubFrameWrite forced into its init params — and feeds the same resolved values to build_config, build_init_params (open AND in-place reconfigure) and the chunked-poll latch. - Windows: env-only as before (async path untouched, byte-identical config for unset env); LowLatencyConfig.slices + the explicit subframe param replace the shared env reads. - Tests: chunked e2e now runs at the DEFAULTS (no knobs); the fallback test becomes the escape test (SLICES=1 disarms; SUBFRAME=0 disarms while 4-slice encode continues on the plain poll path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 23:44:41 +02:00
enricobuehlerandClaude Opus 4.8	c6caeca5bc	feat(encode): RGB-direct (EFC) is now the DEFAULT on capable hosts — gated by a session cursor-blend hint ... B2 default-on (design/vulkan-rgb-direct-encode.md): wherever the probe passes, Vulkan Video sessions now take the EFC RGB source by default — direct import on aligned modes, padded-copy staging on unaligned ones (1080p). PUNKTFUNK_VULKAN_RGB_DIRECT becomes the override: =0 disables, =1 forces, unset = the default below. The one session class that must NOT default on: cursor-as-metadata captures (every non-gamescope compositor), where the CSC shader's blend IS the visible pointer — the EFC cannot composite, and defaulting there would silently drop the cursor from the stream. The hint rides the existing plumbing: - SessionPlan gains cursor_blend, resolved once where the compositor is known (gamescope embeds the pointer itself → false; kwin/mutter/ wlroots/hyprland → true), and shows up in the logged plan line. - open_video/open_video_backend thread it through (native pump: all three encoder-open sites read plan.cursor_blend; GameStream monitor capture: true — it negotiates metadata cursor; spike: false). - VulkanVideoEncoder::open resolves: env override, else ON iff the session never hands us cursor bitmaps. The warn-once for a cursor on an RGB session (forced via =1) stays. Verified on-hw box (Linux): pf-encode + punktfunk-host compile, clippy clean, unit suite green. The GPU paths themselves are unchanged from the smoke-validated 96e19986 — this commit only changes which sessions select them by default. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 23:24:46 +02:00
enricobuehlerandClaude Fable 5	9d3b114fd6	feat(encode/nvenc): LN1 phase-1 — slice-boundary chunked encoder poll (poll_chunk/AuChunk) ... The encoder half of sub-frame slice output (latency §7 LN1, planning design/nvenc-subframe-slice-output.md Phase 1): with PUNKTFUNK_NVENC_SLICES=N + PUNKTFUNK_NVENC_SUBFRAME=1 on a sync depth-1 session, Encoder::poll_chunk hands the in-flight AU out as slice-boundary chunks read through doNotWait sub-frame locks while the tail is still encoding — the readback loop the on-hw probe validated (~200 µs slice spacing on the 5070 Ti), productionized. - codec.rs: AuChunk (AU metadata on the first chunk, `last` closes the AU; chunks concatenate to exactly the poll() bytes) + supports_chunked_poll / poll_chunk trait surface. Default impl wraps poll() as one self-closing chunk, so a chunk-driven consumer works against every backend. - nvenc_cuda: chunked readback cut at slice boundaries only (bitstream size at n reported slices = end of slice n, Annex-B contiguous); completion is NEVER numSlices alone — one finishing BLOCKING lock is the authority and the wedge watchdog, so the final chunk blocks exactly like sync poll (the depth-1 pump contract; 6dc195f9 bug class). Keyframe on early chunks is the submit-time IDR prediction (exact under P-only/infinite-GOP), cross-checked at finish. Debug builds shadow-check emitted chunks against the finished AU prefix. Mutually exclusive with pipelined retrieve (gated off when async_rt exists, dropped by the escalation rebuild); composes with stream-ordered submit. - nvenc_core: slices_env/subframe_requested shared parses so the config author and the chunked-poll arming can't disagree. - TrackedEncoder forwards both new methods (the set_wire_chunking trap class). Host loop untouched — Phase 2 (VIDEO_CAP_STREAMED_AU seal/send) consumes this. On-hw: nvenc_cuda_chunked_poll_end_to_end + nvenc_cuda_chunked_poll_fallback_whole_au. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 20:53:32 +02:00
enricobuehlerandClaude Fable 5	411c6dc06a	fix(encode): forward set_pipelined through TrackedEncoder — the LN3 escalation no-oped through the wrapper ... Every session encoder is boxed in TrackedEncoder (open_video), and the wrapper never forwarded Encoder::set_pipelined — so the host loop's contention escalation (ae673158) hit the trait default, which returns false ("backend can't pipeline, stop asking"), and the pipelined-retrieve stage could never engage adaptively. Only the explicit PUNKTFUNK_NVENC_ASYNC=1 open-time path worked. The exact defaulted-method trap the wrapper's own comment documents for set_wire_chunking. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 20:53:32 +02:00
enricobuehlerandClaude Opus 4.8	96e19986bc	feat(encode): RGB-direct padded-copy — unaligned modes (1080p) get the EFC path safely ... Lifts 3aacec53's alignment gate into a mode select: an aligned mode keeps the true zero-copy direct import; an unaligned one (1080p!) now blits the visible frame into a per-slot ALIGNED BGRA staging image and duplicates the edge rows/columns into the 64x16 padding — transfer-only regions in one vkCmdCopyImage (1080p: visible + 8 row regions; width padding adds a second self-copy pass in GENERAL), no compute shader. The encode reads the staging image, never the capture buffer, so the EFC can never read past a producer allocation (the field GPU hang). Still one ~8 MB copy vs the CSC path's ~17 MB + dispatch + plane copies. Verdict line: active(padded-copy). The staging import drops the video profile entirely (TRANSFER_SRC only). CPU-payload paths made honest on the way (they were the smoke baseline AND the software-capture fallback): - rgb mode: the staging upload is padded CPU-side (edge duplication) so the aligned encode-src is fully defined; - CSC mode: the sampled image is now SOURCE-sized with a matching copy extent — the old aligned-size image + tightly-packed buffer sheared rows and left garbage rows at unaligned modes (black-bar artifacts; YMIN=16 in every smoke frame), which also masked as a 24 dB PSNR 'regression' against the (correct) padded output. On-glass (780M, host Mesa 26.0.4): all four smokes pass at 256x256 (direct) AND 250x250 (padded); padded-EFC frames decode perfectly uniform (YMIN==YMAX) at the exact 709-narrow values (79/148/60 for the first three fills); CSC-vs-padded PSNR 49.9 dB avg after the baseline fix. clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 20:38:55 +02:00
enricobuehlerandClaude Opus 4.8	3aacec53d8	fix(encode): RGB-direct must not engage on unaligned modes — the EFC reads past the capture buffer (GPU hang) ... Field report (commit 25624443, RDNA2/VCN3 host, 1080p): repeated VCN0 VM protection faults from punktfunk-host, vcn_enc_0.0 ring timeouts, two ring resets, then a failed reset escalating to a full MODE1 GPU reset with VRAM loss. Root cause is B1's RGB-direct source: the session's coded extent is 64x16-aligned (1920x1088) but the captured dmabuf is only the real mode size (1920x1080) — the VCN EFC reads the 8 padding rows past the end of the buffer (8 x 7680 B = 61 KB, matching the faulting page span exactly). The CSC shader absorbs alignment by clamping reads and duplicating edges; RGB-direct has no such stage. Every prior validation surface happened to be aligned (256x256 smoke, 1440p live box) — 1080p is the common mode that is not. The stall watchdog's rebuild-and-refault loop then turned a per-session fault into the GPU death spiral. Two layers: - Open-time gate: RGB-direct engages only when the real mode equals the aligned coded extent (720p/1440p/4K yes, 1080p no); otherwise the CSC path runs and the verdict line says why (unaligned-mode). The padded- copy variant that re-enables 1080p is design-doc B2 work. - Submit-time check: an RGB-direct frame that does not cover the coded extent errors out (encoder-rebuild path) instead of importing an undersized source. On-glass (780M, host Mesa 26.0.4): all four smokes pass aligned; at PF_SMOKE_W/H=250 the gate refuses RGB-direct and the rgb smokes soft-skip. clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 20:23:29 +02:00
enricobuehlerandClaude Fable 5	ae67315804	perf(encode/nvenc-linux): LN3 — pipelined-retrieve escalation replaces the depth-1 async foot-gun ... PUNKTFUNK_NVENC_ASYNC gains a real tri-state: 1 = always (as before, now documented as ~+1 tick at depth-1), 0 = never (vetoes escalation), unset = ADAPTIVE — off until the session loop's cadence-overrun detector escalates. The host loop's adaptive-depth leaky bucket grows a second stage: once the capturer's depth is maxed (Linux portal is permanently depth-1), it asks the encoder for pipelined retrieve via the new Encoder::set_pipelined hook (asked exactly once; default impl declines, Windows untouched). nvenc_cuda engages at a safe point via a clean session rebuild WITHOUT the IO-stream binding: with input==output stream bound, later stream work waits on prior encode completions and would serialize a pipelined session — stream-ordered submit and two-thread retrieve are mutually exclusive. The ordered gate now also requires async_rt absence (belt-and-braces for the runtime switch). Re-open's first frame is the standard session IDR. On-hardware test: escalate mid-session → retrieve thread live, binding gone, all AUs deliver, first post-escalation AU is the IDR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 20:10:24 +02:00
3 people	256244430b	feat(encode): Vulkan Video B1 — RGB-direct encode source via VCN EFC (PUNKTFUNK_VULKAN_RGB_DIRECT=1) ... design/vulkan-rgb-direct-encode.md B1: when the probe passes AND PUNKTFUNK_VULKAN_RGB_DIRECT=1 (default OFF until the B2 on-glass A/B), the session opens with pictureFormat=B8G8R8A8 and the captured RGB frame becomes the encode source — the VCN EFC front-end does the 709-narrow CSC inline during encode. Deleted from the per-frame path: the compute CSC dispatch, both NV12 plane copies, the semaphore hop and one queue submit (dmabuf frames are ONE encode-queue submit; ~17 MB/frame of GPU traffic gone). The DPB stays NV12; RFI/RC/quality-level machinery is untouched. Shape: - probe_rgb_direct now returns the chroma-siting bits to create the session with (midpoint preferred, else cosited-even per axis); the open verdict line gains "active" / "available(off; ...)" states. - RgbProfileStack: the rgb-chained video profile rebuilt on the stack per profiled-image creation after open (profile identity is by value) — dmabuf imports become profiled VIDEO_ENCODE_SRC images (import cache unchanged), the CPU staging image likewise (concurrent encode+compute). - record_submit_rgb: steps 2–4 twin (dmabuf: single submit; CPU: staging copy on the compute queue, semaphore-ordered); shared step-1/bookkeeping. - begin_encode_cmd takes a SrcAcquire (CSC general / fresh-import FOREIGN QFOT / cached visibility-only / staging TRANSFER_DST) so both paths share the encode recording. - RGB-direct frames skip the CSC per-slot resources entirely (make_frame split into csc/common halves); cursor bitmaps warn once (EFC cannot composite; gamescope — the flagship — embeds the cursor itself). On-glass (780M RADV PHOENIX, host Mesa 26.0.4): all four smokes pass (vulkan_smoke{,_av1,_rgb,_rgb_av1}); the EFC-encoded H265 stream decodes clean and matches the CSC-encoded stream at 49.9 dB average PSNR (min 48.9) — within the design's ±1-code-value tolerance. (Raw-OBU ffmpeg probing of the tiny AV1 dumps fails identically for BOTH paths — pre-existing dump quirk, not a stream defect.) check+clippy+full unit suite green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 20:05:56 +02:00
enricobuehlerandClaude Fable 5	5a27c02738	feat(encode/nvenc): LN1 phase-0 — slice-count + sub-frame-readback knobs and the slice-timing probe ... PUNKTFUNK_NVENC_SLICES=N (2..=32, default off) splits H.264/HEVC frames into N slices (sliceMode 3); PUNKTFUNK_NVENC_SUBFRAME=1 (default off) arms enableSubFrameWrite + reportSliceOffsets on sync sessions only. Both experimental groundwork for sub-frame slice output (plan §7 LN1). nvenc_cuda_subframe_slice_probe (on-hardware, ignored) answers the LN1 go/no-go: spins lock_bitstream(doNotWait) against an in-flight frame and prints the (t_us, status, numSlices, bytes) timeline — incremental slice availability and its spacing, or all-at-completion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:44:54 +02:00
3 people	d5a0f5012b	fix(encode): RGB-direct probe — accept cosited-even chroma siting (what VCN EFC actually offers) ... On-glass B0 result from the 780M (RADV PHOENIX, host Mesa 26.0.4): the probe returned no-709-narrow-midpoint because RADV advertises xChromaOffsets = COSITED_EVEN only — the VCN EFC does canonical H.26x left-cosited x-chroma, while the requirement was written to bit-match our 2x2-average (midpoint) shader. The delta is a half-pel chroma-x phase, imperceptible and unsignalled in our bitstream; EFC's siting is arguably the more correct one. Accept either siting bit per axis (model + range stay exact: 709 narrow); B1 will pass the preferred available bit. With this the 780M probes rgb_direct=available; both GPU smoke tests (H265 + AV1) pass on that box against host Mesa 26.0.4 — the first real-RADV validation of the poll fix, the quality-level control, and B0. (Container mesa alone can't run the H265 smoke: Fedora ships RADV with H264/H265 encode compiled out — AV1 only. Use the host ICD via VK_ICD_FILENAMES on Atomic boxes.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:44:33 +02:00
enricobuehlerandClaude Fable 5	34ec57cb52	test(encode/nvenc-linux): on-hardware assertion that stream-ordered submit arms ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehlerandClaude Fable 5	cd36c46388	perf(encode/nvenc-linux): LN2 v1 — stream-ordered submit via NvEncSetIOCudaStreams ... Bind the session's IO streams to the encode thread's high-priority copy stream: in sync-retrieve depth-1 use the per-frame input copy and cursor blend now enqueue with NO cuStreamSynchronize and encode_picture orders after them on the stream. Same stream both directions, so the encode's completion is inserted into the stream and later work (the next frame's copy into a reused ring slot) waits for it. Soundness gate: the fast path engages only when pending is empty (true depth-1 usage) — every prior encode was drained by a blocking poll, and the caller holds the frame payload across the matching poll (contract now documented on Encoder::submit; both host loops already comply). Pipelined callers and PUNKTFUNK_NVENC_ASYNC mode keep the blocking copies. True zero-copy input registration (registering the worker-owned IPC buffer directly) stays the LN2 v2 follow-up — it needs a contiguous worker-pool NV12 layout and a registration<->IPC-mapping lifetime tie. PUNKTFUNK_NVENC_STREAM_ORDERED=0 restores the old blocking behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehlerandClaude Fable 5	59b6d3796b	perf(encode/nvenc-linux): LN0 — sampled submit/retrieve-lock split, sub-frame caps, zeroReorderDelay ... Latency plan §7 LN0 (Linux/NVIDIA encode follow-on): - sampled PUNKTFUNK_PERF submit split (copy/blend/map/pic) in nvenc_cuda — the host loop's submit_us folds all four together; the D2D input copy is the LN2 zero-copy target and now measurable on its own - sampled blocking lock_bitstream timing on pf-nvenc-out — in two-thread mode the host loop's wait_us wraps a non-blocking poll, so the real encode wait was measured by no timer - caps probe + log SUPPORT_SUBFRAME_READBACK / SUPPORT_DYNAMIC_SLICE_MODE (LN1 sub-frame slice-output prerequisites, fleet visibility) - explicit zeroReorderDelay=1 in the shared low-latency config (P-only + no lookahead has no reordering anyway; pins the bit against preset or driver drift; shared with the Windows backend) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehlerandClaude Opus 4.8	78dba293a8	feat(encode): Vulkan Video B0 — vendored VK_VALVE_video_encode_rgb_conversion + RGB-direct probe telemetry ... First phase of design/vulkan-rgb-direct-encode.md (punktfunk-planning): make the captured BGRx dmabuf the direct encode source with the VCN EFC front-end doing the 709-narrow CSC — deleting the per-frame compute CSC, both plane copies, the semaphore hop and one queue submit. B0 changes nothing about the encode path. It vendors the extension surface (vk_valve_rgb.rs — ash 0.38 predates it; same rationale and style as the vk_av1_encode module) and probes at open whether this host qualifies: extension present (Mesa >= 26.0 + EFC hardware) → feature bit → conversion caps cover the compute shader's exact math (709 / narrow / midpoint both axes) → encode-src format set offers B8G8R8A8 with DRM-modifier tiling. The verdict is one INFO line (rgb_direct=available | first missing requirement) — the field telemetry that decides where B1 can default on. Verified: cargo check + clippy clean + unit tests green (Linux box); the probe short-circuits to no-ext on non-RADV drivers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:29:22 +02:00
enricobuehlerandClaude Opus 4.8	cfdec2729d	perf(encode): Vulkan Video — explicit VCN preset, persistent bitstream map, CSC split timing ... Field follow-up to 6dc195f9 (the AMD host whose H265 encode sits at ~5 ms): the remaining time is the VCN ASIC preset, and we never chose one. 1. Explicit encode quality level. RADV only emits a VCN preset op when the app issues ENCODE_QUALITY_LEVEL — we never did, so every session ran the firmware's default preset. Install the resolved level on the first frame's RESET control (chained ahead of the CBR state, which satisfies the spec's quality-change-carries-rate-control rule) and bake the same level into the session-parameters object (the spec requires the match). Default 0 = the fastest tier the driver exposes (RADV: SPEED, except H265 on pre-RDNA4 which the driver pins to BALANCE); clamped to the profile's maxQualityLevels. PUNKTFUNK_VULKAN_QUALITY=0..3 overrides for quality-biased setups. Logged at open so field logs show the tier. 2. Persistent bitstream mapping. read_slot vkMapMemory/vkUnmapMemory'd the host-visible bitstream buffer every frame; map each ring slot once at build instead (coherent memory; vkFreeMemory implicitly unmaps). 3. PUNKTFUNK_PERF CSC split. GPU timestamps bracket the compute batch (import barriers + cursor prep + CSC dispatch + plane copies) and a sampled csc_us line logs every ~2 s — separating shader/copy time from the ASIC encode inside the pump's wait_us, the VAAPI submit-split analog for this backend. Off (and unrecorded) unless PUNKTFUNK_PERF. Verified: cargo check + clippy + DPB/RPS unit tests green (Linux box). The GPU smoke tests still need a RADV host (NVIDIA driver fails session open on the build box, pre-existing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:17:34 +02:00
3 people	6dc195f982	fix(encode): Vulkan Video poll() must block per the depth-1 pump contract ... The session pump's depth-1 loop (capture → submit → poll) treats a poll() None as "the backend holds the frame internally, re-poll next tick" — true only of the libav AMF/QSV wrappers, whose codecs genuinely hold ~2 frames. The Vulkan Video backend probed its slot fence with get_fence_status instead, so the AU of every frame — finished on the ASIC in ~5 ms — sat unharvested until the tick AFTER the next frame was submitted: encode_us read as one full frame period (~17 ms at 60 Hz vs VAAPI's ~5.3 ms on the same VCN, the AMD field report) and every frame shipped a frame period late — one frame of avoidable glass-to-glass latency on the path that exists to beat libav VAAPI. Wait the oldest in-flight slot's fence in poll() instead, matching the sync NVENC backend's blocking lock_bitstream and the documented Capturer::pipeline_depth contract ("capture → submit → poll-blocks"). Bounded by ENCODE_FENCE_TIMEOUT_NS like enqueue()'s backpressure wait, for the same reason: poll runs on the thread the stall recovery runs on, so a wedged GPU must surface as an error, not park it. None now only means "nothing submitted". Covers H265 and AV1 (shared poll). Verified: cargo check + DPB/RPS unit tests green (home-worker-5); the GPU smoke tests fail at session open on that box's NVIDIA driver identically on unmodified origin/main — pre-existing, needs the RADV box for on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:53:21 +02:00
enricobuehler	1e8b267d93	Merge branch 'fix/vulkan-open-leak' into land/sweep-all	2026-07-20 00:43:19 +02:00
enricobuehlerandClaude Fable 5	28491acf2a	fix(encode): unwind Vulkan Video open failure instead of leaking every prior object ... VulkanVideoEncoder::open_inner creates ~20 Vulkan objects across ~15 fallible steps, but all cleanup lived in the encoder's Drop — which only runs once the value exists at the final Ok(Self). Any earlier ?/bail! leaked everything built so far (a VkDevice + GPU memory per retried open, and this backend is the default encode path on AMD/Intel Linux hosts where open can fail transiently). Factor the entire teardown sequence — unchanged — into a VkTeardown guard whose Drop destroys any prefix of the build (vkDestroy*/vkFree* are defined no-ops on VK_NULL_HANDLE): open_inner mirrors each object into the guard as it is created and disarms it only at Ok(Self); the encoder's own Drop rebuilds one from its fields, so both paths share one sequence and cannot drift. make_frame now builds in place into a guard-parked null Frame so a mid-build failure unwinds its partial handles too, and make_video_image / vk_util::make_plain_image (also used by the PyroWave backend) / build_parameters_h265 no longer leak their own partially-created objects on failure. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 22:15:44 +02:00
enricobuehlerandClaude Opus 4.8	b0fbb80fd5	fix(encode): key the PyroWave plane-import cache on the capturer's ring generation ... Completes the partial fix from the previous commit. The Windows PyroWave backend caches its imported plane images keyed on the D3D11 texture's COM address, and holds no reference on that texture — so once the capturer recreates its ring, those addresses can be handed straight back out by the allocator and a pointer-keyed cache hit returns an image bound to a texture that no longer exists. Adding the extent to the key ruled out same-address-different-size aliasing, but a recycle at identical dimensions still aliased. The capturer already tracks exactly the value needed: `generation`, bumped on every ring recreate. Plumbed it onto `PyroFrameShare` and the encoder now flushes every cached import when it changes, which makes cache identity independent of allocator behaviour rather than a bet against pointer reuse. Validated on the RTX box: `pyrowave_win_smoke` (forced with `--ignored`, the only test that actually exercises this path on real hardware) passes all ten configurations — 1024²/720p/1080p/1440p across SDR/HDR and 4:2:0/4:4:4 — with correct decoded chroma means, so the steady-state cache-hit path still works. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:45:14 +02:00
enricobuehlerandClaude Opus 4.8	6f52397342	fix(encode): bound NVENC async pipelining by the capturer's texture ring ... The Windows direct-NVENC backend registers and encodes the capturer's textures IN PLACE (no CopyResource), so how deep it may pipeline is a property of the CAPTURER, not of the encoder. It was bounded only by `async_inflight_cap()` — `PUNKTFUNK_NVENC_ASYNC_DEPTH`, default 4, clamped to the output-bitstream pool — which consults nothing about the capturer, while the comment at the backpressure loop claimed it "keep[s] in-flight depth within the capturer's texture ring". It never did. The IDD-push capturer rotates `OUT_RING = 3` per delivered frame with no regard for encode completion (its own invariant note says OUT_RING(3) > max pipeline_depth(2)). With the default async depth of 4 the encoder can therefore still be reading a texture the capturer has already handed out again and overwritten: torn or mixed frames. It is visual corruption rather than UB, so it fails silently and intermittently — the worst shape to diagnose from a field report. Adds `Encoder::set_input_ring_depth`, reported from `Capturer::pipeline_depth`, and bounds the async backpressure loop by `min(async_inflight_cap(), depth)`. For IDD-push that yields 2, matching the capturer's stated contract; backends that copy their input, or are synchronous, ignore it. Wired at ALL THREE encoder-creation sites (initial open, stall/resize rebuild, ABR rebuild) and forwarded through `TrackedEncoder` — this crate has a documented trap where an unforwarded defaulted trait method silently no-ops through that wrapper, which has already bitten the direct-NVENC work once and the wire-chunking probe once. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:42:53 +02:00
enricobuehlerandClaude Opus 4.8	a38adad943	fix(encode): bound GPU waits, validate encode status, repair command-buffer and cache invariants ... Five of the nine medium findings from the pf-encode sweep. The remaining four need cross-crate plumbing or an unwind refactor and are deliberately left out. - vulkan_video `enqueue` waited on the backpressure fence with `u64::MAX`. That wait runs ON the host encode thread — the same thread the stall watchdog's `reset()` would run on — so a wedged GPU parked the one thread that could recover the session: no error, no reset, and teardown blocking on the join. This is the DEFAULT encode path for AMD/Intel Linux hosts (both shipped build recipes enable `vulkan-encode` and `vulkan_encode_enabled()` defaults true). Now bounded by ENCODE_FENCE_TIMEOUT_NS with expiry surfaced as an error. - vulkan_video `import_cached` evicted a cached dmabuf import and destroyed its image/view/memory with no fence wait, while up to `ring_depth - 1` submitted frames may still reference it — a GPU-side use-after-free. `Drop` and `reset` both idle first; this was the one unguarded destroy. Now idles before the eviction loop, guarded on the length test so the steady state pays nothing. - vulkan_video `read_slot` never asked for the encode's operation status, so a FAILED encode was indistinguishable from a successful one and its feedback was read as if it described real bitstream. Now requests WITH_STATUS_KHR and refuses anything that is not COMPLETE. - linux/pyrowave `encode_frame` opens its recording window early and has six fallible steps inside it; every one returned with `cmd` still RECORDING, and nothing repaired it (one `begin_command_buffer` in the file, and neither `reset()` nor `Drop` touches `cmd`), so the next frame called `begin` on a recording buffer — invalid usage. `submit` now resets the buffer on error; legal on all these paths since the pool carries RESET_COMMAND_BUFFER and the buffer is not pending. - windows/pyrowave `encode_frame` ignored `frame.width`/`height` and imported planes at the encoder's configured extent, so a ring recreate at a new mode (the IDD capturer does this autonomously on a confirmed descriptor change) read the planes under a stale VkImageCreateInfo. Added the size guard its QSV and AMF siblings already carry, and keyed the plane cache on (address, width, height) so a recycled COM address cannot resurrect an import of a different size. NOTE: a recycle at the SAME size is still theoretically possible; the complete fix keys on the capturer's ring generation and needs that plumbed onto `PyroFrameShare`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:34:16 +02:00
enricobuehlerandClaude Opus 4.8	b22d0da75b	fix(encode): port the RFI taint sweep to Vulkan Video, close the QSV sweep hole, bounds-check encode feedback ... Three defects from the pf-encode sweep, each adjudicated against source. - Vulkan Video never received fecbec2d's taint sweep (it was carved out one commit later). `pick_recovery_slot` accepts any resident slot whose wire is below the CURRENT loss start, but "resident and older than this loss" is not "the client decoded it": after an earlier loss [a,b] recovered at wire r, everything in [a, r-1] is undecodable at the client — the lost frames plus every frame that predicted through the gap — and those wires stay eligible until the 8-slot ring rolls them out. A later loss could therefore anchor on one and ship it tagged `recovery_anchor`, which is the client's definitive re-anchor signal (punktfunk-core/src/reanchor.rs): the host lifts the client's post-loss freeze onto a picture built from a reference it never had. Swept before anchor selection, matching AMF/QSV. `slot_wire` is blanked and `slot_poc` deliberately is NOT: `slot_poc` feeds `build_h265_rps_s0`, which must keep naming every physically-resident DPB picture or a conforming decoder evicts them and the anchor then references a picture the client already dropped. - QSV's sweep was incomplete, and in its MODAL case. `ltr_slots` mirrors the hardware DPB, but nulling an entry issues no VPL call — the frame stays marked long-term until that LongTermIdx is re-marked or an IDR flushes it (amf.rs states this verbatim). The rejection loop iterates the post-sweep mirror and only rejects `Some` slots, so it silently skipped the single entry the sweep exists to distrust, leaving the recovery frame free to predict from it. With NUM_LTR_SLOTS=2 the "exactly one slot swept" case is the common one, and the two existing tests cover only the both-survive and both-swept cases. Taint is now recorded in `ltr_tainted` with the FrameOrder left in place, so anchor selection and the queued-force guard skip it while the rejection list still names it. - `read_slot` built a slice from the driver-reported (offset, bytes-written) encode feedback with no validation against `bs_size`, so a driver reporting a range outside the bitstream buffer produced an out-of-bounds read shipped straight onto the wire. Checked in u64 (so the add cannot wrap) before `map_memory`, so the error path has no unmap to unwind. Adds `taint_sweep_excludes_slots_from_an_earlier_loss` covering the two-loss case the existing single-loss test does not reach. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:18:17 +02:00
enricobuehlerandClaude Opus 4.8	f9668b16a1	fix(encode): NVENC partial-init session leak + three backend-parity gaps ... All four found in the pf-encode quality sweep and verified against source. - NVENC partial-init leak (BOTH platforms, high): `init_session` publishes `self.encoder` — and on Windows charges LIVE_SESSION_UNITS — *before* its remaining fallible steps (bitstream buffers; on Linux also the input-surface alloc and `register_resource`). A failure there left a live session with `inited == false`, and every guard on the re-init path keys off `inited`, so the next submit skipped teardown and overwrote `self.encoder`: the session leaked permanently toward the driver's per-process cap, and its budget units never returned, progressively starving parallel-display admission. `teardown` already keys off `encoder.is_null()` rather than `inited`, so it cleans up exactly this half-built state — it just was never called. Now invoked on the `init_session` error path on both platforms. - `can_encode_10bit` asked the wrong backend (medium): it resolved via `linux_auto_is_vaapi`, which ignores `encoder_pref`, while `can_encode_444` and `open_video` honour it. On a host that forces a backend (e.g. `encoder_pref = "vaapi"` on an NVIDIA box) the probe answered for NVENC while the session opened VAAPI, so the negotiated bit depth — and the HDR/SDR colour label derived from it — described a backend that never ran. Now uses the same `linux_zero_copy_is_vaapi` mirror, and `linux_auto_is_vaapi` carries a warning that it resolves the `auto` case only and is not a dispatch mirror. - Linux software arm ignored SW_BITRATE_CEIL (low): the Windows arm clamped openh264 to 100 Mbps, the Linux arm passed the full negotiated rate. The constant is now module-scope so both arms share one value. - QSV/AMF env-parity (low): `PUNKTFUNK_IR_PERIOD_FRAMES` was a no-op on QSV despite the comment claiming parity with AMF, and `PUNKTFUNK_NO_QSV_LTR` / `PUNKTFUNK_INTRA_REFRESH` had dropped AMF's `trim()` and `yes`/`on` spellings, so a value with stray whitespace silently did nothing on Intel while the same value worked on AMD. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:47:55 +02:00
enricobuehlerandClaude Opus 4.8	04e4394ee0	fix(encode): close the two teardown memory-safety holes in the reset paths ... Both surfaced in a post-refactor quality sweep of pf-encode and were then verified against the source (and, for pyrowave, against the C side). - PyroWave (BOTH platforms): `reset()` destroyed the encoder and, when the rebuild failed, returned `false` leaving `pw_enc` pointing at the freed object — `Drop` then destroyed it a second time. `pyrowave_encoder_destroy` is a plain `delete` (pyrowave_c.cpp:1184, which also reads `encoder->device` afterwards) with no null check, so this is a real double free. The failure branch is not vacuous: the rebuild fails when the device is lost/OOM, which is exactly the state that makes the stall watchdog call `reset()` in the first place, so the host corrupts its heap on the path that runs when things are already going wrong. Now nulls `pw_enc` before the fallible create, publishes only on success, and null-guards both `Drop` and `encode_frame` (the Windows `Drop` already guarded `sync` this way). - QSV: `reset()` dropped `pending` — each entry owning the `Box<BsBuf>` the runtime writes into asynchronously — BEFORE `MFXVideoENCODE_Close` aborted those operations, so the VPL runtime could write into freed heap. The preceding drain is best-effort and bails on the first `Err`, i.e. precisely the wedged-encoder case that triggers the reset. Fixed by ordering: Close, then clear. The full-teardown path was already correct (`Inner` declares `session` before `pending`, and fields drop in declaration order). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:07:57 +02:00