28 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	ebf61cb448	Merge branch 'worktree-wave2-pw5-encode-overlap' into worktree-wave2-pyrowave ... # Conflicts: # crates/pf-encode/src/enc/linux/pyrowave.rs	2026-08-09 01:14:59 +02:00
enricobuehler	7d37fe450d	test(pf-encode): run PyroWave at depth 2 on real hardware — without shipping depth 2 ... Wave-2 PW5, the stage-6 experiment. Shipped behaviour is UNCHANGED: `max_inflight` is still 1. Stage 6 is the frame-corruption stage, and its gate is an on-glass tear-hunt with a live compositor, a real client and ten minutes of moving content. That is not runnable from here. But the depth-2 risk has two halves, and one of them lives entirely in this crate — the per-slot resources (`cmd`/`fence`/`csc_set`/y/uv/cursor) and the alternating encoder handles — so that half can be answered now, on the GPU, and the answer is worth having before anyone attempts the other. The experiment drives the backend with two frames genuinely in flight (submit N+1, then poll N) and compares the result against the encoder's OWN synchronous output over the same 16 moving frames. Its own depth-1 decode is the honest reference: pyrowave's raw AU bytes are not reproducible run-to-run (see the stage-3 commit), but its decoded planes are. RESULT, .21 / RTX 5070 Ti (GPU idle at 180 MHz of 3090 — the slow-clock worst case on this card): depth-2 vs depth-1 over 16 frames: worst-case PSNR identical (inf) Bit-identical luma, every frame, in order. So stages 4 and 5 between them are sufficient for the encoder side: doubling the six single-slot resources and alternating two `pyrowave_encoder` handles under one monotonic wire sequence really does make overlap invisible to the decoder. The test is built to fail rather than to pass. Content MOVES every frame (flat fills are the documented false-green trap — a torn frame stitched from two halves of a static card is invisible), it asserts two frames were ACTUALLY in flight rather than silently proving nothing, it asserts the AU count is unchanged, and it carries an off-by-one discriminator that raw PSNR would miss: each overlapped frame must match its own reference BETTER than it matches the previous one, so a pipeline delivering frames one position late fails even though every individual PSNR looks fine. It reaches `max_inflight` directly instead of through a shipped knob, precisely so the shipped value stays 1. ⚠ WHAT THIS DOES NOT COVER, stated here so the next person does not read it as a green light for stage 6: the CAPTURE side. `.process` hands the SPA buffer back to the compositor at callback return while the encode thread holds only a dup of its dmabuf fd, so a second frame in flight widens the window in which the producer may overwrite a buffer we are still reading by a full frame period. Nothing in this crate can test that — it needs a live producer. Stages 1 and 2 are what make it answerable (the pool census says how deep the producer's ring is; the Choice range asks for headroom), and the on-glass hunt is what would settle it. Gates green at CI parity.	2026-08-09 00:30:25 +02:00
enricobuehler	077db416ec	feat(pf-encode): two PyroWave encoder handles, and the 3-bit landmine that makes them work ... Wave-2 PW5 stage 5. Depth is STILL 1 — the handles alternate per frame, one in flight. PyroWave's `Encoder` cannot hold two frames. Not "probably not" — structurally not. `Encoder::Impl` owns ONE each of `wavelet_img_high_res`, `bucket_buffer`, `meta_buffer`, `block_stat_buffer`, `payload_data` and `quant_buffer`, and `Impl::encode` OPENS by discarding them: an image barrier with `VK_IMAGE_LAYOUT_UNDEFINED` as the old layout — a written promise that nothing else is reading it — plus three `fill_buffer` clears. Two encodes recorded into two command buffers and submitted to one queue have no execution dependency in Vulkan (submission order orders the START, not the completion), so N+1's DWT would overwrite the wavelet bands and zero the RDO buckets while N's block packing still reads them. Content-dependent, silent. So overlap means TWO handles on one device, alternated — one per slot. Every resource above is then private per handle, and within a handle the encodes stay strictly serialized (a slot's next frame is recorded only after that slot's previous one retired), which leaves patch 0004's scratch-pool invariant intact without touching it. THE LANDMINE, and it is the reason this stage is its own commit: `sequence_count` ALSO lives on `Impl`, and it is the 3-bit counter stamped into every block header. Two handles each count 1,2,3... alone, so the wire sees 1,1,2,2,3,3.... The decoder restarts a frame only when the value CHANGES (`diff = (hdr.sequence - last_seq) & 0x7; restart = diff != 0`), so a repeat reads as MORE BLOCKS OF THE SAME FRAME: `clear()` never runs, `decoded_frame_for_current_sequence` stays true, and the second frame of each pair is swallowed. Half frame rate, occasional mixed-frame blocks, no error anywhere — on every client, since pf-client-core and the Apple Metal hand-port parse the same field. `patches/0007-encoder-sequence-override.patch` (new, ~38 lines) exposes `Encoder::set_next_sequence` + a `pyrowave_encoder_set_next_sequence` C entry + a `PYROWAVE_SEQUENCE_MASK` define, so ONE monotonic counter on the Rust side is stamped regardless of which handle encodes. The setter stores `(seq - 1) & mask` because `Impl::encode` pre-increments — its contract is about the next ENCODE, not the next store. Inert when unused, so the whole Windows backend is untouched. No `.def` change: the C API is a static archive. PREDICTED, THEN OBSERVED. A negative control on .21 (the override call removed, nothing else) reads the wire out at exactly: [1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 0, 0, 1, 1, 2, 2] which is the analysis's prediction character for character, and with the override: +1 mod 8, all 20 frames, through the 3-bit wrap. THE GATE, `wire_sequence_increments_across_alternating_handles`, checks three things over 20 frames because any one alone could pass while the stream is broken: the wire counter advances by 1 mod 8; ONE persistent decoder (its `last_seq` carried across every push, exactly like a client's) reports every AU decodable; and consecutive decoded pictures DIFFER. Content moves every frame — and the first run caught a trap in the harness itself rather than the encoder: `test_card` starts its LCG at `seed | 1`, so seeds 2 and 3 build a byte-identical card and the test faked the very repeat it hunts. Odd seeds only now, with the reason written down. A runtime self-check backs the test up where the test cannot reach: after packetize, the stamped sequence is compared against what we asked for, and a mismatch logs once per process naming patch 0007. A re-vendor that loses the patch would not fail to build — it would fail on glass, subtly, and this makes it loud instead. Two byte reads per frame. `reset()` rebuilds both handles and `Drop` destroys both, each with the same null-immediately discipline the single handle had (`pyrowave_encoder_destroy` is a bare `delete` with no null check, so a stale pointer left in the field is a double free). Vendored-patch discipline: patch 0007 re-applies clean to a pristine vendor checkout (verified by stashing the vendor tree and re-applying), and `git diff crates/pyrowave-sys/vendor/` touches exactly the four intended files. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090): all 8 `#[ignore]`d GPU tests pass, including the new gate and the 4:2:0 / 4:4:4 / 24-bpp PSNR smokes. Gates green at CI parity.	2026-08-09 00:27:28 +02:00
enricobuehler	29248dcab9	feat(pf-encode): PyroWave had six single-slot resources, not the two the plan named ... Wave-2 PW5 stage 4. Pure capacity — `max_inflight` is STILL 1, nothing overlaps yet. The plan named the y/uv images as the thing to double. Reading the backend found five more, and each is a correctness problem under overlap rather than a performance one: * `csc_set` — ONE descriptor set, rewritten every frame by `bind_rgb`. Updating a set still bound by a PENDING command buffer violates VUID-vkUpdateDescriptorSets-None-03047, and on most drivers that is a wrong picture rather than an error. * `y_img`/`uv_img` — the CSC of N+1 storage-writes exactly the images pyrowave is still sampling for N. The barrier comment ("the previous frame's encode already completed under our synchronous fence") was load-bearing and said so. * `cursor_img` + `cursor_stage` — the struct comment stated the assumption outright: *"Single (not ring) because PyroWave encodes one frame synchronously — no in-flight overlap to race."* * `cmd` + `fence` — you cannot record into a PENDING command buffer at all. * `cpu_img`/`cpu_stage` (software capture / tests) — the host writes staging while the previous frame's copy is still pending. All of it moves into a `Slot`, and the encoder now owns `SLOTS` of them. Two, because Granite caps the overlap at two for us: the pyrowave device defaults to `init_frame_contexts(2)` and `next_frame_context()` — called at the top of every `encode_gpu_synchronous` — waits the context it rotates into. A third slot would need a vendored `init_frame_contexts(3)` that is not exposed. `bitstream` and `import_cache` are deliberately NOT per-slot, and the `Slot` doc says why so a later sweep does not "fix" it: `bitstream` is only touched during packetize, i.e. only on the poll side one frame at a time, and `import_cache` retaining the VkImage/VkDeviceMemory per dmabuf inode is precisely what makes it safe for two slots to sample the same imported buffer. `cpu_expand` is shared for the same reason — it is copied into staging before `submit_frame` returns, so no GPU work ever reads it. Each frame carries its slot index in `InFlight` rather than recomputing it, so `wait_and_packetize` cannot wait the wrong fence — the failure that would look like corruption rather than an error. `reset()` now waits EVERY in-flight fence, not just one, which matters the moment depth rises. WHAT IT COSTS, measured from the driver's own memory requirements rather than estimated (.21, RTX 5070 Ti, and there is now an `#[ignore]`d test that prints it on any GPU): 1080p 4:2:0 3872 KiB per slot 7744 KiB for both 4K 4:2:0 12992 KiB per slot 25984 KiB for both 4K 4:4:4 24992 KiB per slot 49984 KiB for both So the extra slot costs ~3.8 MiB at 1080p and ~24 MiB at 4K 4:4:4 — an order of magnitude under the plan's ~25-35 MB / 100-150 MB estimate, because that estimate included pyrowave's internal wavelet and scratch buffers, which stage 5's second encoder handle will add and this stage does not. Affordable on an iGPU. The open line now logs `slots`, `slot_kib` and `slots_kib` so this is visible per session and not only in a test. VERIFIED ON GLASS (.21, GPU idle at 195 MHz of 3090 — slow-clock, the worst case on this card): all 6 `#[ignore]`d GPU tests pass, and all NINE decoded-plane hashes (`ref-dense-{y,cb,cr}`, `ref-chunked-*`, `ref-dense444-*`) are bit-identical to the pre-PW5 base. Decode identity is the meaningful gate here — the raw AU bytes are not reproducible run-to-run even from an unmodified binary, which stage 3's message documents. Gates green at CI parity.	2026-08-09 00:18:38 +02:00
enricobuehler	95962f55d0	refactor(pf-encode): PyroWave waited its fence inside submit — the one backend that did ... Wave-2 PW5 stage 3. Depth is STILL 1; this is the shape change alone. `encode_frame` recorded CSC+encode, queue-submitted, waited the fence and packetized, all inside `Encoder::submit`. Every other backend in this crate puts the wait on the POLL side. That difference is the whole reason the host loop's cadence folds around this encoder: with the wait inline, `submit` returns only after the GPU is done, so the arrival-anchored floor absorbs the encode only while it stays under 0.9x the frame interval. Split into `submit_frame` (ingest -> CSC -> pyrowave encode -> queue-submit -> return) and `wait_and_packetize` (fence wait -> packetize -> AU), with an `InFlight` deque between them capped by `max_inflight`, which is 1. **One is the only value the resources can support today** — `cmd`, `fence`, `csc_set` and the y/uv images are one each, so a second concurrent frame would record into a PENDING command buffer and storage-write images pyrowave is still sampling. `submit` therefore drains to `max_inflight - 1` before recording, which states that invariant in one place instead of leaving it implicit in "the encode is synchronous". The subtle part is the command-buffer state machine, and it is unchanged: the record-and-submit closure still resets `cmd` on every PRE-submit failure (RECORDING/INVALID/EXECUTABLE, never PENDING), and the fence wait still does NOT reset on failure, because a timeout leaves the buffer PENDING where a reset violates VUID-vkResetCommandBuffer-commandBuffer-00045. What changed is that a failed wait now also leaves the entry IN FLIGHT — which is precisely what tells `reset()` there is live GPU work to re-wait before the pyrowave encoder object may be destroyed. `gpu_pending` is gone; `!inflight.is_empty()` is the same fact, and cannot drift from it. The split opened two windows that did not exist when everything ran inline, both closed here: `reconfigure_bitrate` and `set_wire_chunking` can now land BETWEEN a submit and its poll, so the packetize boundary and the bitstream cap are snapshotted into `InFlight` at submit time. Reading the live fields would have let a mid-flight bitrate drop turn a perfectly good frame into "unexpected packet count", and a mid-flight chunking change into an AU with the wrong `chunk_aligned` flag. `flush()` is no longer a no-op — it drains the in-flight frame, so the trait's poll-until-None contract still returns every AU (the `spike` subcommand and the hardware smoke tests are the real users). The perf instrument still measures submit->AU, stamped at submit and taken when the AU becomes readable, so `92326312`'s numbers stay directly comparable; the log line now carries `depth` and says plainly that above depth 1 the number legitimately grows by about one loop period. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090 — so these are slow-clock runs, which is the worst case on this card, not the best): all 6 `#[ignore]`d GPU tests pass — the 4:2:0, 4:4:4 and 24-bpp PSNR smokes, the mode-mismatch refusal, the fd-leak check and the golden dump. Byte-identity, honestly: the AU bytes are NOT reproducible, and were not before this commit either. Three runs of the SAME unmodified binary produced three different `au-dense.bin` hashes (ab7ecaf6 / 8735700e / 933b3d40) — the vendored 4:2:0 encoder emits run-varying bytes that the decoder ignores. So the meaningful gate is DECODE identity, and that holds exactly: every decoded plane (`ref-dense-{y,cb,cr}`, `ref-chunked-{y,cb,cr}`, `ref-dense444-{y,cb,cr}`) is bit-identical between the pre-split base and this commit, across four runs. 4:4:4 AUs are additionally bit-stable and match the checked-in Apple fixture exactly. Gates green at CI parity.	2026-08-09 00:11:22 +02:00
enricobuehler	20f4d23f2d	test(pw6): the streamed-AU trap is real — and at 2 % loss it costs exactly nothing ... PW6 shipped behind a knob because one pre-registered risk was unmeasured: a streamed frame whose FINAL block is lost has no totals, so where the whole-AU path hands the consumer a usable blurred partial, a streamed frame may deliver nothing. PyroWave clients opt into partial delivery unconditionally, so this would have been a live behaviour change for every one of them. Measured now, three ways, instead of reasoned about. `tools/loss-harness` gains a partial-delivery leg: FEC pinned OFF, chunk-aligned AUs, deliver_partial ON, realistic 1408/200 geometry, and AU sizes swept across the whole 1..=200-shard range of FINAL-block sizes — because the final block's size is what bounds the exposure. Loss is injected per packet from a seeded xorshift rather than through `loopback_drop_period`, whose deterministic 1-in-N would systematically always-or-never hit the final block, which is the entire question. `tc netem` on `lo` was deliberately not used: the in-process model gives exact per-frame attribution, needs no sudo, cannot disturb a box running a live desktop session, and — decisively — can drop precisely the final block. Leg 1, deterministic (drop exactly the last block, 200 frames): whole-AU delivers 200 partials and 0 losses; streamed delivers 0 partials and 200 total losses. The trap is real and, when it fires, total. Leg 2, random loss, 20 000 frames per cell, same seed and sizes for both shapes. At 2 % the two are indistinguishable — 20000/20000 partials and ZERO vanished frames on both, matching the analytic bound E[loss^k] over final-block sizes k (~1e-4). The gap only appears at 30 % (99.94 % vs 100 % rescue) and 50 % (99.79 %). `complete` is 0 throughout by construction: with FEC off and ~500 packets per AU, essentially every frame is damaged — which is the regime the partial path exists for. The spike gains `--wire-chunk` and a streamed loopback path, so the wire shape is reachable end to end outside a real client: `poll_chunk` drains the AU, `begin_streamed_frame_at`/`seal_streamed_chunk`/`seal_streamed_finish` seal each piece, and the client byte-compares the reassembly. On 120 real PyroWave AUs the streamed legs (56.5 and 2.0 chunks/AU) and the whole-AU control emit a byte-identical 47 373 568-byte stream with 0 mismatches — the cut changes the wire shape and not one byte of content, and with the knob unset it does not engage at all. A new `#[ignore]`d GPU test closes the picture question on real hardware with a BUSY card (gradients + checker + noise), never a flat fill: chunks are whole windows, exactly one `first` and one `last`, the AU decodes through the client's own window walk, and luma PSNR lands at 40.2 dB. Unset the knob and the test refuses to run, which is the default-off claim verified rather than asserted. Verdict recorded in the plan: KEEP IT OFF. The 2 % tie is an argument about typical loss, but the failure is not graceful when it fires and the measured win is host send-side pipelining that nobody has yet put a millisecond number on.	2026-08-08 21:26:25 +02:00
enricobuehler	49f5c815ea	feat(pf-encode): PyroWave can stream its AU to the wire — and newest-wins was never in the way ... PW6 was gated on one question: what happens to the client's newest-wins draining when a PyroWave AU arrives in pieces, given that `Session::set_deliver_frame_parts` refuses to combine with an all-intra stream. The answer is that the doc and the plan conflated two different axes, and the question never applied to this package. Host STREAMED_AU chunks change only the WIRE shape. The reassembler completes such a frame exactly like a whole one (`block_count != 0 && blocks_ok == block_count`) and hands up ONE Frame, so the frame channel still sees one entry per AU and the drain is untouched. What newest-wins genuinely cannot survive is the client's SEPARATE prefix delivery, and the mechanism is sharper than "assumes whole AUs" said: `FrameChannel::pop` counts QUEUE ENTRIES and takes one entry to be one AU. With parts on, one AU pushes several, so `len > 1` stops meaning "the consumer is behind" — the drain fires mid-AU, returns a SUFFIX and clears that same AU's prefixes. For PyroWave that is fatal rather than lossy: the sequence header lives in window 0 of every AU (`au_dims` reads it there), so every frame would arrive headerless, and `FramePart`'s own orphan contract would have a correct consumer abandon essentially all of them. Written into `pop`, `set_deliver_frame_parts` and the handshake, together with what a fix would take (skip whole SUPERSEDED AUs, never split one). That answer shrinks what this package may claim, so the code says so plainly. `encode_frame` is synchronous: the whole AU exists before the first chunk can be polled, so `poll_chunk` is not "emit as produced" and there is no encode/send overlap here (PW6 ⟂ PW5, confirmed). And with the client still receiving one whole Frame there is no decode-while-arriving either — the "~7 ms, decouple e2e latency from AU size" framing needs client work this commit does not do. What IS left is real and host-side: the whole-AU path FEC-protects, packetizes and seals the entire ~830 KB AU before its first datagram may leave the socket, while the streamed path seals and paces each FEC block as it completes. All of the cutting lives in the shared `pyrowave_wire` helper, which compiles and unit-tests on every platform, so both backends' `poll_chunk` / `supports_chunked_poll` are thin delegations — the Windows backend cannot be compiled from a Linux box, and logic written into it directly would ship unverified. Chunks are whole numbers of framing windows because `build_au` gives each window exactly ONE kind; that also makes them shard-aligned for free, which is what the sealer's sentinel bases require. Dense mode never streams (no window framing to cut on). `poll()` now errors while a chunk cursor is live — the trait's one-drain-method-per-AU contract, where double-emitting would put the same bytes on the wire twice under one frame index — and `reset()` drops the cursor so a rebuild cannot splice a dead AU's tail onto a fresh one. No new Encoder trait method, so neither the TrackedEncoder forwarding trap nor the EncoderCaps default trap is in play. Shipped OFF: `PUNKTFUNK_PYROWAVE_STREAMED_AU=1` arms it, `PUNKTFUNK_PYROWAVE_CHUNK_KIB` tunes the 256 KiB target. The pre-registered partial-delivery trap is real and now has a named cost — an unpinned streamed frame (final block lost) is excluded from partial delivery, where the whole-AU path still hands the consumer a usable blur, and PyroWave clients opt into partials unconditionally. The netem loss-harness leg is the prerequisite for default-on and has not been run.	2026-08-08 19:23:05 +02:00
enricobuehler	9232631299	feat(pf-encode): PyroWave had no encode split — so the one cost this program protects was unmeasurable ... Wave-2 PW1's exit criterion, and the instrument it needed. VAAPI and direct NVENC both log a PUNKTFUNK_PERF submit split. PyroWave did not — which meant the single encoder the GPU-priority work exists to defend was the one you could not put a number on. Adds per-frame timing of the synchronous encode (whole `submit`: CSC + encode + fence wait + packetize, which for this backend IS the encode), summarised every 2 s as mean/p50/p99/max. p99 rather than mean-only on purpose. The failure patch 0005 describes is a TAIL event — frames going ~2 ms to 15-18 ms at 95 % game load while the mean barely moves — so a mean-only readout would report "fine" straight through the thing being measured. WHAT IT MEASURED — .21, RTX 5070 Ti (610.57.04), GRID 2 benchmark loop saturating the GPU at 54-87 %, PyroWave 1080p, same binary both arms (only CAP_SYS_NICE differs), 30-frame windows with the warm-up window dropped: arm p50 p99 worst frame default priority (refused) ~2.6 ms ~6.4 ms 9.5 ms REALTIME granted ~3.2 ms ~4.4 ms 5.4 ms REALTIME granted (repeat) ~3.35 ms ~4.8 ms 5.1 ms p99 down ~30 %, worst frame roughly halved, for ~0.6 ms on the median. For a streaming encoder that is the right side of the trade — the tail is what becomes a visible hitch. This CONTRADICTS the patch's only prior datum (RTX 4090 / Windows / WDDM: "did not reduce the spikes"), so patch 0005's header now records the Linux/NVIDIA result beside it, with an explicit "do NOT delete this patch on the strength of the WDDM result — the two stacks disagree". Header prose only; the diff hunks stay byte-identical and `git diff crates/pyrowave-sys/vendor/` is untouched by this commit. Caveats recorded rather than buried: the arms were not interleaved and the game load drifted between them, capture was frame-starved (~2.5 fps) so this is encode latency under contention and not a full-rate stream, and it is two granted runs against one refused run. The direction held across all 25 windows. Also worth knowing for anyone repeating this: `encode_fps` is a VACUOUS metric on this rig. A headless gamescope with no real content emits ~12 fps, so both arms simply report the capture rate. Measure latency, not throughput. Gates green at CI parity.	2026-08-08 18:40:52 +02:00
enricobuehler	2bf571a5ad	feat(pf-encode): PyroWave's Linux encode device never asked for the priority its own patch requests ... Wave-2 PW1, first half = Wave-1 WP14 step 4, executed as specced. PyroWave encodes on the same GPU shader cores a game saturates, and that is measured to hurt: patch 0005's header records `encode_gpu_synchronous` going from ~2 ms to 15-18 ms at 95 % game load, with the stream frame rate collapsing. NVENC is immune because it has its own ASIC. The lever for a compute workload is an elevated global-priority QUEUE — a process-priority raise only reorders submission, not hardware preemption. The vendored patch requests exactly that. It is gated `if (!inherit_info)`, and only Windows leaves `inherit_info` null (`pyrowave_create_device_by_compat`, where Granite builds the device itself). Linux passes its own create-infos into `pyrowave_device_create_info`, Granite's `get_existing_create_info()` hands them back, `create_device` takes the inherit branch — and the whole block is skipped. On Linux the knob has never done anything at all. Meanwhile pf-zerocopy's VkBridge has shipped the identical ladder on Linux for some time and calls it "the actual NVIDIA compute-preemption lever"; the encoder that needs it most did not have it. This wires it natively in `open_inner`'s `DeviceHold`: - The extension probe reuses the `dev_ext_props` already fetched for queue_family_foreign, and takes KHR or the EXT alias — the same spelling pf-zerocopy probes, so the two cannot disagree. - `queue_priority_candidates` is a pure fn with the grammar copied from the C patch: unset → realtime, ASCII-lowercased, `off` alone disables, `high` asks for HIGH only, junk falls back to the ladder rather than to off. One env var must not mean two things on two platforms — that is the documentation trap this package exists to close — so the grammar is unit-tested against the patch's, including where they are both deliberately un-clever (neither trims). - The create ladder is REALTIME → HIGH → no-priority, stepping only on a refusal. A refused class can never fail the open, which matters more here than on Windows: this path is reached only by a NEGOTIATED PyroWave session, so a hard error is a dead stream, not a fallback to another encoder. The subtle part is the write-back. `pyrowave_create_device` RETAINS `device_create_info` for the device's lifetime and Granite reads the chain back. If the ladder ends on the no-priority attempt while `_queue_ci[0].p_next` still points at the global-priority struct, Granite is handed a chain the device was not created with. The `None` arm therefore nulls `p_next` before the final create, and the field's doc says why. The enabled extension deliberately STAYS in the list: it really is enabled on the device, it just carries no request. One deviation from the plan, stated because it is a deviation: the ladder also steps down on `ERROR_INITIALIZATION_FAILED`, not only `ERROR_NOT_PERMITTED_KHR`. The plan and the C patch handle only the latter; pf-zerocopy's shipped ladder accepts both. Given a hard error here kills a negotiated session, treating one extra driver-specific refusal as a downgrade is the cheap side of that asymmetry. Also corrects the two vendored notes, which claimed a Linux behaviour the gate made impossible, and records that patch 0005's negative RTX-4090 result is Windows/WDDM and does not transfer to a different driver stack. Patch hunks are byte-identical (header prose only) and `git diff crates/pyrowave-sys/vendor/` is PUNKTFUNK-VENDOR.txt alone. `PYROWAVE_QUEUE_PRIORITY` is now reachable on Linux, so it is documented in the same PR. MEASURED ON GLASS, and it changes what this package is worth on its own — .21, RTX 5070 Ti, NVIDIA 610.43.02, same binary in both arms: as packaged (no capability) every class refused, REALTIME *and* HIGH -> default priority same binary, cap_sys_nice+ep granted REALTIME on the FIRST attempt, no downgrade So the lever is INERT on an unprivileged host, and that is not the RADV-specific downgrade the plan predicted — on NVIDIA it is a downgrade to nothing at all. The ladder itself is proven good across all three legs (unset / high / off): a refused class never fails the open, and `off` enables no extension and logs nothing. It simply has nothing to grant yet. The privilege needed is CAP_SYS_NICE on the host binary, which is NOT what Wave-1 WP3 ships (RLIMIT_NICE, PAM limits, CPUWeight — all different things). That grant is a security-posture change on a network-facing daemon, so it is deliberately NOT in this commit; the warn line now names the capability so an operator is not left guessing, and the docs row says the setting has no effect on most hosts today rather than implying it works. The loaded-GPU encode_us p99 A/B is therefore not run: it needs a GPU-saturating game (hence a desktop session the box does not currently have) and it is pointless before the capability lands, since the unprivileged arm has no priority to measure. NO unit test is possible for the device-create ladder itself — it needs a real Vulkan device. Its coverage is the clippy pass, the grammar tests, and the on-glass log line. Stated here rather than left for a reviewer to wonder about.	2026-08-08 14:37:41 +02:00
enricobuehler	6de325a6b6	fix(ci): the unsafe lint said warn while CI enforced it as deny, and main went red ... `unsafe_op_in_unsafe_fn = "warn"` was adopted workspace-wide in 39513528 on the assumption that `warn` is a soft setting you can clear at leisure. It is not: ci.yml runs `cargo clippy … -D warnings`, which promotes it to a hard error, so main has failed on EVERY commit since — Linux `rust` and `rust-arm64` both dying on `pf-client-core` with 70 E0133 errors, and windows-host.yml alongside them. A lint level that understates its own severity is worse than a strict one, so this states what CI already does — `deny` — and writes the exemptions down instead. Fourteen GPU/FFI backend files take `#![allow(unsafe_op_in_unsafe_fn)]`, each with its reason and the workspace Cargo.toml carrying the argument in full. They are not "not done yet": measured across them, 64% of the sites are a single third-party FFI call (ash, pyrowave-sys, libav, the NVENC/AMF entry tables), and of the 44 `unsafe fn`s only 4 have a body containing no unsafe operation at all. Since pf-encode also denies `undocumented_unsafe_blocks`, narrowing them means a hand-written SAFETY comment per line that could only restate the signature — the exact noise that made `unsafe` stop meaning anything here before. Everything else stays at zero and enforced, and each allow is removable on its own terms. Two smaller things this had to clear, both invisible to the job that would have caught them: - `service.rs`: `undocumented_unsafe_blocks` wants the proof on EACH block, and a comment covering a group of consecutive `unsafe` statements only credits the first — so the two `OwnedHandle` wraps became their own statements. Windows-gated, so only the .47 gate sees it. 37a42078 fixed the same class of failure in pf-frame/dxgi.rs concurrently; that fix is taken as-is here. - `clients/linux/ui_settings.rs`: `show`'s deletion left its doc comment stranded on `show_scoped`, which silently merged two unrelated doc blocks onto one fn. Removed. Verified by running the real CI commands, not proxies: on .21 fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` + build + test, all rc=0; on the Intel box .47 all four windows-host.yml clippy invocations, all rc=0. The arm64 job lints pf-client-core and punktfunk-client-linux, both covered here.	2026-07-28 22:32:30 +02:00
enricobuehlerandClaude Fable 5	6d1baa0add	fix(pf-encode/pyrowave): the bitrate pin holds on the WIRE, not the raw bitstream ... A datagram-aligned PyroWave session inflates the codec bitstream ×1.2–1.3 on its way to the wire — greedy packing of few-hundred-byte atomic block packets into 1408 B windows zero-pads most window tails, plus the 4-byte prefixes and FRAG chains. The 2026-07 field report's 1440p60 10-bit "Automatic" pin of 407 Mb/s put a measured 550 Mb/s on a 1 GbE link; nothing enforced the pin past the rate controller. New shared WireBudget (pyrowave_wire.rs, both backends): tracks the real per-frame AU/bitstream ratio as a ×1024 fixed-point EMA (prior ×1.25, weight 1/8, clamped ×1.0–×2.0) and deflates the budget handed to pyrowave's rate control by it, so the windowed AU lands on the configured rate. Sealed-datagram framing (+4.5%) and FEC parity stay uncompensated — H.26x sessions carry those on top of the configured bitrate too, and the pin must mean the same thing for every codec. Dense (non-chunked) sessions are untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Opus 5	bf9fb3fb22	fix(pf-encode): enable VK_EXT_queue_family_foreign for the dmabuf acquires (Phase 8) ... Both Linux Vulkan encode backends named QUEUE_FAMILY_FOREIGN_EXT as the acquire barriers' src family without ever enabling the extension — spec-invalid on every device, tolerated by RADV. The audit filed vulkan_video's three sites; pyrowave's fresh-import acquire had the identical defect on its own device (critic catch). Enable when advertised (a fresh open-time enumerate — the rgb probe's is a probe-local and skipped entirely on native-NV12, so there was nothing to reuse; pf-presenter/dmabuf.rs is the in-repo precedent that already enables this extension). Not advertised → the core-1.1 QUEUE_FAMILY_EXTERNAL conservative substitute, chosen once at open and warn-logged (no fleet hardware takes that arm; such devices were never valid targets before). All four sites are acquire-only (src=FOREIGN, EXCLUSIVE images, oldLayout=UNDEFINED) — the swap is index-only. On-glass: 780M under validation layers — vulkan smokes + pyrowave smokes green, FOREIGN advertised and enabled, no fallback engaged. Shared ext_advertised helper in vk_util (cfg = the union of both consumers) with a unit test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:08:44 +02:00
enricobuehlerandClaude Fable 5	e3354b6d5d	fix(encode/vulkan): guard the CSC source dimensions, and bound reset()'s wait ... The CSC path was the only backend arm that took frame.width/height on trust: the shader samples with clamped 1:1 texelFetch, so a mismatched frame silently streamed a cropped/edge-padded picture where every sibling errors into the encoder-rebuild path. The import cache now also carries the extent it imported at (a (st_dev, st_ino) hit alone doesn't prove the allocation still matches) and is dropped on reset(). reset() opened with an untimed device_wait_idle on the one thread whose every other wait is capped at ENCODE_FENCE_TIMEOUT_NS for exactly this reason — reset() runs BECAUSE the GPU looks wedged. Both vulkan-video and pyrowave now bound the wait and report "no in-place rebuild" on timeout instead of parking recovery on the suspect device; Drop keeps the unbounded wait (teardown must stay memory-safe against a wedged device). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:10 +02:00
enricobuehlerandClaude Fable 5	ffc7aec91a	feat(encode/pyrowave): log which GPU pyrowave picked — the selection stays put, by decision ... WP4.5's device-selection half, closed as the observability intermediate after TWO selection designs died in adversarial review: - Attempt #1 (d26bcf05, withdrawn): match pf_gpu::selected_gpu(). Its Linux auto arm answers "the NVIDIA GPU" whenever /dev/nvidiactl exists, moving the encoder off the iGPU that can import the compositor's dmabufs on an Intel-compositor + NVIDIA-present laptop — import failures feed the process-wide raw-dmabuf latch, which never un-latches. - Attempt #2 (this session, withdrawn before commit): anchor on the PUNKTFUNK_RENDER_NODE-else-renderD128 node via VK_EXT_physical_device_drm. Render minors are driver-BIND-ORDER artifacts, not display topology: on the common AMD-iGPU + NVIDIA-display desktop, in-tree amdgpu binds before out-of-tree nvidia, so the anchor deterministically picks the idle iGPU while the compositor allocates on NVIDIA — the same latch, opposite polarity, behind a success-looking log. The correct oracle is evidence of which device ALLOCATED the capture buffers — producer identity from the capture negotiation, threaded per session into this open. Until that plumbing exists, selection stays first-usable, both call sites still share one selector (pure over the device list, so capture_modifiers and open_inner cannot diverge — including across an in-place resize's re-open, which does not renegotiate capture), and the open logs ONE greppable line: picked vendor/device, the anchor node and its owner (DRM render major/minor, VK_EXT_pci_bus_info fallback), and the console's selected GPU. A wrong-device session on a multi-GPU host used to be completely invisible; a field report can now show it. No WARN arm on purpose: the wrong-pick direction inverts between the laptop and desktop topologies, so a mismatch is not evidence of a wrong pick, and a warning that fires forever on healthy hosts teaches people to ignore warnings. Decision recorded against the audit's framing: manual console GPU selection stays unhonored by pyrowave on Linux (the Windows twin honors it) — honoring console-mutable state without per-session threading is what made attempt #1 unsafe. Verified on the 780M: the line resolves all three identities (1002:15bf x3, DRM-props match live); full pyrowave on-glass suite green; selection behaviour byte-for-byte unchanged. WP4.5 (device half). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 19:22:28 +02:00
enricobuehlerandClaude Opus 5	fdded5b8c3	fix(encode/pyrowave): refuse a frame that isn't the session's mode ... PyroWave never checked frame dimensions against the session, and it applies no alignment — `width`/`height` are the negotiated mode verbatim — so a mismatched frame was encoded edge-smeared or cropped, silently, forever. Every other Linux backend already refuses exactly this, with this shape, in `submit`: libav-NVENC (`linux/mod.rs`), VAAPI (`vaapi.rs`) and openh264 (`sw.rs`) all carry the same `ensure!`. PyroWave was the only one that didn't. That is the justification; an earlier draft cited `vulkan_video.rs` instead, which is the weaker precedent — it bails in its Dmabuf arms only, and its CSC path and CPU arm have no dimension guard at all. Mostly this is a wrong-picture bug and not a memory-safety one: `rgb2yuv.comp` clamps every fetch with `min(p, textureSize - 1)` and the CPU arm uploads `min(len, need)` into a session-sized image. But it also closes a narrow real hazard that was not in the filing: `import_cached` keys on `(st_dev, st_ino)` and returns the cached `VkImage` on a hit WITHOUT rechecking the extent, and unlike the capture side it is never cleared on a renegotiation — so a dmabuf inode recycled across a shrinking renegotiation would hand the encoder an image sized for the old, larger allocation. This check closes that route. ⚠ Recorded at the code because it changes the failure mode, not just the detection: a mismatch is NOT always transient. A compositor-initiated PipeWire renegotiation updates the capturer's size in place and signals nothing the encode loop reads, so it can be a permanent new steady state — and `reset()` reopens at the same dimensions by construction, so the host's five-reset budget cannot recover (~3.1 s of frozen stream, then the session ends) where before it would have streamed on with a wrong picture. For a real mode change that trade is clearly right; for a 16-row KWin mismatch it is not, and the proper fix is for the host to classify this error as a PIPELINE rebuild rather than an encoder reset. Filed, not done here. The device-selection half of WP4.5 was written, reviewed and WITHDRAWN — see the handoff doc. Matching the selected render GPU regresses the hybrid Intel-compositor + NVIDIA-present topology this project has a live field report for, because `selected_gpu()` answers NVIDIA whenever `/dev/nvidiactl` exists regardless of where capture actually runs. WP4.5 (dimension half). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:56:38 +02:00
enricobuehlerandClaude Fable 5	47a23bec12	fix(encode/vulkan): unwind every open/import leak, and serve 24-bpp CPU instead of dying on it ... Phase 5's Linux half (audit WP5.1 + WP5.4), each item shaped by the review that rejected the obvious fix: Dmabuf import unwind (vk_util): every failure after create_image leaked the VkImage, and the dup'd dmabuf fd leaked as a raw i32. The sharp edge is that a SUCCESSFUL vkAllocateMemory transfers fd ownership to Vulkan (vkFreeMemory closes it), so the naive close-on-error is a double close that clobbers whatever unrelated descriptor recycled the number. The dup now lives in an OwnedFd released exactly in the allocate-success arm; every other path drops it once, and bind/view failures free image+memory. PyroWave open unwind: open_inner had ~20 fallible steps that each leaked everything before them (instance, device, pyrowave objects, the whole CSC pipeline). Rather than a parallel teardown guard — whose reviewed hazards were a null-unsafe pyrowave_encoder_destroy and a drifting duplicate of Drop — Self is now constructed right after create_device with every later resource null, and the existing Drop (wait-idle first, pw_enc null-guarded, delete-nullptr and VK_NULL_HANDLE destroys are no-ops) is the single unwind path for error and normal teardown alike. The ensure_cpu_rgb staging twins (create/allocate/bind, both backends) and the RGB-direct make_view pair get the same discipline via a shared make_host_buffer. Observed on hardware: 32 forced import failures, zero fd drift (the new import_failure_leaks_no_fds smoke on RADV). 24-bpp CPU service (WP5.4): pixel_to_vk had no mapping for the packed Rgb/Bgr the PipeWire portal negotiates, so a session committed to a path the backend could not serve and died at its first frame. The filed open-gate was rejected as a half-mirror — the dmabuf axis is keyed by fourcc at submit, unknowable at open — so instead the CPU axis is SERVED: a 3-to-4 expand at the staging upload (normalize_cpu_rgb, the CPU twin of WP1.4's swscale expand), order-preserving for the CSC samplers and BGRA-forced for the RGB-direct encode source, whose session pictureFormat is B8G8R8A8 — the on-glass run caught R-first sources violating VUID-vkCmdEncodeVideoKHR-pEncodeInfo-08207, a mismatch that predates this change for plain Rgbx CPU sources. The dmabuf axis feeds pf-zerocopy's raw-dmabuf degrade latch (3efbe416) from both Vulkan import caches — deterministic refusals flip capture to CPU delivery, which now serves every format capture produces; transient OOM and native-NV12 sessions are excluded. RECORDING-state hygiene: the fallible recording prefix (cursor prep, import, staging) now resets the command buffer on error instead of leaving it RECORDING for the next begin to trip VUID-vkBeginCommandBuffer-commandBuffer-00049; PyroWave's submit-level blanket reset is replaced by the same scoped shape, closing its fence-timeout hole where a reset hit a PENDING buffer (VUID-vkResetCommandBuffer-commandBuffer-00045). Verified: docker linux/amd64 4-leg gate green; RADV 780M on-glass under the validation layers at 1920x1080 — all 10 smokes pass (including the new 24-bpp CSC + RGB-direct legs and both channel orders), decoded colour truth checked with ffmpeg, and the only remaining validation messages are the two documented VALVE-extension layer gaps plus a pre-existing pyrowave shader/feature mismatch now filed in the planning doc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:51:27 +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	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 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	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
enricobuehlerandClaude Fable 5	75474dcc90	fix(pyrowave): guard 4:4:4 modes that overflow the rate controller's block index ... The vendored rate controller packs its wavelet block index into 16 bits (RDOperation.block_offset_saving), so a mode whose 32x32-block count exceeds u16::MAX wraps inside the controller and corrupts the bitstream — ~8K-class 4:4:4 territory. Compute the exact count (`block_count_32x32`, the counting walk of upstream init_block_meta, pinned against the validated Apple WaveletLayout) and expose `pyrowave_mode_fits_rdo`; the negotiator downgrades such a session to 4:2:0 before the Welcome (the honest-downgrade channel), and both encoders refuse outright if one slips through rather than emit a wrapped stream. Vendor patches: 0002-rdo-saving-clamp (analyze_rate_control.comp clamps the saving accumulation to the target, same overrun class as 0001; slangmosh.hpp regenerated), 0003-devel-encode-16bit-read (devel tool y4m 16-bit plane reads; tool-only, kept so the vendored source stays honest). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 01:16:51 +02:00
enricobuehlerandClaude Opus 4.8	9fe9c451dc	perf(pyrowave): pool encoder scratch buffers + fix client parser O(n²) — lift the 2.5 Gbps wall ... Real-world PyroWave streaming maxed ~2.5 Gbps with sagging fps while raw transport does 4.8. Root-caused to serial per-frame paths at BOTH ends (the transport was never the limit); this fixes the two dominant ones. Host (vendored shim, patch 0004): pyrowave_encoder_encode_gpu_synchronous allocated four Vulkan buffers (meta + bitstream, Device + CachedHost) on EVERY frame. At 240 fps with MB-scale bitstreams that per-frame allocator churn stalled the encode itself. Pool them on the encoder and reuse across frames (recreate only on a size grow); the sizes are session-fixed, so it is pure reuse after frame 1. On an RTX 4090 the 5120x1440 submit+fence-wait drops ~15 ms -> ~1 ms, i.e. the host serial ceiling goes 64 -> 1025 fps (444+HDR 44 -> 614). Safe under the synchronous encode model; re-validated by pyrowave_win_smoke (Windows) and pyrowave_smoke/_444 (Linux). Applies to both host encoder paths (they share the shim). Client (Apple Metal decoder): WaveletBitstream.parse reserved the payload buffer per packet (reserveCapacity(count + words), an exact realloc each of ~3000 packets/frame => O(n²)) and copied word-by-word. Reserve once up front and memcpy each packet's coefficients in one shot (all Apple platforms are little-endian, so the wire's LE u32s land verbatim; memcpy is alignment-free). 5.44 ms -> 0.055 ms per 1.44 MB frame (25x); byte-identical (parser unit tests + golden-frame PSNR unchanged). Also: - native.rs: PUNKTFUNK_PYROWAVE_MAX_MBPS caps PyroWave's open-loop Automatic bitrate pin for hosts on a constrained link (unset => no cap; an explicit client rate bypasses it). The pin is all-intra + ABR-off, so at a high pixel rate it can outrun the fabric (4:4:4+HDR 5120x1440@240 pins ~5.3 Gbps, over a 5 GbE link) and the overshoot just becomes loss. - pf-encode caps(): report the real opened chroma instead of a hardcoded 4:2:0 default, so a genuine 4:4:4 session no longer trips the spurious "encoder chroma disagrees with the negotiated Welcome" warn. Also fix a latent Windows reset() that rebuilt at 4:2:0 for a 4:4:4 session. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 19:09:23 +02:00
enricobuehlerandClaude Fable 5	188edde2b3	feat(pyrowave): Windows host HDR + 4:4:4, Rust client HDR present ... Phase 3 of design/pyrowave-444-hdr.md. A PyroWave session now negotiates HDR (10-bit) and 4:4:4 on a Windows host exactly like HEVC/AV1, and the Linux client presents it through the real HDR10 path. Host (Windows): BgraToYuvPlanes becomes mode-aware — SDR/BGRA and HDR/scRGB variants at half- or full-res chroma. The HDR passes reuse HdrP010Converter's exact colour math (scRGB -> PQ BT.2020 limited studio codes, verified by hdr_p010_selftest) but write P010-style MSB-packed codes into two separate shareable R16_UNORM/R16G16_UNORM textures; chroma keeps the pyrowave family's centre-sited 2x2 box. idd_push pins the composition to the NEGOTIATED depth (SDR sessions force advanced color off as before; 10-bit sessions enable it and ride the FP16 ring), and the descriptor poller re-asserts that state instead of following display flips the fixed-format encoder can't. The encoder imports 8/16-bit planes per session and stamps the sequence header's BT.2020/PQ/matrix bits on HDR (stamp_color_bits, extending 574e3e4e's range stamp); supports_10bit/can_encode_10bit/can_encode_444 gates open (HDR Windows-only — Linux capture has no HDR source). Client: the plane ring becomes R16_UNORM for 10-bit sessions (with a STORAGE_IMAGE format probe), the planar CSC pass joins the HDR10 swapchain rebuild (set_hdr_mode previously destroyed it without rebuilding — latent), st.hdr follows frame.color.is_pq(), and the planar push constants carry depth-10 MSB-packed rows + the PQ tonemap mode, identical to the NV12 arm. Verified: .173 (RTX 4090) deploy-config clippy + fmt + wire tests + the extended pyrowave_win_smoke (10-case {SDR,HDR}x{420,444} matrix incl. R16 imports and header stamps); .21 (RTX 5070 Ti) clippy across 4 crates, host 186 tests, client/presenter/encode tests, both Linux GPU smokes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 13:21:06 +02:00
enricobuehlerandClaude Fable 5	4861824e7d	feat(pyrowave): Linux 4:4:4 encode — per-pixel CSC, full-res chroma, gate open ... Phase 2 of design/pyrowave-444-hdr.md. can_encode_444(PyroWave) now returns true on Linux, so a client that advertises VIDEO_CAP_444 (the 4:4:4 setting) and prefers PyroWave negotiates a full-chroma wavelet session end to end (the client decoder side landed in 5eb930e7). - rgb2yuv444.comp: the 4:4:4 twin of rgb2yuv.comp — one invocation per pixel, full-res interleaved RG8 CbCr, no box filter/siting, byte-identical BT.709 limited coefficients; compiled .spv committed (glslangValidator -V, matches the existing shader's toolchain). - Encoder: chroma-conditional pyrowave create (open + reset), full-res chroma plane + views, per-pixel dispatch, 4:2:0-only even-dims check. - Tests: decode oracle grows a 4:4:4 mode (YUV444P CPU readback); pyrowave_smoke_444 round-trips plane means AND drives the busy test card at the ~2.6 bpp operating point asserting in-budget + run-to-run deterministic AU sizes — the exact regime that silently corrupted before the vendored payload_data fix (patches/0001), so this doubles as its regression test. Verified on .21 (RTX 5070 Ti): clippy -D warnings, host tests, and both GPU smokes (pyrowave_smoke + pyrowave_smoke_444) green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 12:43:34 +02:00
enricobuehlerandClaude Fable 5	5eb930e71d	feat(pyrowave): negotiation plumbing for 4:4:4 + HDR — thread chroma/depth/ColorInfo end to end ... Phase 1 of design/pyrowave-444-hdr.md. No behavior change yet: the handshake's 4:4:4 gate now admits PyroWave (probe = can_encode_444(codec), capture gate inherently satisfied — the wavelet path always ingests an RGB source and does its own CSC), but can_encode_444 stays false for PyroWave until the per-OS full-res-chroma CSC variants land (Phase 2 Linux, Phase 3 Windows), so every session still resolves 4:2:0/8-bit. - Both host encoders take the negotiated ChromaFormat (bail on 444 for now); the PUNKTFUNK_ENCODER=pyrowave lab override pins 4:2:0. - Bitrate: the automatic ~1.6 bpp pin resolves AFTER depth+chroma and scales x1.625 for 4:4:4 / x1.15 for 10-bit (factors from the Phase-0 fixture matrix); the mid-stream mode-switch re-resolve threads the session's values. - Client: PyroWaveDecoder builds its plane ring (full-res chroma when 444) and creates the upstream decoder from the negotiated chroma, keeps chroma fixed across mid-stream resizes, drops the even-dims requirement for 444, and returns the negotiated Welcome ColorInfo as the frame colour contract instead of hardcoded BT.709 (the wavelet bitstream has no VUI). Verified on .21 (RTX 5070 Ti): clippy -D warnings (host+client+encode), host 186 tests, client + pf-encode tests, fmt, and the pyrowave_smoke GPU round-trip through the patched vendored lib (97cf15e3). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 12:37:12 +02:00
enricobuehlerandClaude Opus 4.8	574e3e4e3f	fix(pyrowave): signal ycbcr_range=LIMITED in the sequence header ... pyrowave's encoder fills the BitstreamSequenceHeader with `= {}` and its C API offers no way to set colour/range, so it signals ycbcr_range=0=FULL — but both host CSCs (rgb2yuv.comp on Linux, BgraToYuvPlanes on Windows) always emit BT.709 LIMITED Y'CbCr (black = Y'16). A client that honours the VUI (the Apple wavelet decoder reads bit 30 of word1) then skips the limited→full expansion and shows washed-out, raised blacks — reported on both Linux and Windows hosts. Patch the range bit HONEST (mark_limited_range in the shared pyrowave_wire, called by both encoders after packetize). Clients that hardcode limited (the Vulkan video_pyrowave path) are unaffected, and pyrowave's own decode ignores the flag (raw Y'CbCr reconstruction). No client rebuild needed. Unit-tested + asserted in pyrowave_win_smoke; the smoke decode still round-trips 100/180/60. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 11:39:44 +02:00
enricobuehlerandClaude Opus 4.8	ebd9967547	feat(pyrowave): Windows host encoder — separate-plane zero-copy D3D11→Vulkan ... Wire PyroWave into the Windows host (design/pyrowave-windows-host-zerocopy.md). Before this a macOS client + Windows host that both selected PyroWave silently ran HEVC: the host never advertised CODEC_PYROWAVE and open_video_backend bailed. Approach (zero-copy, no GPU→CPU→GPU): pyrowave owns its own Vulkan device (create_device_by_compat, by render-GPU vendor/device-id — NOT LUID, invalid in Session 0). The capturer runs a BGRA→YUV BT.709-limited CSC (matching rgb2yuv.comp) into TWO SEPARATE shareable plane textures — full-res R8 Y + half-res R8G8 CbCr — which the encoder imports into pyrowave's device. Separate single/two-component textures import reliably on NVIDIA at any size; a single planar NV12 import does NOT (the vendored interop test: "only very specific resource sizes" — confirmed on-glass: 1024² fine, 720p/1080p/1440p garbage). A shared D3D11 fence, signalled after the CSC, is imported as a Vulkan timeline semaphore so the wavelet read is ordered after it. - pf-encode: enc/windows/pyrowave.rs (Encoder impl, two-plane import + Linux-style plane views); host_wire_caps advertises CODEC_PYROWAVE on Windows when the backend isn't Software; open_video_backend routes a negotiated PyroWave session first; pyrowave-sys on the Windows target; interop confirmed at open → clean HEVC fallback. - pf-encode: shared, unit-tested enc/pyrowave_wire.rs (single source of truth for the client-facing AU framing); Linux encoder uses it too. - pf-capture: dxgi.rs BgraToYuvPlanes CSC; idd_push.rs pyrowave mode — forces the virtual display SDR (the VideoProcessor can't ingest the FP16 HDR ring), a two-plane shareable out-ring, a shared fence passed every frame (so a rebuilt encoder re-imports it). Threaded via OutputFormat::pyrowave. - pf-frame: D3d11Frame::pyro carries the CbCr plane + fence; OutputFormat::pyrowave. Verified on .173 (RTX 4090): full-host build + clippy -D warnings (nvenc,amf-qsv) + fmt --all --check; pyrowave_wire unit tests; pyrowave_win_smoke GPU test round-trips distinct Y/Cb/Cr (100/180/60) exactly at 1024²/720p/1080p/1440p; Stage-0 interop validated in the real Session-0 service context on-glass. Deployed to the box. Owed: final on-glass picture/latency confirmation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 11:39:44 +02:00
enricobuehlerandClaude Opus 4.8	9a36ea2132	refactor(host/W6.2): extract the video encode backends into the pf-encode crate ... encode.rs + encode/* (NVENC, VAAPI, native AMF, AMF/QSV ffmpeg, direct-SDK NVENC/CUDA, raw Vulkan-Video, PyroWave, openh264) move into crates/pf-encode behind one Encoder trait + open_video selector (plan §W6). The crate speaks the shared frame vocabulary (pf-frame: CapturedFrame/PixelFormat + the DXGI identity D3d11Frame/make_device) and pf-zerocopy (CUDA context/buffers), and NEVER pf-capture — the capture→encode edge is one-way (ZeroCopyPolicy, prior commit). Dep moves: the heavy encoder deps (ffmpeg-next, the NVENC SDK, openh264, pyrowave-sys) move from the host to pf-encode; the host's nvenc/amf-qsv/vulkan-encode/pyrowave features now FORWARD to pf-encode/*. The host keeps a mod-encode shim (pub use pf_encode) so every crate::encode::* path (negotiator + GameStream/native/mgmt planes) is unchanged. resolve_render_adapter_luid moves from the host's windows/win_adapter.rs into pf-gpu (both pf-encode and pf-capture need it as a peer of GPU selection); its 5 call sites (encode amf/nvenc, capture idd_push/synthetic_nv12, vdisplay manager) rewire to pf_gpu::resolve_render_adapter_luid and win_adapter.rs is deleted. pf-frame's make_device gains a # Safety section (public-unsafe-fn lint, latent since the pf-frame carve — a full-workspace -D warnings clippy catches it). Verified: Linux clippy -D warnings (pf-encode + host nvenc,vulkan-encode,pyrowave --all-targets) + 13/13 pf-encode + 299/299 host tests; Windows clippy -D warnings (pf-encode nvenc,amf-qsv --all-targets + host nvenc,amf-qsv --all-targets) Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 10:42:51 +02:00