Trigger Rally: test runs

Played sessions

Testing is done with Walnut's rating tool (walnut-rate, on the console): how ratings are made and submitted.

Builds: Walnut 0.1, trigger-rally 0.6.6.1-4+b1

The platform builds under it (3)

Linux kernel	`6.12.111+ps3.874` Walnut's build
Mesa	`26.2.4-1+ps3.1139~dev20261029214356` Walnut's build
ps3rsx	`0.924+k6.12.111+ps3.874` Walnut's build

Date	Launcher	Rules	Play	Ended	Picture
2026-10-29	Trigger Rally	2.3	5 min	quit	wrong	Details

Download all sessions as CSV (one row per session, the aspects as columns)

Rating history

The rating on each version it was tested on, newest first: each row is rated from that version's sessions alone, under the newest rules those sessions have the data for.

Version	Tested	Medal	Rules	Frame rate	Smoothness	Sound	Picture	Stability	Controls	Display	Features	Load	Play
Walnut 0.1 trigger-rally 0.6.6.1-4+b1	2026-10-29	Rust · 84	2.3	70	74	100	75	90	100	100	100	97	0.1 h 1 test

Scripted benchmarks

Not rated: tests of driver and game changes. A script plays the same scene on the PS3 again and again (the desktop stopped, vsync off) to compare two builds of the game or of the graphics driver. The numbers say which build is faster; they never feed the medal.

How the script plays it: Trigger Rally 0.6.6.1: smoke test, not benchmarked. Menu only: the game has no command-line options, so the player starts a race by hand.

The recipe's full description

Trigger Rally 0.6.6.1 (Debian ports ppc64: trigger-rally, trigger-rally-data 116 MB download): smoke test, not benchmarked. Menu only: the game has no command-line options, so the player starts a race by hand (Enter on Single Race / the arrow keys, pick an event and a stage, Enter; drive with the arrow keys, Space is the handbrake, R recovers, C changes the camera). Fullscreen at the desktop resolution comes from setup(): a copy of /etc/trigger-rally.config.defs written to the user's config file with 1920x1080 fullscreen and the cheaper options (no foliage, no weather, no dirt effect, no anisotropic filtering, point snowflakes), restored after the run. What it exercises: GL 2.0 compatibility with fixed function and GLEW (terrain, sky, cars), SDL2_image JPEG/PNG textures (the stage textures are big: RAM is the risk, the data is 121 MB installed), OpenAL + ALUT for the engine and the co-driver's voice. Risks: terrain drawn from many large draws per frame on the PPE, GLEW picking extensions nv30 lacks (it only prints), RAM during the stage load. Variant full: the game's own defaults (foliage, weather, anisotropy 4) to see what the cheap settings buy.

5 variants of the recipe

`base`	the recipe as it is, without a variant
`full`	-
`menu`	-
`fresh`	-
`freshrace`	-

One table, a header row per batch (what it tested and what came out). Conditions: what a variant adds to the recipe (its environment switches) and what ran alongside (the stall recorder, a profiler); a column appears only when this game has a value in it. Rows marked invalid or not comparable say why.

What the run length means

"warm-up + 120 s" is a steady-state run, which leaves out a 60 s warm-up and measures 120 s or more; "whole run" counted everything from the start, the way runs before 2026-10-17 did.

Variant	Conditions	Steady fps in the window	1% low fps	Stalls frames over 100 ms	fps whole run	Run length	cpu seconds	underruns underruns	ram free MiB	vram MiB	longest ms ms	stall disk s seconds	stall swap s seconds	stall reclaim s seconds	stall gpu s seconds	stall cpu s seconds	stall play s seconds	longest play ms ms
Mesa ps3.924 + kernel .874, profiled smoke runs (STALLS=1 PERF=1): which threads hold the CPU in the stall frames 2026-10-29 · `2026-10-29-worker-threads` Tested: Whether Luanti's problem (the main thread starved by the game's own worker threads in the stall frames) shows up in other games with many threads: one profiled run each of Scorched 3D, Trigger Rally and Endless Sky. Result: It doesn't: in the stall frames the main thread ran 62% (Scorched 3D) and 74% (Trigger Rally) of the time and the other game threads only 9% and 8%, against 22% and 83% in Luanti before its fix. No general renicing was built. What we saw One profiled run per game, VRAM swap on, every run fullscreen 1920x1080, process check clean. Scorched 3D: 20 fps, 13.5 s of stalls in 90 s. In the stall frames the main thread ran 62% of the time, the other game threads 9%. The kernel's swapper took 23% of the stall time, and the main thread decoding the Ogg music 18% of its stall samples. Picture right (bots firing, island, HUD). Trigger Rally: 59 fps, 3 stall frames, one of them the 13.9 s stage load inside the window. Main thread 74%, other threads 8%. The race drawn (the car standing at the start). Endless Sky: disturbed by an SSH command at 331 s and left out. Its profile covers the data load, where the two loader threads have 74% of the CPU and the main thread 16%, waiting for them as designed. Luanti before its fix, for comparison: main thread 22%, other threads 83%.
`freshrace`	stall recorder at 10 ms perf recording	59	32.0	3	59	warm-up + 120 s	94.2	0	52.6	194.6	13875.0	0.5	0.0	0.4	0.4	15.2	17.1	13875.0