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`	-

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	Build	Run length	ram free MiB	vram MiB	stall play s seconds	longest play ms ms	sound faults per min faults a minute	cpu seconds	underruns underruns	longest ms ms	Note
Suite summary 2026-10-20 · `suite-summary-2026-10` Tested: Not a test run: the suite's 13 benchmarked games (15 rows, with OpenArena's two renderers and OpenTTD's two blitters) gathered with their known numbers as of October 2026, each value naming the batch or document it came from. Result: It is the calibration of the rating formula (rules 1): the scale was tried on these numbers before any game was rated, and the GameDB calibration table is generated from it. Benchmarks never give a medal; medals come from played sessions only.
Yamagi Quake II	YQ2_KISS_QSIZE=4096	68.7	31.1	-	-	-	warm-up + 120 s	46	48	0.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 · `2026-10-28-rtprio-openal` Tested: Whether letting OpenAL's mixer thread run at real-time priority (SCHED_RR, allowed by a priority limit of 10) prevents sound dropouts in OpenArena, Yamagi Quake II and Luanti, three rounds. Result: No gain: there were no audible dropouts with or without it, and it cost a little frame rate. Not shipped. What we saw 18 runs, rounds alternating the order, none interfered. Every run fullscreen at 1920x1080, with a screenshot 40 s after the load. 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, without against with: 68.55 against 68.3 fps steady, 1% low 37.5 against 36.6. Yamagi Quake II: 86.8 against 86.3 fps (the ranges don't overlap). Luanti: 46 against 45 fps (HUD), 1% low 19.8 against 20.9, stall time 4.1 against 2.6 s. 20 live runs outside the harness (OpenArena and Quake III with bots) agree: no gain, a small fps cost. Extreme Tux Racer and Armagetron were left out: their recipes need a virtual input device that was not installed (the runs sat in menus), and neither plays through OpenAL.
`base`	real-time priority 0	86.8	44.5	15	85.4	-	warm-up + 120 s	-	-	3.8	301.9	-	172.9	0	301.9
`base`	real-time priority 10	86.3	44.2	15	84.9	-	warm-up + 120 s	-	-	3.9	320.1	-	172.8	0	320.1
Mesa ps3.407 NV30_TRANSLATE_LUT, yquake2 ps3.408 kiss4k, luanti ps3.405 trim16 (all with WAKER kick) 2026-10-18 · `2026-10-18-mesa-407-lut` Tested: Three changes: Mesa ps3.407's lookup table for 8-bit vertex attributes on BananaBread, Yamagi Quake II's memory cut (kiss4k) and Luanti's trim16 setting. Result: The lookup table speeds BananaBread up by 53%, and Yamagi's memory cut ends its stalls (22.6 s to 0.05 s). Luanti's trim16 gave no gain and more stalls, so it was rejected. What we saw Same boot, two runs each, all with the 10 ms waker kick. BananaBread demo with the lookup table for 8-bit vertex attributes: steady 25.9 to 39.6 fps (+53%), 1% low 18.3 to 26.9. Yamagi Quake II with kiss4k: memory in use 125 to 56 MB, swap used 80 to 9 MB, gameplay stall time 22.6 to 0.05 s, longest frame 4.5 s to 91 ms, steady 65.7 to 68.7 fps. Luanti trim16: no gain and more stalls (3.35 to 8.6 s). Rejected. Pictures right on the webcam.
`base`	waker kick at 10 ms	65.7	20.1	33.5	60.0	Mesa ps3.407	warm-up + 120 s	12.2	48.2	22.6	4508.5	-	127.2	0.0	4508.5
`kiss4k`	YQ2_KISS_QSIZE=4096 waker kick at 10 ms	68.7	31.1	0.5	64.7	Mesa ps3.407	warm-up + 120 s	46.4	48.2	0.1	91.1	-	145.6	0.0	91.1
Mesa ps3.262 runs with perf recording (audio profiling) 2026-10-17 · `2026-10-17-mesa-262-perf` Tested: Plain-named runs made while the audio profiling was going on: dsda-doom's music, OpenArena and Yamagi Quake II on Mesa ps3.262. Result: Not valid for comparison: perf was recording during these runs, which explains the slow OpenArena and Yamagi numbers. They say nothing about a change in Mesa ps3.262. What we saw Perf was recording during these runs (said by the coordinator; the run folders do not show it). The numbers are not for comparison. dsda-doom playing at normal speed, twice: 1276 and 1422 ALSA underruns, HUD 51 and 50 fps. Probably the runs behind the profile that put the FluidSynth library at 48.3% of the game's samples. OpenArena: 39.7 fps with a 5.9 s longest frame, then 23.4 fps with a 15 s stall (the run ended with an error). The unprofiled suite run had 54.4. Lowest free memory in the two OpenArena runs: 38 and 13 MB. Yamagi Quake II: 55.2 fps (63.9 in the suite round). not comparable runs with perf recording (audio profiling), slower than plain runs.
`base` not comparable	the recipe as it is	-	-	-	55.2	Mesa ps3.262	whole run	27.0	48.2	-	-	-	16.9	20	-
Mesa ps3.262 OpenAL log variants (allog; perf recording) 2026-10-17 · `2026-10-17-mesa-262-allog` Tested: How much of the CPU OpenAL's sound mixing takes in four games, profiled with perf, to see whether moving the mixer to the SPUs would pay off. Result: OpenAL itself is 3.7-4.7% of the game's CPU samples, under the 6% bar set for an SPU mixer. The frame rates are slowed by the profiler and are not for comparison. What we saw OpenArena, Yamagi Quake II, Luanti and ClassiCube with stock OpenAL settings and OpenAL's log on, perf recording for 20 s from the sound start. One run each. The profiler slows the games: OpenArena 46.2 fps, Yamagi 32.1 (63.9 unprofiled), ClassiCube 45.6, Luanti 58 (HUD). Not for comparison. OpenAL itself is 4.7% of OpenArena's process samples and 3.7% of ClassiCube's: under the 6% bar for an SPU mixer. The sound device was stereo float32 at 48000 Hz (OpenAL's ALSA path). No underruns except in Yamagi (14). not comparable OpenAL logging runs with perf recording, slower than plain runs.
`allog` not comparable	the recipe as it is	-	-	-	32.1	Mesa ps3.262	whole run	31.7	48.2	-	-	-	16.5	14	-
Mesa ps3.262 + ps3rsx 0.249 2026-10-17 · `2026-10-17-mesa-262` Tested: Mesa ps3.262 (patches 0019 to 0025: fewer words sent to the GPU per draw) across the suite, against ps3.246. Result: Big gains in several games: OpenArena +23%, Yamagi +24%, X-Moto +21%, Extreme Tux Racer and dsda-doom +15%. Armagetron fell from 60 to 51 fps, which the next batches traced. Single runs; BananaBread's drop is a memory stall, not a driver number. What we saw The patches: no relocations, the texture cache invalidated only after texture changes, no duplicate vertex-format writes, batched vertex program constants. One run per game. Against ps3.246: OpenArena with compressed textures 44.2 to 54.4 fps (+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 with the demo now finishing (+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 batch), Luanti 53 to 53. Armagetron dropped from 60 to 51 (driver frame counter). BananaBread reads 28 to 8 on the counter, but it was memory-stalled (13 MB free, killed at the cap): not a driver number, and the cause is uncertain. The kernel's command validator rejected nothing. Single runs.
`base`	the recipe as it is	-	-	-	63.9	Mesa ps3.262, ps3rsx 0.249	whole run	37.4	48.2	-	-	-	14.9	19	-
Mesa ps3.246 + ps3rsx 0.249 2026-10-17 · `2026-10-17-mesa-246-ps3rsx-249` Tested: The first full suite round after the reboot into ps3rsx 0.249, one run per game, as a baseline. Result: Every game ran with the right picture. The sound was right except in dsda-doom (MIDI music), BananaBread and OpenTTD. Single runs, so differences of a few fps are noise. What we saw One run per game. Frame rates by the game's own counter, or the driver's frame counter where marked: Armagetron 60 (counter), ClassiCube 47.6, dsda-doom software 33 (counter, demo unfinished), Extreme Tux Racer 46 (counter), Luanti 53 (counter), Neverball 78.2. OpenArena with compressed textures 44.2 (longest frame 2.1 s), QuakeSpasm 70.5, BananaBread with CPU skinning 28 (counter), X-Moto 39 (counter), Yamagi Quake II 51.4. Pictures right. Sound right except dsda-doom (1161 underruns, MIDI music), BananaBread (176) and OpenTTD (1429, choppy). OpenTTD used 55.5 s of CPU and has no frame rate (plain X11 path). Single runs: differences of a few fps are within the run-to-run spread.
`base`	the recipe as it is	-	-	-	51.4	Mesa ps3.246, ps3rsx 0.249	whole run	31.0	48.2	-	-	-	15.7	15	-
Yamagi Quake II sample byte-swap fix (yquake2 +ps3.240) 2026-10-16 · `2026-10-16-yquake2-byteswap` Tested: Our yquake2 +ps3.240, which swaps 16-bit sound samples to the machine's byte order on load, against the white noise found before. Result: Fixed: sound right through OpenAL (the user confirmed), picture right, 56.1 fps, 7 underruns. Single run. What we saw Our yquake2 8.70 +ps3.240 with OpenAL, single run. 56.1 fps, picture right. Sound right, confirmed by the user; 7 underruns. Proves the fix for the white noise of the previous Yamagi batch.
`base`	the recipe as it is	-	-	-	56.1	-	whole run	36.4	48.2	-	-	-	15.7	7	-
Yamagi Quake II OpenAL white noise (yquake2 +ps3.229; Mesa ps3.225) 2026-10-16 · `2026-10-16-yquake2-white-noise` Tested: Yamagi Quake II as our package, with its OpenAL sound against its SDL sound backend, to find where its white-noise sound comes from. Result: The noise is the OpenAL path, not the hardware: with SDL sound the audio is right. The OpenAL backend handed little-endian samples to OpenAL on this big-endian machine; fixed in yquake2 +ps3.240. What we saw Debian's yquake2 8.70 built as our package, OpenGL 1 renderer, timedemo q2demo1, single runs. With OpenAL: the sound is white noise; 51.1 fps. With the SDL sound backend: sound right; 58.4 fps. So the noise is the OpenAL path, not the hardware: the OpenAL backend handed little-endian WAV samples to OpenAL.
`base`	the recipe as it is	-	-	-	51.1	Mesa ps3.225	whole run	42.5	48.2	-	-	-	16.7	-	-
`sdlsound`	the recipe as it is	-	-	-	58.4	Mesa ps3.225	whole run	38.0	48.2	-	-	-	16.5	11	-