Performance Research A04 Lazy GP EP Execution

Lazy GP/EP execution

A04 — Implementation and validation notes

Field	Value
Evidence state	Quiescence hypothesis; silence-only skip disproved by a model
Inspected source	322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment	Explicit disabled/reset-state equivalence, not silence detection
Scope	Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

The attractive idea needs a narrower condition. Zero mixbin input does not imply zero output or no side effects. A DSP can retain filter/reverb state, update counters, consume DMA, or run a program unrelated to immediate voice output. The included zero-input/stateful-output model demonstrates why silence alone cannot justify a skip.

The actual frame path sets a start-frame interrupt, clears halt_requested, resets the cycle count, and runs the enabled processor. EP already runs once per eight VP frames. Therefore a previous frame's halt flag is not, by itself, proof that subsequent frames are dispensable. Frame execution, start-frame side effect.

Merited formulation. Classify explicitly disabled/reset states and prove that the particular work being skipped has no required memory, register, interrupt, or future-state effect. For known idle DSP loops, an event-aware execution shortcut would need an exact state transition and bounded next wake event—not merely an audio-energy threshold.

Expected gain. Potentially large only in workloads with substantial provably redundant DSP work; potentially zero in active effects. Do not treat turning off the monitor/output device as authorization to skip emulated processors.

Acceptance. Compare future state and memory writes across silence, effect tails, frame interrupts, DMA arrival, reset release, and resume. A dead-simple output-only oracle is inadequate.

First patch boundary

Define the exact skipped operation and its allowed states. Do not omit mixbuffer writes, frame interrupts or DMA merely because a processor is silent.

frame event -> processor state/IRQ/memory effects -> output; skip only a proven side-effect-free transition

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'mcpx_apu_dsp_frame|dsp_start_frame|halt_requested' -- hw/xbox/mcpx/apu

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID	Setup / deliberate control	Required oracle
A04.01	Zero new input after nonzero filter/effect history.	Future output and state still advance; the shortcut is ineligible unless equivalence is proved.
A04.02	Silent input plus pending DMA, start-frame interrupt, reset release and processor resume.	The event is processed at the correct boundary; no wake condition is dropped.
A04.03	An explicitly disabled state with the proposed operation omitted; compare complete future state after re-enable.	Memory, registers, IRQs, counters and resumed output match—not only the silent frame.

Counters and rejection criteria

Collect: eligible_frames, skipped_transitions, dsp_cycles, register_writes, dma_events, apu_cpu_ns, output_mismatches. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: Any changed future state invalidates the skip condition. Turning off monitoring or output is not an emulated-device quiescence predicate.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.