Yamagi Quake II: 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, yamagi-quake2 8.70+dfsg-1+ps3.839

The platform builds under it (3)

Linux kernel	`6.12.111+ps3.786` Walnut's build
Mesa	`26.2.4-1+ps3.827` Walnut's build
ps3rsx	`0.788+k6.12.111+ps3.786` Walnut's build

Date	Launcher	Rules	Play	Ended	Picture
2026-10-26	Quake II (demo)	2.3	8 min	quit	minor	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.3	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 with the Quake II demo data: timedemo of the demo pak's only demo, q2demo1.dm2, on the gl1 renderer, fullscreen 1920x1080, vsync off.

The recipe's full description

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). Rows marked invalid or not comparable say why. The other numbers, the build and the run length are under "All numbers" in each batch.

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.

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	real-time priority 0	86.8	44.5	15
`base`	real-time priority 10	86.3	44.2	15

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 85.4 cpu 172.9 seconds underruns 0 underruns longest_ms 301.9 ms stall_play_s 3.8 seconds longest_play_ms 301.9 ms	no build recorded the game's resolution, warm-up + 120 s
`base`	fps whole run 84.9 cpu 172.8 seconds underruns 0 underruns longest_ms 320.1 ms stall_play_s 3.9 seconds longest_play_ms 320.1 ms	no build recorded the game's resolution, warm-up + 120 s

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	waker kick at 10 ms	65.7	20.1	33.5
`kiss4k`	YQ2_KISS_QSIZE=4096 waker kick at 10 ms	68.7	31.1	0.5

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 60.0 cpu 127.2 seconds underruns 0.0 underruns ram_free 12.2 MiB vram 48.2 MiB longest_ms 4508.5 ms stall_play_s 22.6 seconds longest_play_ms 4508.5 ms	Mesa ps3.407 the game's resolution, warm-up + 120 s
`kiss4k`	fps whole run 64.7 cpu 145.6 seconds underruns 0.0 underruns ram_free 46.4 MiB vram 48.2 MiB longest_ms 91.1 ms stall_play_s 0.1 seconds longest_play_ms 91.1 ms	Mesa ps3.407 the game's resolution, warm-up + 120 s

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base` not comparable	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 55.2 cpu 16.9 seconds underruns 20 underruns ram_free 27.0 MiB vram 48.2 MiB	Mesa ps3.262 the game's resolution, whole run

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`allog` not comparable	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`allog`	fps whole run 32.1 cpu 16.5 seconds underruns 14 underruns ram_free 31.7 MiB vram 48.2 MiB	Mesa ps3.262 the game's resolution, whole run

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 63.9 cpu 14.9 seconds underruns 19 underruns ram_free 37.4 MiB vram 48.2 MiB	Mesa ps3.262, ps3rsx 0.249 the game's resolution, whole run

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 51.4 cpu 15.7 seconds underruns 15 underruns ram_free 31.0 MiB vram 48.2 MiB	Mesa ps3.246, ps3rsx 0.249 the game's resolution, whole run

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 56.1 cpu 15.7 seconds underruns 7 underruns ram_free 36.4 MiB vram 48.2 MiB	no build recorded the game's resolution, whole run

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	Steady fps in the window	1% low fps	Stalls frames over 100 ms
`base`	the recipe as it is	-	-	-
`sdlsound`	the recipe as it is	-	-	-

All numbers and setup of this batch

Variant	Numbers	Setup
`base`	fps whole run 51.1 cpu 16.7 seconds ram_free 42.5 MiB vram 48.2 MiB	Mesa ps3.225 the game's resolution, whole run
`sdlsound`	fps whole run 58.4 cpu 16.5 seconds underruns 11 underruns ram_free 38.0 MiB vram 48.2 MiB	Mesa ps3.225 the game's resolution, whole run

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.