Yamagi Quake II: test runs

Played sessions

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

Date	Version	Launcher	Kind	Rules	Play	Ended	Picture	Builds
2026-10-26	Walnut 0.1 yamagi-quake2 8.70+dfsg-1	Quake II (demo)	session	2.2	8 min	quit	minor	yamagi-quake2 8.70+dfsg-1+ps3.839 Linux kernel 6.12.111+ps3.786 Mesa 26.2.4-1+ps3.827 ps3rsx 0.788+k6.12.111+ps3.786	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 yamagi-quake2 8.70+dfsg-1	2026-10-26	Gold · 88	2.2	83	85	100	75	90	100	85	100	94	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: Yamagi Quake II 8.70 (our build of Debian's yquake2, gamedb/games/yquake2/packages/yquake2/) with the Quake II demo data (quake2-demo-data from make game-data: /usr/share/games/quake2-demo/baseq2/pak0.pak): timedemo of the demo pak's only demo, q2demo1.dm2, on the gl1 renderer (GL 1.4 fixed function; gl3 needs GL 3), fullscreen 1920x1080, vsync off (a timedemo isn't otherwise capped). It returns to the console after the demo: stopped at the result line. The engine is run directly (Debian's quake2 wrapper package is contrib and not ours); the config is ~/.local/share/YamagiQ2/baseq2/config.cfg (8.70 is built with XDG support: "Using '<home>/.local/share/YamagiQ2/baseq2' for writing", session of 2026-10-26); builds without it used ~/.yq2. Steady state: the timedemo repeated in one session (PASSES=1: passes starting 54 s or more after the first counted until ~120 s, then the game is stopped). At a demo's end the server runs the nextserver cvar, which demomap fills from nextdemo; autoexec.cfg's alias `bench` sets nextdemo again, disconnects (CL_Disconnect prints the pass's line; a plain chained demomap would reconnect and clear the counters without a line, cl_parse.c CL_ClearState) and starts the demo cold again. Each pass prints "ERROR: Disconnected from server" too. fps= is the first pass's (as before).

The recipe today runs it at the game's own resolution, with vblank_mode=0 (vsync off). Older batches ran the recipe as it was then: their titles and observations say what changed (a new game build, a driver change).

13 variants of the recipe

`base`	the recipe as it is, without a variant
`sdlsound`	Yamagi's SDL sound backend instead of OpenAL (OpenAL gave white noise on the PS3: 16-bit samples with their bytes swapped somewhere on the way, big-endian)
`kissbig`	the KISS PRNG's lag table (our yquake2 0002, YQ2_KISS_QSIZE): the package's default is 4096 entries, 32 KiB each (docs/MEMORY.md; measured on the PS3: 70 MB less RAM, gameplay stalls 22.6 -> 0.05 s). The old table was 16 MiB in the client and 16 MiB in game.so, all written at start (32 MB of the game's 77 MB resident): variant kissbig restores it (the base is the small table). Client-side randomness (particles) differs from the old sequence, the demo doesn't
`kiss4k` stands for the game	-
`allog`	-
`b16`	-
`f44`	-
`b16f44`	-
`p1024`	-
`alnull`	-
`f32`	-
`lin`	-
`nosound`	-

Conditions: what a variant adds to the recipe (its environment switches) and what ran alongside (the stall recorder, a profiler). Length: "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. Rows marked invalid or not comparable say why.

Suite summary

2026-10-20 · batch suite-summary-2026-10

Purpose: The 13 benchmarked games (15 rows) with their known numbers, the rules-1 calibration of the rating formula (docs/GAMEDB.md "Calibration", tools/gamedb/score.py). Each value names its source: a batch's cell, or the suite table of docs/games/README.md where the number is a reading or a range (no single cell holds it). Stutter is the stall seconds over the 2-minute window; load unmeasured, stability assumed clean, picture and display right.

Row	ram_free MiB	vram MiB	fps_steady frames a second	stall_play_s seconds	low1_play frames a second	longest_play_ms ms	sound_faults_per_min faults a minute	Picture, sound
Yamagi Quake II kiss4k	46	48	68.7	0.1	31.1	91	0	right, right (our fix)

RT mixer: RTPRIO=10 against RTPRIO=0 (OpenAL's mixer on SCHED_RR) on OpenArena, Yamagi Quake II and Luanti base x3 (kernel .874)

2026-10-28 · batch 2026-10-28-rtprio-openal · 18 runs in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	longest_ms ms	stall_play_s seconds	longest_play_ms ms
`base`	real-time priority 0	-	the game's	warm-up + 120 s	85.4	86.8	44.5	15	172.9	0	301.9	3.8	301.9
`base`	real-time priority 10	-	the game's	warm-up + 120 s	84.9	86.3	44.2	15	172.8	0	320.1	3.9	320.1

Observations: same boot (2026-10-28 00:19-01:23Z), 18 runs, rounds alternating the order, none interfered; every run fullscreen at 1920x1080 (geom=) and a screenshot 40 s after the load (OpenArena's mostly the demo's map load screen, Yamagi's demo, Luanti's flight). No audible dropout in either arm; inaudible gaps 4 without the limit (Luanti 3, up to 102 ms; Yamagi 1, 67 ms), 1 with it (Yamagi, 7 ms). OpenArena steady 68.55 against 68.3, 1% low 37.5 against 36.6; Yamagi steady 86.8 against 86.3 (ranges not overlapping); Luanti HUD 46 against 45, 1% low 19.8 against 20.9, stall time 4.1 against 2.6 s. With the 20 live runs (OpenArena and Quake III with bots, outside the harness: docs/SPU-AUDIO.md "Real-time mixer"): no gain, a small fps cost, not shipped. Extreme Tux Racer and Armagetron left out: their base recipes need evemu-device, which is not installed (the runs sat in menus), and neither plays through OpenAL

Mesa ps3.407 NV30_TRANSLATE_LUT, yquake2 ps3.408 kiss4k, luanti ps3.405 trim16 (all with WAKER kick)

2026-10-18 · batch 2026-10-18-mesa-407-lut · 12 runs in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB	longest_ms ms	stall_play_s seconds	longest_play_ms ms
`base`	waker kick at 10 ms	Mesa ps3.407	the game's	warm-up + 120 s	60.0	65.7	20.1	33.5	127.2	0.0	12.2	48.2	4508.5	22.6	4508.5
`kiss4k`	YQ2_KISS_QSIZE=4096 waker kick at 10 ms	Mesa ps3.407	the game's	warm-up + 120 s	64.7	68.7	31.1	0.5	145.6	0.0	46.4	48.2	91.1	0.1	91.1

Observations: same boot 2026-10-18 ~05:50-06:50 local, x2. Sauerbraten demo: steady 25.9 -> 39.6 (+53%), low1 18.3 -> 26.9 with NV30_TRANSLATE_LUT=1 (8-bit vertex attributes via a lookup table). Yamagi Q2: kiss4k RSS 125 -> 56 MB, swap used 80 -> 9 MB, stall_play_s 22.6 -> 0.05, longest 4.5 s -> 91 ms, steady 65.7 -> 68.7. Luanti trim16: no gain, more stalls (3.35 -> 8.6 s): rejected. Webcam: pictures right

Mesa ps3.262 runs with perf recording (audio profiling)

2026-10-17 · batch 2026-10-17-mesa-262-perf · 5 runs in the batch (all games)

Not comparable: runs with perf recording (audio profiling), slower than plain runs.

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`base` not comparable	the recipe as it is	Mesa ps3.262	the game's	whole run	55.2	-	-	-	16.9	20	27.0	48.2

Observations: 11:38-11:49Z, plain-named runs between the profiled ones: dsda-doom 'play' twice (1276 and 1422 underruns, HUD 51 and 50; probably the runs behind the profile that gave libfluidsynth 48.3% of the process samples), OpenArena base 39.7 fps with a 5.9 s longest frame and then 23.4 fps with a 15 s stall (rc 1; the suite run had 54.4), Yamagi 55.2 fps (63.9 in the suite). MemAvailable fell to 38 and 13 MB in the two OpenArena runs. Perf was recording during these runs (told by the coordinator; the run directories have no during.log), which explains the slow OpenArena and Yamagi runs. Do not read them as a change in Mesa ps3.262; the cells are not for comparison.

Mesa ps3.262 OpenAL log variants (allog; perf recording)

2026-10-17 · batch 2026-10-17-mesa-262-allog · 4 runs in the batch (all games)

Not comparable: OpenAL logging runs with perf recording, slower than plain runs.

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`allog` not comparable	the recipe as it is	Mesa ps3.262	the game's	whole run	32.1	-	-	-	16.5	14	31.7	48.2

Observations: 11:30-11:38Z, the 'allog' variant (stock OpenAL settings, OpenAL log in the run directory) of OpenArena, Yamagi, Luanti and ClassiCube with perf attached for 20 s from the sound start (during.log), for SPU-AUDIO.md's M0. The profiled runs are slower (OpenArena 46.2 fps, Yamagi 32.1 against 63.9, ClassiCube 45.6, Luanti HUD 58), so the fps and CPU cells are not for comparison. Result: libopenal itself is 3.7-4.7% of the process samples (OpenArena 4.7, ClassiCube 3.7), under the 6% bar for an SPU mixer; the device was Stereo Float32 48000 Hz (OpenAL's ALSA path). No underruns in any of them except Yamagi (14). One run each.

Mesa ps3.262 + ps3rsx 0.249

2026-10-17 · batch 2026-10-17-mesa-262 · 12 runs in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`base`	the recipe as it is	Mesa ps3.262, ps3rsx 0.249	the game's	whole run	63.9	-	-	-	14.9	19	37.4	48.2

Observations: 2026-10-17 10:42-11:04Z, suite round after Mesa 0019-0025 (fewer words per draw: no relocations, texture cache invalidate only after texture changes, no duplicate VTXFMT writes, batched VP constants; bcd99d7, 5fe2290), one run per game. Against ps3.246: OpenArena tc1 44.2 to 54.4 (+23%), Yamagi 51.4 to 63.9 (+24%), X-Moto 39 to 47 (+21%), Extreme Tux Racer 46 to 53 (+15%), dsda-doom software 33 to 38 and now finishes (+15%), ClassiCube 47.6 to 50.1 (+5%), Neverball 78.2 to 71.5 (noise), QuakeSpasm 70.5 to 66.3 (repeated in the next row), Luanti 53 to 53. Armagetron drops from 60 to 51 (HUD). Sauerbraten reads 28 to 8 (HUD): it is memory-stalled (MemAvailable 13 MB, killed at the cap), so that is not a driver number and the cause is uncertain. No validator rejects. Single runs.

Mesa ps3.246 + ps3rsx 0.249

2026-10-17 · batch 2026-10-17-mesa-246-ps3rsx-249 · 12 runs in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`base`	the recipe as it is	Mesa ps3.246, ps3rsx 0.249	the game's	whole run	51.4	-	-	-	15.7	15	31.0	48.2

Observations: 2026-10-17 08:32-08:54Z, first suite round after the reboot, one run per game. fps: Armagetron 60 (HUD), ClassiCube 47.6, dsda-doom software 33 (HUD, demo unfinished), Extreme Tux Racer 46 (HUD), Luanti 53 (HUD), Neverball 78.2, OpenArena tc1 44.2 (longest frame 2.1 s), QuakeSpasm 70.5, Sauerbraten CPU skinning 28 (HUD), X-Moto 39 (HUD), Yamagi Quake II 51.4. Pictures right and sound right for these games except dsda-doom (1161 underruns, MIDI music), Sauerbraten (176) and OpenTTD (1429, choppy). OpenTTD base ran 55.5 s of CPU with no frame rate (plain X11 path). Single runs, so differences of a few fps are within the run-to-run spread.

Yamagi Quake II sample byte-swap fix (yquake2 +ps3.240)

2026-10-16 · batch 2026-10-16-yquake2-byteswap · 1 run in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`base`	the recipe as it is	-	the game's	whole run	56.1	-	-	-	15.7	7	36.4	48.2

Observations: 23:56Z, our yquake2 8.70+dfsg-1+ps3.240 (5ae1eb4: 16-bit WAV samples swapped to host order on load): 56.1 fps with OpenAL, picture right, the sound right (the user confirmed per GAME-PLAN), 7 underruns. Proves the fix for the white noise of the previous Yamagi row. Single run.

Yamagi Quake II OpenAL white noise (yquake2 +ps3.229; Mesa ps3.225)

2026-10-16 · batch 2026-10-16-yquake2-white-noise · 2 runs in the batch (all games)

Variant	Conditions	Build	Resolution	Length	fps whole run	Steady fps in the window	1% low fps	Stalls frames over 100 ms	cpu seconds	underruns underruns	ram_free MiB	vram MiB
`base`	the recipe as it is	Mesa ps3.225	the game's	whole run	51.1	-	-	-	16.7	-	42.5	48.2
`sdlsound`	the recipe as it is	Mesa ps3.225	the game's	whole run	58.4	-	-	-	16.5	11	38.0	48.2

Observations: 23:22-23:24Z, Debian's yquake2 8.70 as our package, gl1, timedemo q2demo1. With OpenAL (base) the sound is white noise on big-endian and 51.1 fps; with its SDL backend (variant sdlsound, s_openal 0) the sound is right and the game runs at 58.4 fps. So the noise is the OpenAL path (70b219b), not the hardware: the OpenAL backend handed little-endian WAV samples to alBufferData. Single runs.