Performance is not the biggest number shown on the screen. The goal is to maintain predictable pacing, stable audio, responsive input, and acceptable temperature in the actual device.
What we measure
- Actual FPS: core frame counter difference over a time window.
- Frametime: average time per frame. At 60 FPS, the reference is 16.67 ms; at 30 FPS, 33.33 ms.
- Pace: variation between frames, which can be noticeable even when the average looks good.
- Side delays: loading, cache, audio, storage, processor temperature and frequency.
RetroArch exposes frame_count and core_fps to rogpOS. Consumers calculate observed FPS from deltas. This separates the rate declared by the core from what was actually delivered.
Profile before adjustment
Aggressive adjustments remain off by default. The SNES stable profile targets 60 FPS without automatically enabling runahead, preemptive frames, or aggressive CPU policy. Each system can gain a specific profile after measurements and physical tests support the change.
Techniques and their costs
CPU governor
The governor performance requests the highest frequency allowed by the active policy. This can reduce latency variation, but increases consumption and temperature. rogpOS provides activation during the session and restoration of the previous state on exit, protected by trap.
Scheduling priority
SCHED_FIFO can reduce scheduler interference, but it is opt-in and needs fallback to nice. A misapplied real-time priority can harm audio, input, or the system itself.
Runahead and predictive frames
Runahead relies on fast save states and CPU slack. Ordering too many frames may produce choking or incorrect behavior. Therefore, the configuration is per system and starts off.
Frameskip
Frameskip can preserve emulation speed when the hardware cannot keep up with the design. It can also make movement jerky. In PPSSPP, the automatic limit needs to respect 30 FPS games so as not to unduly drop them to 15 or 10 FPS.
Cache and visible work
Textures use limited cache. Lists calculate the visible range and avoid rebuilding everything in each frame. Storage readings and process launches are outside the renderer. This discipline is usually worth more than isolated optimization.
Validation method
- Record version, device, system, core, and test content.
- Record FPS, frametime, audio, temperature and session duration.
- Change a single resource behind a flag.
- Repeat the same sequence and compare the distribution, not just the mean.
- Confirm input, audio, return to launcher and restore previous state.
- Keep rollback simple.
A gain without repetition, without an identified target or without a physical test remains a hypothesis.