APU & GPU Compute Micro-Codes

1. Overview

Yes: APU/DSP calculations can be executed by GPU compute shaders through PHLEGM’s graphics backends. This would extend the proposed graphics-backend micro-code architecture to a third execution target: GPU Compute. The approach is technically feasible, but not every APU operation would benefit.

For the SNES, the best initial candidates are selected S-DSP signal-processing tasks; the sequential S-SMP / SPC700 processor should initially continue executing on the host CPU using the existing data-driven micro-code runtime.

This is an architecture proposal, not a statement that GPU APU micro-codes or a cross-backend compute IR already exist in PHLEGM v9.

2. Why graphics backends can handle audio

General-purpose GPU compute dispatches parallel shader invocations over buffers of data. Audio algorithms often contain arithmetic that can be expressed as reusable operations: decoding, interpolation, mixing and filtering.

GPU compute can be excellent for large buffers, but the SNES audio workload is small. Kernel launches, state transfers, fences, and readback may cost more than the audio math itself. Availability does not guarantee a speedup.

3. Proposed PHLEGM execution architecture

compute.lib is a suggested abstraction for dispatching backend-neutral computation—not an existing required PHLEGM library. The compute IR expresses operations in hardware-independent terms; backends supply shader compilation, resource allocation, dispatch, and synchronization.

4. SNES S-SMP / S-DSP suitability

SNES audio combines the S-SMP (SPC700) control processor, the S-DSP audio processor, and CPU↔APU communication ports. These parts have very different parallelism and synchronization requirements.

The S-DSP’s nominal output stream is approximately 32 kHz. This is a relatively modest workload by modern host CPU standards, so the default should remain CPU execution until measurements show otherwise.

5. Candidate audio micro-code primitives

The names below are illustrative proposals for a generic audio/compute instruction vocabulary; they are not existing PHLEGM opcodes or finalized .phlegm syntax.

Each primitive needs well-defined operand widths, signedness, rounding, saturation, latency, buffer ownership, and state-update ordering. Accuracy must not depend on subtle differences between shader compilers.

6. Keep audio behavior data-driven

The emulated device definitions should determine what the APU does; generic execution engines determine how to execute it efficiently.

Illustrative definition-driven pipeline

// Conceptual program only — NOT valid .phlegm syntax
APU_AUDIO_BLOCK:
    for each emulated DSP sample time:
        AUDIO_ENVELOPE_UPDATE(voice_state)
        AUDIO_BRR_DECODE(sample_state)
        AUDIO_SAMPLE_INTERPOLATE(voice_sample)
        AUDIO_VOICE_MIX(voice_samples)
        AUDIO_FIR_FILTER(echo_history)
        AUDIO_ECHO_FEEDBACK(echo_state)
        AUDIO_SAMPLE_OUTPUT(pcm_buffer)

// Execution policy:
// CPU_reference by default; GPU_compute only if verified
// and profitable for a suitably sized workload.

A real implementation may need to fuse stages or execute some of them serially to preserve authentic DSP ordering. The pseudocode specifies the concept, not a claim that the steps are freely parallelizable.

7. Compilation and execution lifecycle

PHLEGM’s existing micro-code rule remains unchanged: compile the applicable machine-specific definitions at machine load, and recompile when a session restore requires it. Do not generate machine micro-codes during native build, distribution packaging, or bootstrap execution.

1. Load the machine. Resolve active chipset, support-chip and audio definitions.
2. Compile and validate. Build an architecture-neutral audio/compute IR from the active definitions.
3. Inspect capabilities. Determine whether the chosen graphics backend has suitable compute support and integer precision.
4. Select an execution target. Use the deterministic CPU path by default; optionally enable a verified GPU implementation.
5. Compile GPU programs once per active definition state. Prepare shaders, buffers and dispatch plans, not one shader per sample or frame.
6. Schedule blocks safely. Produce exactly the samples allowed by elapsed emulated DSP time; return ordered PCM buffers to the host audio output.
7. On machine change/restore. Invalidate old compiled machine-specific programs and reconstruct them from the currently active definitions.

8. Timing, buffering and synchronization

Audio is low-latency and strongly ordered. An efficient compute shader that finishes too late, uses stale port state, or changes sample ordering is an incorrect emulation result.

Because DSP operations maintain history across samples, naively processing an entire block in parallel can change results. Any parallel implementation must either respect dependency order or prove an equivalent transformation.

9. Backend and CPU fallback contract

Backends should expose shared feature/capability queries and return the same observable emulated audio behavior. No game should require a GPU, and the same APU definitions should run on different host graphics backends.

10. Correctness and performance validation

Begin with a deterministic CPU implementation. Then compare audio sample streams and internal DSP-state transitions against GPU execution using the same emulated register writes and sample-clock schedule.

Suggested diagnostics: emulated DSP sample counter, S-SMP instruction count, CPU↔APU port state, audio IR hash, selected execution target, per-block samples, dispatch duration, readback duration, underrun count, and CPU/GPU sample checksum.

11. Recommended implementation sequence

1. Complete functional SNES audio accuracy first. Validate S-SMP IPL/upload flow, CPU↔APU synchronization and S-DSP output using CPU execution.
2. Define reusable audio IR. Specify typed operations, integer widths, saturation, buffer access, state hazards and deterministic ordering.
3. Build the CPU reference executor. Ensure every proposed primitive produces a testable and correct result.
4. Prototype an optional compute interface. Let graphics backends advertise compute capabilities without embedding SNES-specific DSP code.
5. Offload one benchmarked kernel. Begin with a bounded, testable workload such as batched interpolation or mixing; do not migrate the whole APU blindly.
6. Prove backend parity. Add OpenGL, then D3D11 and Vulkan implementations as appropriate, with exactness tests and automatic fallback.
7. Expand selectively. Consider BRR decode and filtering only where real profiling shows a sustained improvement after transfer costs.
8. Reuse across systems. Apply generic audio operations to other emulated machines without adding machine-specific branches to native libraries.

12. Scope, cautions and conclusion

• Not a replacement for APU hardware emulation: GPU compute only accelerates selected calculations; S-SMP, S-DSP and port semantics still need correct definitions and timing.
• Not guaranteed faster: For eight SNES voices at ~32 kHz, a well-written CPU implementation may remain the best choice.
• Not tied to display refresh: Audio must run from the emulated audio clock, not the PPU’s frame presentation.
• Not hard-coded machine logic: Avoid SNES-specific branches inside compute.lib or backend libraries.
• Not proprietary firmware distribution: The design does not require shipping an S-SMP IPL ROM image; existing explicit firmware-source rules remain in force.
• Not currently implemented: Names, IR stages and APIs in this document are proposals requiring development and benchmarking.