fix(vdisplay/driver,pf-frame): no punktfunk process holds REALTIME GPU priority by default #173

Merged

enricobuehler merged 1 commits from worktree-rt-gpu-priority-defaults into main 2026-08-12 13:11:08 +00:00

Conversation 0 Commits 1 Files Changed 3

+164 -56

enricobuehler commented 2026-08-12 11:57:55 +00:00

Owner

Copy Link

Copy Source

Root-cause + coherent re-default of both REALTIME GPU-scheduling levers, convicted by the RX 9070 XT field A/B (2026-08-11/12 logs) of generating the metronomic capture-stall class the stall program has chased: compose-silence holes of 150–800 ms in which ETW shows no process presenting while the GPU stays responsive (fence probes 0–1 ms).

Field evidence (one lever changed per session):

• PFVD_NO_RT_GPU=1 (driver's IddCxSetRealtimeGPUPriority off) → the ~1.75 s metronome vanished; H265 3.9-min session dropped from ~0.35 stalls/s metronomic to 10 sparse aperiodic stalls, zero metronomic classifications.
• PUNKTFUNK_GPU_PRIORITY_CLASS=high on top (host auto-gate's HIGH→REALTIME promotion off) → the residual ~3.58 s class vanished too; AV1 3.4-min session clean at the same baseline.
• The metronome had persisted through topology: extend AND with the monitor physically unplugged (connected_inactive=none), so it was host-intrinsic — and a periodic-actor census of both processes found nothing punktfunk-side in the 1.69–2.29 s band. The period is emergent from the REALTIME-queue-vs-WDDM-scheduler interaction (it differs by which process holds REALTIME), not an amplified punktfunk cadence.

Changes:

• Driver (swap_chain_processor.rs): default is now NO priority raise — canonical-IDD parity (no shipping IDD, SudoVDA included, sets the DDI). Opt-in ladder via machine env PFVD_RT_GPU: thread = SetGPUThreadPriority(+7) (the graduated in-band middle, unmeasured — kept opt-in), anything else = the old REALTIME DDI. PFVD_NO_RT_GPU stays recognized and wins, so field boxes carrying it keep meaning OFF.
• Host (pf-frame/dxgi.rs): PUNKTFUNK_GPU_PRIORITY_CLASS default auto → high. auto (VRAM/HAGS-gated REALTIME upgrade) and realtime remain explicit opt-ins; unrecognized values land on high instead of silently opting into the gate. Gate machinery unchanged.
• Stall detector (pf-capture stall.rs): the no-OS-event METRONOMIC warning now self-reports both levers' env state (rt_gpu_driver/rt_gpu_host) and names clearing a REALTIME opt-in as the first cure — so the next field log self-diagnoses.

Validation (.173, native Windows): host workspace cargo check + clippy -D warnings + cargo test for pf-frame/pf-capture green (9/9 incl. the metronome suite); driver workspace cargo check/clippy -D warnings green under the canonical WDK env. Not validated: the full signed driver release build (CI's build-pf-vdisplay.ps1 leg), and no live A/B of the new defaults yet.

Open items:

1. NVIDIA field test of PFVD_RT_GPU / host auto — decides whether the hazard is AMD-scheduler-specific or universal.
2. The thread rung is unmeasured — worth one RX 9070 XT session.
3. If the 5K@240 encode-starvation case (T2.3's original ceiling-raiser) regresses at plain HIGH, the answer is a smarter gate (REALTIME only during encode bursts), not resident REALTIME.

Root-cause + coherent re-default of both REALTIME GPU-scheduling levers, convicted by the RX 9070 XT field A/B (2026-08-11/12 logs) of generating the metronomic capture-stall class the stall program has chased: compose-silence holes of 150–800 ms in which ETW shows **no process presenting while the GPU stays responsive** (fence probes 0–1 ms). **Field evidence (one lever changed per session):** - `PFVD_NO_RT_GPU=1` (driver's `IddCxSetRealtimeGPUPriority` off) → the ~1.75 s metronome vanished; H265 3.9-min session dropped from ~0.35 stalls/s metronomic to 10 sparse aperiodic stalls, zero metronomic classifications. - `PUNKTFUNK_GPU_PRIORITY_CLASS=high` on top (host auto-gate's HIGH→REALTIME promotion off) → the residual ~3.58 s class vanished too; AV1 3.4-min session clean at the same baseline. - The metronome had persisted through `topology: extend` AND with the monitor physically unplugged (`connected_inactive=none`), so it was host-intrinsic — and a periodic-actor census of both processes found nothing punktfunk-side in the 1.69–2.29 s band. The period is emergent from the REALTIME-queue-vs-WDDM-scheduler interaction (it differs by which process holds REALTIME), not an amplified punktfunk cadence. **Changes:** - **Driver** (`swap_chain_processor.rs`): default is now NO priority raise — canonical-IDD parity (no shipping IDD, SudoVDA included, sets the DDI). Opt-in ladder via machine env `PFVD_RT_GPU`: `thread` = `SetGPUThreadPriority(+7)` (the graduated in-band middle, unmeasured — kept opt-in), anything else = the old REALTIME DDI. `PFVD_NO_RT_GPU` stays recognized and wins, so field boxes carrying it keep meaning OFF. - **Host** (`pf-frame/dxgi.rs`): `PUNKTFUNK_GPU_PRIORITY_CLASS` default `auto` → `high`. `auto` (VRAM/HAGS-gated REALTIME upgrade) and `realtime` remain explicit opt-ins; unrecognized values land on `high` instead of silently opting into the gate. Gate machinery unchanged. - **Stall detector** (`pf-capture` `stall.rs`): the no-OS-event METRONOMIC warning now self-reports both levers' env state (`rt_gpu_driver`/`rt_gpu_host`) and names clearing a REALTIME opt-in as the first cure — so the next field log self-diagnoses. **Validation** (.173, native Windows): host workspace `cargo check` + `clippy -D warnings` + `cargo test` for pf-frame/pf-capture green (9/9 incl. the metronome suite); driver workspace `cargo check`/`clippy -D warnings` green under the canonical WDK env. Not validated: the full signed driver release build (CI's `build-pf-vdisplay.ps1` leg), and no live A/B of the new defaults yet. **Open items:** 1. NVIDIA field test of `PFVD_RT_GPU` / host `auto` — decides whether the hazard is AMD-scheduler-specific or universal. 2. The `thread` rung is unmeasured — worth one RX 9070 XT session. 3. If the 5K@240 encode-starvation case (T2.3's original ceiling-raiser) regresses at plain HIGH, the answer is a smarter gate (REALTIME only during encode bursts), not resident REALTIME.

enricobuehler added 1 commit 2026-08-12 11:57:57 +00:00

fix(vdisplay/driver,pf-frame): no punktfunk process holds REALTIME GPU priority by default ... 6a506a8fa9

The RX 9070 XT field A/B (2026-08-11/12 logs) convicted BOTH of our REALTIME
GPU-scheduling levers of generating the metronomic capture-stall class the
stall program has chased for weeks — compose-silence holes of 150-800 ms in
which ETW shows NO process presenting while the GPU stays responsive:

- the vdisplay driver's IddCxSetRealtimeGPUPriority raise beat at ~1.75-1.78 s
  (PFVD_NO_RT_GPU=1 alone removed that metronome: ~0.35 stalls/s metronomic ->
  10 sparse aperiodic over 3.9 min);
- the host auto-gate's HIGH->REALTIME upgrade (pf-frame dxgi.rs, T2.3) beat at
  ~3.58 s in the AV1 sessions where it promoted (vram_pct=1, 12:59:26); pinning
  PUNKTFUNK_GPU_PRIORITY_CLASS=high removed that residual too (13:45 session:
  zero metronomic, stall rate at the clean-run baseline).

Neither period matches any punktfunk clock: the full periodic-actor census
(driver: event-paced drain + 16 ms E_PENDING wait, 33 ms cursor poll, 3 s
watchdog reap; host: 250 ms descriptor poll, 5/50/100 ms probes + ~2 s scanline
retarget, 2 s VRAM gate, 2 s exclusive re-assert, 3.33 s pinger, 1 s stats,
~1 Hz phase-lock, fps/2 LTR marks) has nothing in the 1.69-2.29 s band, and
every host-side actor ran unchanged in the A/B that killed the fast metronome.
The periodicity is emergent from holding an unreachable-priority queue against
the WDDM scheduler on this AMD family (the period even differs by which of our
processes holds REALTIME); it is not a punktfunk cadence being amplified, so
there is nothing punktfunk-periodic to fix - the fix is to stop holding
REALTIME by default, which is also canonical parity (no shipping IDD raises
it, and HIGH was the class that delivered the original Sunshine-parity encode
win).

- Driver: PFVD_NO_RT_GPU (default-ON, opt-OUT) becomes the PFVD_RT_GPU ladder,
  default OFF on every vendor: unset = no raise (canonical IDD behavior);
  =thread = SetGPUThreadPriority(+7), a graduated in-band middle rung for field
  A/B (not default: unmeasured here, and the host measured the same call as "no
  help" for its own starvation case); anything else = the old REALTIME DDI.
  PFVD_NO_RT_GPU stays recognized and WINS over the opt-in, so the field boxes
  that carry it through the default-ON era keep meaning OFF. Both directions
  remain A/B-able without a rebuild (machine env + device restart). The CPU
  half of the original branch-2 hardening (MMCSS / TIME_CRITICAL) is untouched
  - it addressed the delivery holes that were actually observed.
- Host: PUNKTFUNK_GPU_PRIORITY_CLASS default auto -> high. `auto` (the gated
  REALTIME upgrade) stays available as an explicit opt-in, `realtime` still
  pins; unrecognized values now land on the HIGH default instead of silently
  opting into the gate - a typo must not buy the hazard. The VRAM/HAGS gate
  machinery is unchanged for `auto`; it guards the NVENC-hang hazard but cannot
  see this one.
- stall.rs: the no-OS-event METRONOMIC warning now carries rt_gpu_driver /
  rt_gpu_host fields (the machine-env state of both levers) and names clearing
  them as the FIRST cure, ahead of the display-hardware suspects - a field log
  self-answers the triage question this program just spent a week on.

No console policy axis for the driver knob: the lever is default-safe now, the
driver reads config at WUDFHost scope where machine env already matches the
device-restart lifecycle, and a policy axis would need pf-driver-proto churn
(or a device-key registry write) for an experimental lever that only exists to
be A/B-ed. If the `thread` rung ever proves out as a default-worthy raise,
that is the moment to revisit.

enricobuehler referenced this pull request 2026-08-12 13:10:20 +00:00

feat(display): edid_lock policy axis — pin AMD connector EDID emulation while streaming #176

enricobuehler merged commit c2c71f0ac5 into main 2026-08-12 13:11:08 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#173