PGR2 Performance Test Routes

PGR2 Performance Test Routes

This page records the canonical automated Project Gotham Racing 2 workloads used by the xemu performance lab. Keep these routes stable so results from different commits and hosts remain comparable.

Workload identities

Workload	Start state	Purpose
PGR2 full start	Fresh HDD seed and a new xemu process	Startup plus deterministic menu-to-race progression, followed by live gameplay
PGR2 snapshot	Named retained guest snapshot	Repeatable scene testing without startup or menu traversal

Do not combine these rows or compare their raw frame metrics as if they were the same workload. A full-start result must not be labeled a snapshot result, and a snapshot result does not validate fresh-start behavior.

Canonical direct-script full-start input route

The established Windows direct-capture script starts with a 10-second emulator/firmware settle, then waits the suffix delay before sending each key:

A-3, A-10, A-2, A-2, F-2, A-2, A-2, A-2, A-2, A-2, A-7

A is the Xbox A button. F is the lab keyboard binding for left-stick right. Expressed as absolute press times after launch, the sequence is:

Elapsed	Input
13 s	A
23 s	A
25 s	A
27 s	A
29 s	Left stick right
31 s	A
33 s	A
35 s	A
37 s	A
39 s	A
46 s	A

Wait another 10 seconds before the race-entry capture. The first early A press skips the startup videos when the guest controller is attached. The later inputs select the player profile, Single Player, Arcade Racing, Street Racing, the event, difficulty and race start.

The canonical direct-script source is run-pgr2-freshboot-presentmon.ps1, SHA-256 cff35d8a9086945f9c6d07865a0cca7065229ca7db84bf6a165a240c7d86a418 as validated on 2026-09-22. Its key sender uses a 100 ms tap. Do not assume that a runner plan with a different input provider, disk seed, or button-hold duration can omit its own route calibration.

Required controller binding

Setting only port1_connected = 1 creates the virtual port but does not attach the keyboard input provider. Automated key injection requires an explicit binding:

[input.bindings]
port1_driver = 'usb-xbox-gamepad'
port1 = 'keyboard'

[input.virtual_ports]
port1_connected = 1

Without [input.bindings], the title screen can time out into attract mode and falsely look like it accepted input. This previously caused a startup-animation capture to be mislabeled as an in-game performance result.

Runner translations

For Xemu Test Runner plans, represent each delay as an explicit wait followed by a button action. Map F to LStickRight and use 100 ms taps when matching the direct Windows script.

The Steam Deck translation used the 11-input direct-script sequence above. The validated Windows runner route revision 2 needs one additional confirmation after the old final A:

A-3, A-10, A-2, A-2, F-2, A-2, A-2, A-2, A-2, A-2, A-7, A-2

The added A occurs at 48 seconds after launch. In the Windows runner workload, the 46-second A opens the Select Transmission prompt and the added A confirms it. Wait another 10 seconds after the added confirmation before capturing race-entry.

This route was calibrated on an unchanged reference build before use in an A/B matrix. Run 20260923-073715856-7ff152879e6b48a492a57c1dce6f8793 reached live gameplay, passed the runner correctness and evidence contracts, and advanced from the starting grid to 27.122 seconds of race time during the 30-second throttle segment. The eight earlier 11-input Windows cells are retained as negative controls: all stopped at Select Transmission, proving that whole-image non-black checks were insufficient.

After the platform-specific final 10-second settle:

1. Capture race-entry and require the calibrated HUD region.
2. Start the measured gameplay segment.
3. Hold RTrigger for the declared fixed duration, currently 30 seconds for the Steam Deck screen.
4. Capture steady-race and require the same calibrated HUD region.
5. End the segment and quit xemu cleanly.

The route was revalidated on Steam Deck with exact xemu main 084de1db6e, Xemu Test Runner f82004c37c, Vulkan/RADV and a fresh HDD seed. Run 20260922-192045257-c8f9251648cb440784deba461cd154c2 reached a visible live race after about 57 seconds and completed the 30-second throttle segment. The older 130-second title wait remains a fallback diagnostic route, not the canonical performance route.

Steam Deck X11 binding check — September 27, 2026

The later Deck runner at 1ba4c530 did not deliver its configured host a key during scripted jobs. Controlled X11 key-state monitoring recorded the other scripted keys, but no a transition. A crossover job mapped logical Xbox A to host q and logical Xbox B to host a: A advanced PGR2's menu and B did not. The crossover had zero operator inputs. This isolates the failure to the Deck host a input path in that session; it does not establish a general xemu or runner-source regression.

For this Deck installation, the runner's XemuControl.ButtonKeys.A is q. Every matching PGR2 job must also set Xbox A to SDL scancode 20 in its portable xemu config:

[input.keyboard_controller_scancode_map]
a = 20

Keep the runner host key and xemu scancode paired. Block manual input during controlled jobs and check operator-events.jsonl after each run. The 13-second first A skips the startup video; the 130-second route can leave the intro visible for two minutes and must retain its separate diagnostic identity. With this binding, parent and candidate full-start proof jobs reached the race HUD and a moving car through the runner's scripted inputs. Their corrected evidence results are 20260927-023605736-598377ff122646f29b27fcc7cf4e939a and 20260927-024110718-a819d326826e457598922dc978deec51.

For the Deck's 1280×718 runner screenshots, a race speedometer check was calibrated against captured title, pre-race and loading negatives. Both race-entry.png and steady-race.png use normalized region (X=0.72, Y=0.70, Width=0.12, Height=0.15), RGB threshold 160, and minimum non-black ratio 0.015. The sampled negative frames measured zero in that region; sampled race frames measured 0.032–0.049. This is a Deck-specific route gate. Continue visual inspection of every accepted run, since a bright region alone cannot prove comparable gameplay or audio behavior.

The HUD gate also accepts the starting grid at 000 MPH. For a sustained-gameplay claim, retain guest-flips.log as a separate evidence requirement and check that it contains multiple nonzero frame-count intervals. A 500-byte minimum admitted 19 intervals in the controlled 30-second-throttle Deck run 20260927-035331924-48385eaab028424fa393a41c9fc9b2fc; a 1,000-byte minimum falsely rejected the same log format. Inspect both race captures and require a visibly progressed scene and nonzero speed after throttle (that run moved from 000 to 078 MPH). The log proves rendering progression, while the captures establish movement in PGR2. A fixed-time input plan can still diverge at a loading screen or the transmission menu, so plan completion and a clean operator log cannot replace these checks.

Evidence gates

For 1296x999 Windows external-window captures of the 1280x960 game window, the validated race-HUD gate is:

{
  "MinimumNonBlackPixelRatio": 0.05,
  "NonBlackPixelThreshold": 96,
  "ImageRegion": {
    "X": 0.07,
    "Y": 0.08,
    "Width": 0.19,
    "Height": 0.25
  }
}

The retained Select Transmission negative controls measured 0% qualifying pixels at threshold 96 in this region. Two independently launched valid Vulkan baseline captures measured roughly 13–20%, leaving a useful margin above the fixed 5% requirement. Recalibrate rather than silently reusing these normalized coordinates when the capture provider, window decoration, resolution, or renderer materially changes.

A successful process exit is not sufficient. A full-start cell must retain:

• exact xemu source and executable identities;
• for GitHub pull-request CI artifacts, the PR head, workflow event, and embedded test-merge commit as distinct identities (the AppImage can contain a synthetic merge rather than the standalone head);
• exact runner identity;
• fresh HDD seed identity and isolated runtime copy;
• renderer, resolution, cache and worker settings;
• the input plan and measurement-segment boundaries;
• visible race-entry and steady-race captures with non-black-pixel assertions;
• visual movement/frame-progression checks for a sustained-gameplay claim;
• guest frame/progress output and enough telemetry samples for the declared window;
• a runner assessment with correctness passed, evidence complete and comparison eligible.

Inspect the captures before accepting a new route or host. File existence alone cannot prove that the game reached the intended state. Keep raw captures, game data, firmware, EEPROM and disk images in the private evidence store; PRs should carry compact text summaries and run identities.

Route-change policy

Do not alter the route inside an A/B series. If timing must change for a platform or title revision:

1. validate the new route on an unchanged reference build;
2. prove equivalent race state with the required captures;
3. record a new route revision and retain the old identity;
4. restart the A/B series so every compared cell uses the same route.

Use this full-start route alongside the existing PGR2 snapshot and Morrowind snapshot workloads. Add a new game route only when those established workloads cannot exercise the behavior under test.