SuperTuxKart: test runs

Played sessions

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

Same in every session: Walnut 0.1

Date	Launcher	Game build	Platform builds that differ	Rules	Play	Ended	Picture
2026-10-26	SuperTuxKart	supertuxkart 1.5-2+ps3.833	Linux kernel 6.12.111+ps3.786 Mesa 26.2.4-1+ps3.850 ps3rsx 0.788+k6.12.111+ps3.786	2.3	13 min	quit	ok	Details
2026-10-26	SuperTuxKart	supertuxkart 1.5-2+ps3.833	Linux kernel 6.12.111+ps3.747 Mesa 26.2.4-1+ps3.827 ps3rsx 0.788+k6.12.111+ps3.786	2.3	12 min	crash	minor	Details
2026-10-25	SuperTuxKart	supertuxkart 1.5-2+ps3.786	Linux kernel 6.12.111+ps3.747 Mesa 26.2.4-1+ps3.827 ps3rsx 0.735+k6.12.111+ps3.747	1.0	2 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 supertuxkart 1.5-2	2026-10-26	Silver · 69	2.3	5	58	98	95	91	100	100	100	71	0.2 h 2 tests
Walnut 0.1 supertuxkart 1.5-2	2026-10-25	Scrap · 31	1.0	-	-	73	-	90	-	-	-	97	0.0 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: SuperTuxKart 1.5. Its profile mode starts a race at once with every kart driven by the AI, drives for the given seconds, prints "Number of frames: N time T, Average FPS: F" and quits.

The recipe's full description

SuperTuxKart 1.5 (our build, gamedb/games/supertuxkart/packages/supertuxkart/: big-endian .spm loading, legacy-renderer fixes; 839 MB with its data, deployed by name). Its profile mode (--profile-time) starts a race at once with every kart driven by the AI, drives for the given seconds, prints "Number of frames: N time T, Average FPS: F" and quits. GL 2.1 picks the legacy renderer by itself ("Using the fixed pipeline"). RAM and VRAM are the risk (its FAQ wants 1 GB against our 217 MB): a small track and 4 karts. setup() writes the whole config (~/.config/supertuxkart/config-0.10/config.xml) every run, so the run doesn't depend on what an earlier one saved: the settings below, everything else at the game's defaults (a file without a key keeps that key's default). Names from src/config/ user_config.hpp; the file has one element per group with the settings as attributes. The game rewrites it when it quits (BACKUP restores it). base: the game's defaults (HD textures on: up to 2048x2048; texture compression on, which our 0004 makes reach the legacy renderer: opaque power-of-two textures as DXT1, compressed by Mesa at upload; the minimap shown, 512x512 render target with 0003), but vsync off and the old-driver popup off. Every variant changes one thing, except lean (the candidate PS3 default). Memory per run: during.log has MemAvailable and SwapFree every 5 s, bench.txt their lowest. Steady state: the HUD window, 60 s from the end of the track load (LOAD_MARK, the Track: line printed when the scene is built; the race starts at once, no countdown), then 120 s. Our patch 0005 (ProfileWorld::update) with STK_PROFILE_WARMUP=60 restarts the tick count and the clock once the race time passes 60 s and ends the race at 60 + the profile time (180 s: 240 s of race, 180 s measured); the "Average FPS" line it prints is ticks per second (see FPS_RE below). The race is AI-driven (rand() seeded from the clock, frame-time physics): close between runs, not identical.

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

11 variants of the recipe

`base`	the recipe as it is, without a variant
`nohd`	HD textures off (bit 1: the user's choice, so the game doesn't turn them back on): textures are scaled down to max_texture_size (512) at load instead of 2048. The biggest single VRAM and RAM cut expected: a 2048x2048 RGBA8 texture is 16 MB, at 512 1 MB (DXT1: 128 KB)
`tex256`	the same capped at 256
`notc`	no texture compression: every texture RGBA8, as Debian's build (isolates 0004: VRAM, load time)
`nomap`	minimap hidden: its render target (FBO texture plus depth buffer) isn't made (0003)
`noparticles`	no particles (skid, nitro, weather, explosions): fewer billboards and their textures
`static`	drivers not animated: the legacy renderer skins every animated kart on the CPU each frame
`geo0`	LOD switched at the shortest distances (Very Low): draw cost, not memory (every level is loaded)
`vsync`	vsync on, the game's default (base turns it off)
`karts1`	fewer karts on the track (their models load at startup anyway; this is draw and AI cost)
`lean` stands for the game	the candidate PS3 default if the single steps hold: HD textures off (512), compression on, no minimap, important particles only, static drivers

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	stall disk s seconds	stall swap s seconds	stall reclaim s seconds	stall gpu s seconds	stall cpu s seconds	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.
SuperTuxKart lean	the recipe as it is	21.0	11.8	-	-	-	warm-up + 120 s	26	97	1.8	513	3	-	-	-	-	-	-	-	-	track draws, sound running
batch ssdroot12 snd_ps3 DMA watchdog (kernel local/0047): dma_watchdog_ms=200 against 0 (off) on SuperTuxKart lean, OpenArena gl2min and ClassiCube base x3 (SSD root .472 Mesa ps3.545~dev, .472 with the test module) 2026-10-20 · `2026-10-20-ssdroot12-dma-watchdog` Tested: Whether the new snd_ps3 DMA watchdog (kernel patch 0047, which restarts the sound card's DMA when it stalls for 200 ms) prevents the OpenAL wedge, against the watchdog off, on SuperTuxKart, OpenArena and ClassiCube, three rounds. Result: Yes: with it off 2 of 9 runs wedged; with it on none did, two stalls were caught and restarted, and the sound kept going. Frame rates were equal. The watchdog stays on by default in the kernels since. What we saw 18 runs rotated with system dumps on; one OpenArena run with the watchdog off was interfered by two logins and left out. Watchdog off: 2 of 9 runs wedged (one OpenArena, one ClassiCube). Watchdog on: 0 of 9 wedged. It caught 2 stalls (OpenArena, ClassiCube), restarted the DMA, and the sound kept going. Frame rate, 1% low and stalls equal: SuperTuxKart 21 and 20 fps, ClassiCube 48.4 in both, OpenArena 61.9 and 62.3.
`lean`	stall recorder at 10 ms	21	11.8	6	20	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	26.1	95.0	1.0	291.1	-	318.4	0	291.1	0.1	0	0.1	0	0.8
`lean`	stall recorder at 10 ms switch snd_dma_watchdog_ms0	20	11.7	5	19	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	29.2	96.0	0.6	126.1	-	323.5	0	126.1	0	0	0	0	0.6
batch ssdroot10 OpenAL wedge rate on SuperTuxKart lean x5 per arm: our openal-soft +ps3.549 (int16), stock +ps3.273 (LDPATH), ours with OAL=f32 (SSD root .472 Mesa ps3.545~dev) 2026-10-20 · `2026-10-20-ssdroot10-openal-wedge` Tested: Whether our OpenAL build makes the sound wedge more likely than Debian's, and whether float output avoids it: five SuperTuxKart runs per arm. Result: No: our build wedged in 2 of 5 runs and Debian's in 3 of 5 (an earlier 0 of 12 for Debian's was luck). The wedge is the sound driver's DMA stopping whatever OpenAL does, the job of the snd_ps3 DMA watchdog (kernel patch 0047). Float output's 0 of 5 is not significant at five runs. What we saw 15 runs rotated; one run with Debian's library was interfered by two logins and left out. Runs that wedged: ours 2 of 5, Debian's 3 of 5, ours with float output 0 of 5. Our build does not raise the rate; the earlier 0 of 12 for Debian's library was luck. Float output's 0 of 5 is not significant at 5 runs. Frame rate equal in all arms: 20-21 fps steady, 1% low 11.5-11.9.
`lean`	stall recorder at 10 ms	20	11.6	8	19	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	23.4	95.7	1.3	255.3	-	322.7	0	255.3	0.1	0.0	0.0	0	1.0
`lean`	stall recorder at 10 ms switch ldstock-openal	21.0	11.9	7.5	20.0	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	25.9	95.0	1.1	216.0	-	315.7	0.0	216.0	0.1	0.0	0.0	0.0	0.9
`lean`	stall recorder at 10 ms switch oalf32	20	11.5	9	20	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	21.4	95.9	1.1	157.8	-	313.2	0	157.8	0.1	0	0	0	0.8
batch ssdroot9 Mesa 0044: NV30_MINMAX_VMX=1 against unset on SuperTuxKart lean x5 (SSD root .472 Mesa ps3.545~dev) 2026-10-20 · `2026-10-20-ssdroot9-minmax-vmx` Tested: A larger repeat (five rounds) of Mesa 0044 (the AltiVec index scan) on SuperTuxKart, after the first test gave an indicative +5%. Result: A gain: 22 against 20 fps (+10%), 1% low 12.3 against 11.6, gameplay stalls halved (0.6 against 1.2 s) and a little less CPU. Marked a candidate default; no decision to turn it on is recorded. What we saw 10 runs rotated, 5 per arm, none interfered. Steady fps 22 with 0044 against 20 without (+10%). 1% low 12.3 against 11.6. Gameplay stalls 0.6 against 1.2 s. CPU 307 against 320 s.
`lean`	stall recorder at 10 ms	20	11.6	8	20	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	24.1	95.1	1.2	205.6	-	319.6	0	205.6	0.1	0	0.0	0	1.0
`lean`	stall recorder at 10 ms switch minmax_vmx1	22	12.3	5	21	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	27.8	95.9	0.6	143.7	-	307.4	0	143.7	0.0	0	0	0	0.5
batch ssdroot8 DUMPON=1 repro of the OpenAL wedge: SuperTuxKart x4 OpenArena x3 ClassiCube x3 (SSD root .472 Mesa ps3.545~dev, stock snd_ps3) 2026-10-20 · `2026-10-20-ssdroot8-openal-wedge` Tested: Another reproduction of the OpenAL wedge with system dumps, on SuperTuxKart, OpenArena and ClassiCube, with the stock snd_ps3 sound driver. Result: The real wedge (OpenAL waiting on a sound card that stopped) hit 3 of 10 runs: 2 of 4 SuperTuxKart, 0 of 3 OpenArena and 1 of 3 ClassiCube. In one, the card's position had stood still for a second before, as in the first count. The other dumps caught short underruns that recovered; investigation runs, not for comparison. What we saw Investigation runs, not for fps: a dump freezes the game for seconds. Only runs without a dump have numbers, not comparable with other batches. Webcam picture right in all 10; dumps in 8 of 10. SuperTuxKart: one run without a dump. A real wedge at 10.9 s in another, where the card's hardware position had stopped 1.0 s before (its DMA stopped). Two more dumps on a memory-map error at 30.6 and 33.1 s, one of which then wedged. OpenArena: three dumps at 20.5-33.4 s, all on a memory-map error, no wedge, the card still moving. ClassiCube: a dump at 2.9 s followed by a wedge; one clean run; one dump at 4.4 s with the card still moving. In total the wedge hit 3 of 10 runs; the other 5 dumps were underruns that recovered. Two SuperTuxKart runs lost their result and part of their game log, likely because a 164 MB core dump sat in RAM on a 256 MB console (not checked). They make no numbers.
`lean--`	stall recorder at 10 ms	-	-	-	19.5	Kernel ps3.472, Mesa ps3.545~dev	whole run	13.2	-	-	-	-	-	-	-	-	-	-	-	-
`lean`	stall recorder at 10 ms	20.5	11.7	6.0	20.0	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	23.0	95.5	0.8	142.2	-	320.3	0.0	142.2	0.0	0.0	0.0	0.0	0.7
batch ssdroot8 Mesa 0038 force-DXT on the rest of the suite: Luanti and ClassiCube off/opaque/opaque+NEAREST, OpenArena gl2min and gl2min_tc0 off/opaque, SuperTuxKart lean opaque/all (SSD root .472 Mesa ps3.545~dev) 2026-10-20 · `2026-10-20-ssdroot8-force-dxt` Tested: Whether Mesa 0038's forced texture compression (opaque textures to DXT1, or every texture with 'all') saves VRAM in the rest of the suite: Luanti, ClassiCube, OpenArena and SuperTuxKart. Result: Only SuperTuxKart with 'all' changed anything: 182 textures went to DXT5 and peak VRAM fell from 95.5 to 58.1 MiB (-39%) at the same frame rate, with no difference visible on the webcam. The other games compressed nothing, because their uploads are empty textures filled later, small, or in formats the switch skips. No decision recorded; the user has the last word on the picture. What we saw 24 runs, compression statistics on in every arm, none interfered, webcam picture right in all. Luanti: nothing compressed (every upload is an empty texture filled later). Peak VRAM 62.4 MiB off, 60.9 opaque, 61.9 opaque with nearest filtering; 46.5, 46.0 and 46.0 fps; stalls 3.3, 3.3 and 3.9 s; load about 25 s. Equal within the noise. ClassiCube: nothing compressed (textures under 64 px, or kept for nearest filtering or alpha). VRAM 60.1 MiB in every arm, 47.2-47.3 fps, no stalls. OpenArena opengl2: nothing compressed (formats the switch doesn't take). 61.8 fps off against 62.1 opaque, VRAM 114-117 MiB in both. With the game's own compression off, still nothing: 58.6 against 58.9 fps at 145-149 MiB. SuperTuxKart: opaque compresses nothing again (the game already compresses its opaque textures). 'all' takes 182 textures to DXT5 (52-53 MB sent as 13 MB). SuperTuxKart, opaque against all: peak VRAM 95.5 against 58.1 MiB (-37 MiB, -39%), 20 against 20.5 fps, 1% low 11.3 against 11.4, stalls 1.8 against 1.4 s, load 28.1 against 28.4 s. Free RAM 26-32 MiB in both: the saving is VRAM, not RAM. Picture: SuperTuxKart's photos with 'all' show the same track and kart, with no blockiness at the webcam's resolution. DXT5's loss on fine detail can't be judged by a webcam. OpenAL wedged in 9 of the 24 runs, in off arms too, without changing their fps.
`lean`	stall recorder at 10 ms switch force_dxtall_force_dxt_stats50	20.5	11.4	10.5	19.5	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	28.6	58.0	1.4	225.7	-	316.2	0.0	225.7	0.0	0.0	0.0	0.0	1.4
`lean`	stall recorder at 10 ms switch force_dxtopaque_force_dxt_stats50	20.0	11.2	12.0	20.0	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	28.1	95.5	1.8	309.8	-	316.6	0.0	309.8	0.1	0.0	0.0	0.0	1.6
batch ssdroot7 DUMPON=1 repro of the OpenAL wedge: SuperTuxKart x4 OpenArena x3 ClassiCube x3 Sauerbraten x3 (SSD root .472 Mesa ps3.545~dev) 2026-10-19 · `2026-10-19-ssdroot7-openal-wedge` Tested: How often OpenAL's sound output wedges (stops) in four games, with a full system dump taken the moment it happens, to find the cause. Result: The wedge hit 3 of 4 SuperTuxKart runs, 1 of 3 OpenArena, 1 of 3 ClassiCube and none of 3 BananaBread, as early as 21 s in. The dumps showed the sound card's DMA stopping in the kernel's snd_ps3 driver. Investigation runs: their numbers are not for comparison. What we saw Investigation runs, not for fps: a dump freezes the game for seconds, and the dump mode itself costs (OpenArena's window was 71 s at 57 fps against 94 s at 62 fps without it). Only the 8 of 13 runs without a dump have numbers, and they are not comparable with other batches. Webcam picture right in all 13 runs. Runs where OpenAL wedged: SuperTuxKart 3 of 4 (dumps at 48, 33 and 286 s), OpenArena 1 of 3 (at 21.6 s), ClassiCube 1 of 3 (at 103.6 s), BananaBread 0 of 3 (underruns 96-171). The dumped SuperTuxKart runs left no result; their counts come from the game log and they make no numbers. Finding from the dumps: the sound card's DMA stops (the snd_ps3 driver's interrupt chain).
`lean`	stall recorder at 10 ms	20	11.3	8	19	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	25.6	95.0	0.9	126.9	-	323.1	0	126.9	0.0	0	0.0	0	0.8
batch ssdroot7 Mesa 0044: NV30_MINMAX_VMX=1 against unset on SuperTuxKart lean x3 (SSD root .472 Mesa ps3.545~dev) 2026-10-19 · `2026-10-19-ssdroot7-minmax-vmx` Tested: Whether Mesa 0044 (AltiVec code for the min/max scan of index arrays, 6.5% of SuperTuxKart's profile) makes SuperTuxKart faster, three rounds. Result: Indicative +5%: 22 fps in every run with it against 19-21 without, but one fps is the HUD's resolution and the CPU time did not fall. Not proven; repeated with five rounds. What we saw 6 runs rotated, 3 per arm, none interfered, webcam picture right in all. Steady fps (Gallium HUD, whole numbers): unset 21, 19, 21; with 0044 22, 22, 22. Counted over the frames under 100 ms: 20.7 against 21.9 (+6%). 1% low 12.0 against 12.3. Gameplay stalls 6 frames (0.8 s) in both. CPU 305 s unset, 313 s with it: the expected 5% saving is not there. OpenAL's wedge showed in all 6 runs, badly in 3 (two unset, one with 0044). The badly wedged unset runs made 21 fps, so no sign that it costs frames. Load 28.1-28.4 s everywhere.
`lean`	stall recorder at 10 ms	21	12.0	6	20	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	24.4	94.6	0.8	231.5	-	305.2	0	231.5	0.1	0.0	0	0	0.6
`lean`	stall recorder at 10 ms switch minmax_vmx1	22	12.3	6	21	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	26.5	96.1	0.8	185.2	-	313.2	0	185.2	0.1	0	0.1	0	0.7
batch ssdroot6 libpng: libpng16 1.6.59 +ps3.560 against Debian's stock on SuperTuxKart lean x3 and Sauerbraten base x3 and OpenArena gl2min x2 (SSD root .472 Mesa ps3.545~dev zlib-ng on both arms) 2026-10-19 · `2026-10-19-ssdroot6-libpng` Tested: Whether our libpng (1.6.59 +ps3.560) cuts load times against Debian's, mainly on SuperTuxKart, whose load profile showed 4 s of PNG decoding; BananaBread and OpenArena as controls, zlib-ng on in both arms. Result: Yes for SuperTuxKart: PNG decoding in the load fell from 4.0 to 1.6 s (-60%, as predicted) and the whole load from 30.3 to 27.6 s (-9%), with gameplay unchanged. Nothing measurable for BananaBread and OpenArena. Our libpng later replaced Debian's on the PS3. What we saw Webcam picture right in all runs. SuperTuxKart, 3 rounds: round 1 was interfered (a login and mouse moves) and left out, so 2 runs per arm. SuperTuxKart's PNG decoding in the load: 4.0 s with Debian's library against 1.6 s with ours (-2.4 s, -60%). The zlib part stays 3.4 s in both. SuperTuxKart's load: 30.3 s against 27.6 s (-2.8 s, -9%). The main thread's CPU over the load: 24.0 against 21.1-21.7 s. SuperTuxKart gameplay unchanged: 20 against 19.5 fps (HUD), 1% low 11.9 against 11.5, 10 frames over 100 ms in both. One SuperTuxKart run with Debian's library aborted after the full race; cause not looked at. BananaBread: load 7.19 against 7.25 s, 39.5 fps in both. libpng is too small a part of its load to show. OpenArena (control, 2 runs): load 6.80 against 6.62 s, 63.1 against 61.1 fps (noise). CPU 231-241 s with Debian's libraries against 211 s with ours, not explained. OpenAL's wedge messages (its sound output stalling) showed in 8 of the 10 SuperTuxKart runs of this and the previous batch, in both arms.
`lean`	stall recorder at 10 ms start-up profile switch zng	19.5	11.5	10.0	19.5	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	19.8	95.4	1.2	172.6	-	320.4	0.0	172.6	0.1	0.0	0.0	0.0	1.1
`lean`	stall recorder at 10 ms start-up profile switch zng switch ldstock-png	20.0	11.8	10.5	19.5	Kernel ps3.472, Mesa ps3.545~dev	warm-up + 120 s	27.3	95.7	1.4	198.8	-	322.5	0.0	198.8	0.1	0.0	0.0	0.0	1.2
batch ssdroot5 load-time libraries: libvorbis +ps3.549 and zlib-ng against stock on SuperTuxKart lean and Sauerbraten base x3, JSIMD=none x2 (SSD root .472 Mesa ps3.544) 2026-10-19 · `2026-10-19-ssdroot5-load-libraries` Tested: Whether our libvorbis (+ps3.549) and zlib-ng shorten load times against Debian's libraries, on SuperTuxKart and BananaBread, three rounds; plus two runs with libjpeg-turbo's AltiVec code turned off to see whether it is in use. Result: Small gains on SuperTuxKart's load: 0.7 s from libvorbis and 0.9 s from zlib-ng. BananaBread's load and all frame rates were unchanged. Both libraries became defaults later (our libvorbis replaces Debian's; zlib-ng is loaded for every game), and the AltiVec test showed libjpeg-turbo's AltiVec path is in use. What we saw Load-time profiling on, 22 runs. SuperTuxKart load: 31.5 s with our libvorbis against 32.2 s with Debian's (-0.7 s); 30.6 s with zlib-ng (-0.9 s). SuperTuxKart with libjpeg-turbo's AltiVec code off: 32.6 s (+1 s), so that code is in use. BananaBread's load unchanged within the spread (8.4, 7.5 and 8.1 s). Gameplay frame rates unchanged.
`lean`	stall recorder at 10 ms start-up profile	21	11.9	6	20	Kernel ps3.472, Mesa ps3.544	warm-up + 120 s	27.9	95.9	0.8	151.8	-	321.9	0	151.8	0	0	0.1	0	0.7
`lean`	stall recorder at 10 ms start-up profile switch jsimdnone	20.5	11.9	8.5	20.0	Kernel ps3.472, Mesa ps3.544	warm-up + 120 s	31.0	95.4	1.4	442.6	-	321.4	0.0	442.6	0.1	0.0	0.2	0.0	1.0
`lean`	stall recorder at 10 ms start-up profile switch ldstock-vorbis	21	12.0	5	20	Kernel ps3.472, Mesa ps3.544	warm-up + 120 s	25.4	96.1	1.2	427.2	-	320.5	0	427.2	0.1	0	0.3	0	0.6
`lean`	stall recorder at 10 ms start-up profile switch zng	20	11.7	7	20	Kernel ps3.472, Mesa ps3.544	warm-up + 120 s	24.9	95.9	0.8	141.2	-	325.4	0	141.2	0.1	0	0	0	0.8
batch ssdroot2 P2: Mesa 0038 NV30_FORCE_DXT=opaque against off (MEM=1 STALLS=1 NV30_FORCE_DXT_STATS=50) 2026-10-19 · `2026-10-19-ssdroot2-force-dxt` Tested: Mesa 0038, a switch that compresses opaque textures to DXT on upload to save VRAM, against off on BananaBread, SuperTuxKart and OpenArena. Result: In BananaBread it cuts peak VRAM from 119.8 MB (the cap) to 73-78 MB with no frame rate change and a slightly softer picture. It compresses nothing in SuperTuxKart and OpenArena, whose textures it skips, so no effect there. What we saw Same boot, two runs per arm interleaved, both arms with the compression statistics on. BananaBread: 73 textures compressed (88 MB raw to 11 MB stored, all DXT1; 4 turned back, 17 skipped for alpha). Peak VRAM 119.8 MB (the cap) to 73-78 MB. GPU buffers at mid-run 351 to 215 MB. Memory in use -3.5 MB. BananaBread steady 39.9 fps off against 39.0 on (unprofiled baseline runs span 39.1-40.3, so no fps change resolved). 1% low 26.0 against 23.9 (two runs, spread 22.9-26.2). Stalls 0.5 against 0.55 s. BananaBread's picture is slightly softer and darker on the webcam (grey difference 10, against 1-2 between repeats): lossy, as expected. SuperTuxKart lean: nothing compressed (182 textures skipped for alpha, 173 for format, 22 too small, 6 non-power-of-two; the game's own compression already covers its opaque ones). VRAM 98.5 against 97.3 MB, HUD 20 against 21 fps, stalls 2.8 against 1.7 s: noise. OpenArena OpenGL 2: nothing compressed (2238 uploads in formats the switch does not take). VRAM 120.1 against 119.7 MB, steady 56.3 against 55.8: no effect. OpenArena ran 56 fps in both arms against 60-63 unprofiled earlier the same boot: the statistics or drift, not separated.
`lean`	stall recorder at 10 ms switch force_dxt_stats50	20.0	10.6	17.5	19.5	-	warm-up + 120 s	27.6	96.2	2.8	480.2	-	323.1	0.0	480.2	0.2	0.0	0.2	0.0	2.4
`lean`	stall recorder at 10 ms switch force_dxtopaque_force_dxt_stats50	21.0	11.6	11.5	20.0	-	warm-up + 120 s	24.6	95.0	1.7	385.5	-	318.3	0.0	385.5	0.1	0.0	0.3	0.0	1.3
batch ssdroot2 P1b: gameplay profiles on the SSD root (PERF=1 MEM=1 x1) 2026-10-19 · `2026-10-19-ssdroot2-gameplay-profiles` Tested: Where the CPU goes during play in seven games on the SSD root, profiled with perf over the measured window. Result: Mesa is the biggest share in BananaBread (62.8%) and ClassiCube, the game itself in SuperTuxKart, OpenArena and Luanti, and OpenTTD spends half its time in the kernel. Profiled runs, not for frame rates; OpenTTD was profiled at its title screen, not in play. What we saw Same boot, one run per game, perf at 499 Hz over the window. Profiled runs are for profiles, not fps (OpenArena 56 against 60 unprofiled). Share of the game process's samples: BananaBread: Mesa 62.8%, the GPU kernel driver 4.8, the game 10.5. ClassiCube: Mesa 41.2, kernel 20.1, the GPU kernel driver 7.1. SuperTuxKart: the game 36.5, Mesa 35.5, libc 15.1. OpenArena: the game 27.6, Mesa 23.1, other 20.4 (OpenAL 12.4, libdeflate 3.9). Luanti: the game 47.2 (its mesh-update thread 20.7% of all samples), Mesa 14.6, libc 13.7. dsda-doom: Mesa 22.3, the game 20.5, audio 30 (FluidSynth 15, libspeq 12). OpenTTD: kernel 49.5 (36.7 replaying deferred interrupts, 8.3 page table invalidation, 5.1 clearing GPU memory mappings when buffers are created), audio 17. It ran at its title screen (a menu, not gameplay: 18 fps, 4172 underruns). Mesa has no symbols in these profiles (to be resolved on the PC later). SuperTuxKart's fps is the HUD's. not comparable gameplay profiles (PERF=1 MEM=1), slower than plain runs.
`lean` not comparable	perf recording	20	10.8	20	20	-	warm-up + 120 s	22.9	94.5	2.7	316.8	-	322.5	0	316.8	-	-	-	-	-
batch ssdroot2 P1a: start-up profiles on the SSD root (PERF_LOAD=1 STALLS=1 x1) 2026-10-19 · `2026-10-19-ssdroot2-startup-profiles` Tested: Where the start-up time goes now that the system runs from the SSD: one profiled start of each of five games, from a cold cache. Result: Loads are 39-61% shorter than on USB and are now mostly CPU work on the main thread (47-77%), with the disk only 13-26%. The biggest remaining costs are named per game (map inflate, PNG and zlib decoding, Luanti's map generation). Profiled runs, not for frame rates. What we saw Same boot as the SSD baseline, cold page cache, one run per game. Time to the end of the loading screens, against the USB profiles of batch 17: BananaBread 7.7 s (19.8), OpenArena 14.2 (28.1), Luanti 26.1 (43.1), SuperTuxKart 31.5 (54.3), ClassiCube 7.5 (13.9). That is -39 to -61%. The main thread's disk wait in the load fell from 4.8-18.6 s to 1.0-3.2 s (BananaBread 1.9, OpenArena 2.1, Luanti 3.0, SuperTuxKart 3.2, ClassiCube 1.0). The main thread's CPU stayed about the same (BananaBread 3.9 s against 4.1, OpenArena 8.7 against 9.0, SuperTuxKart 23.8 against 22.5, ClassiCube 3.2 against 2.9). So loads are now 47-77% CPU on the main thread, not fully CPU-bound: disk 13-26%, the rest GPU, memory reclaim, waiting to run and sleeps. Biggest costs now: BananaBread zlib 1.6 s (inflating the map); OpenArena the game's own load path 3.9 s (shader scripts, mipmaps); Luanti map generation 8.6 s plus a 15 s hold; SuperTuxKart PNG 4.2, zlib 3.9, audio 2.2 and JPEG 2.1 s; ClassiCube the game 1.5 s and the dynamic linker 0.6 s. Profiled runs are for profiles, not fps. not comparable start-up profiles (PERF_LOAD=1 STALLS=1), slower than plain runs.
`lean` not comparable	stall recorder at 10 ms start-up profile	21	12.0	5	20	-	warm-up + 120 s	23.5	95.7	0.6	151.3	-	316.1	0	151.3	0	0	0	0	0.6
batch ssdroot1+2 A: baseline on the SSD root (kernel .472 Mesa .476 ps3rsx 0.443 ps3-gpu-tools 0.477~dev) 2026-10-19 · `2026-10-19-ssdroot1-baseline` Tested: A new baseline with the whole system running from the internal SSD instead of a USB disk, on five games, to see what it does to loads, stalls and frame rates. This console has an upgraded SSD; a stock PS3 has a hard disk. Result: Loads are 35-58% shorter (BananaBread 16.9 to 7.1 s, SuperTuxKart 53.6 to 31.1 s) and BananaBread's gameplay stalls almost vanish, while frame rates stay about the same apart from OpenArena (55.9 to 60.4). It also showed SuperTuxKart's own "Average FPS" is its physics tick rate, so its fps is taken from the HUD from here on. What we saw Same boot, kernel 6.12.111+ps3.472, root on the internal SSD (an upgraded SSD; a stock PS3 has a hard disk). 5 of 17 runs left out as interfered (SSH logins, a key press, a polling loop at the batch switch). Load against the USB root (other boots, older Mesa for some games): BananaBread 7.1 s against 16.9, OpenArena 6.9 against 10.7, Luanti 25.0 against 40.8, SuperTuxKart 31.1 against 53.6, ClassiCube 7.6 against 14.2. The load's disk wait: 1.3-3.4 s against 5.5-10.9 s. Gameplay stalls: BananaBread 0.05 s against 1.6, OpenArena 0.2 against 0.3, Luanti 3.5 against 2.5 (memory reclaim 1.6 s against 0.4), SuperTuxKart 0.2 s (one run). Steady fps about the same: BananaBread 39.1 against 38.5, Luanti 46 against 46, SuperTuxKart 22 (HUD) against 20, ClassiCube 48.1 against 45.9 (falling to 46.1 later in the session with nothing changed). OpenArena gained: 60.4 against 55.9. SuperTuxKart's own 'Average FPS' (105-111) is its physics tick rate (120 Hz for 180 s, 21602 ticks in every run), not rendered frames. Its fps cells are the HUD median from now on. Photos show the right scenes. Luanti's photos at 60 and 150 s fall on the flight path's turn over the sea (cyan, no terrain), because the load is shorter than on USB: not a missing world. Microphone: OpenArena audible; the other games mostly at the room-hum level.
`lean`	stall recorder at 10 ms	22	12.8	2	21	Kernel ps3.472, Mesa ps3.476, ps3rsx 0.443	warm-up + 120 s	25.1	94.8	0.2	108.3	-	308.3	0	108.3	0	0	0	0	0.2
batch 17: ETR uncapped, start-up profiles x5, shader cache cold/warm, OpenArena gl2 memory variants, Mesa sysmem switches, Sauerbraten shortnormals 2026-10-18 · `2026-10-18-batch17` Tested: A mixed batch: ioquake3 462's new colour path and memory variants for OpenArena's OpenGL 2 renderer, Mesa's system-memory copy switches, BananaBread's short normals, a warm shader cache, Extreme Tux Racer without a frame cap, and start-up profiles. Result: ioquake3 462 cuts OpenArena's stalls from 9-11 s to 0.7-2.6 s at 57-60 fps, Mesa's system-memory switches fix the old colour path's stalls, and BananaBread's short normals give +17%. The shader cache gives no faster loads and Extreme Tux Racer's 59 fps is not a vsync cap. What we saw Same boot as batch 16 (kernel .433), ioquake3 462, Mesa 442~dev, cube2 442~dev. One BananaBread run with a key press left out. OpenArena OpenGL 2 on ioquake3 462 (compact colours by default): steady 57-60 fps, stalls 0.7-2.6 s. On the 396 build in batch 16: 51-53 fps and 9-11 s. The old 16-bit colour path: 52-53 fps, 12.9 s of stalls, 20 s of swap stalls. Packed animated model frames: 20 MB less VRAM, same stalls. Gamma-correct mipmaps computed per channel: the lowest stalls (0.7-0.9 s). Mesa's system-memory copy plus buffer invalidation on the old colour path: stalls 9.9 and 12.3 s to 1.5 and 1.4 s, swap stalls 20-26 s to 0.6-1.1 s, steady 53-54 to 59 fps. BananaBread with short normals: 38.7 to 45.4 fps (+17%), stalls equal, VRAM +4 MB. Shader cache cold against warm: no load gain (OpenArena 10.3 s cold, 10.6 s warm; BananaBread 17.4 against 18.4 s). Extreme Tux Racer without a frame cap: still 59 fps, so not a vsync cap.
`lean`	stall recorder at 10 ms start-up profile	19	11.5	8	19	-	warm-up + 120 s	22.5	96.1	2.0	691.2	-	335.3	0	691.2	0.4	0.0	0	0	0.7
batch 16: game prefetch A/B, idle fix on/off (433), ClassiCube chunks1, X-Moto stream, Luanti lean parts 2026-10-18 · `2026-10-18-batch16` Tested: Several checks on kernel .433: a game-data prefetch, the idle-CPU fix on and off, ClassiCube's chunk setting, X-Moto's streaming draw path, and the parts of Luanti's lean settings one at a time. Result: The prefetch gives no gain and makes Luanti worse, so it was turned off by default. The idle fix is confirmed clean (gameplay stalls 0.4 s against 8-9 s); ClassiCube's chunk setting gains 4.7% and X-Moto's streaming 1%. Luanti's chunk size 3 is what empties the world in lean. What we saw Same boot, kernel .433 with the idle fix and no kicker, interference detector on (3 runs disturbed by SSH logins left out). Prefetch against none, three runs each: no gain. BananaBread load 18.1-18.6 s against 15.2-18.8; OpenArena OpenGL 2 about 0.5 s faster; Luanti worse (load +1-4 s, two runs with 3 s hitches). Default turned off. Idle fix on and off, two runs each: gameplay stall time 0.4 and 0.4 s against 9.0 and 7.9 s, longest frame 0.22-0.38 s against 2.2-2.8 s. Clean. ClassiCube's alternative chunk drawing: 48.1 fps against 46.0 (+4.7%). X-Moto with its streaming draw path: 162.1 against 160.6 (+1%). Luanti with chunk size 3 renders a black void at 150 s: it is the part of lean that empties the world. Server unloading and active block range 2 render, but stall more (6.3 and 6.7 s against about 2.5).
`lean`	gpflearn	21	12.1	6	20	-	warm-up + 120 s	26.7	95.9	1.3	432.6	-	331.1	0	432.6	-	-	-	-	-
`lean`	stall recorder at 10 ms	20	11.4	7	19	-	warm-up + 120 s	23.9	95.2	1.8	686.1	-	330.8	0	686.1	0.4	0.0	0	0	0.7
`lean`	stall recorder at 10 ms switch gpffetch	20	11.5	12	20	-	warm-up + 120 s	24.4	96.1	2.7	682.4	-	330.6	0	682.4	0.5	0.0	0	0	1.1
batch 8: STK lean, OpenTTD gl, ClassiCube/dsda batching, malloc presets, profiles (Mesa ps3.408, kick) 2026-10-18 · `2026-10-18-batch8` Tested: A mixed batch: SuperTuxKart's lean settings, OpenTTD's OpenGL driver, draw batching in ClassiCube and dsda-doom, memory allocator presets, and profiles of OpenArena and Luanti. Result: SuperTuxKart lean runs 21.4 fps against 13 with far fewer stalls, OpenTTD's GL driver doubles its frame rate, dsda-doom's batching gains 3% while ClassiCube's loses 4%, and the allocator presets were noise. One Luanti profiling run was disturbed by a mouse click. What we saw Same boot. SuperTuxKart: the track draws (webcam). Lean settings 21.4 fps smooth against 13 as built, stalls 2.4 against 13.5 s. OpenTTD with the GL driver: right picture, 21 fps (8-12 with software drawing). ClassiCube with batching 47.3 fps against 49.4 with the old drawing (-4%), but 1% low 31 against 27.6. dsda-doom GL renderer with batching 55.9 against 54.2 (+3%), 1% low 40.8 against 36.5. Memory allocator presets: inconsistent between rounds (noise). OpenArena OpenGL 2 renderer: 55 s of stalls, longest 16 s, 66 MB swapped out. Luanti: 10 s of stalls, 51 MB swapped out. Interference (found by the later scan): the profiled Luanti run had a right click in its measured window, so distrust that cell.
`base`	waker kick at 10 ms	12	8.4	113	12	Mesa ps3.408	warm-up + 120 s	24.4	129.7	13.5	675.6	-	412.3	0	675.6	-	-	-	-	-
`lean`	waker kick at 10 ms	21	12.2	8	21	Mesa ps3.408	warm-up + 120 s	18.5	95.7	2.4	663.4	-	318.1	0	663.4	-	-	-	-	-
`lean`	waker kick at 10 ms perf recording	20	10.8	15	20	Mesa ps3.408	warm-up + 120 s	27.6	95.0	3.4	576.3	-	325.4	0	576.3	-	-	-	-	-
Group 4 smokes (Mesa ps3.246 + ps3rsx 0.249) 2026-10-17 · `2026-10-17-group4-smokes` Tested: First runs of the heavy games with the VRAM swap on: OpenArena's OpenGL 2 renderer with two settings, SuperTuxKart, and BananaBread with GPU and with CPU skinning. Result: The heavy games are memory-bound, with no driver bug in sight: OpenArena's OpenGL 2 renderer made 10.7 to 13.6 fps with single stalls of 28.3 and 36.3 s. SuperTuxKart refused to start on a big-endian machine, and BananaBread's GPU skinning was far slower than CPU skinning. What we saw OpenArena, OpenGL 2 renderer with minimal settings (97 shader programs): the first launch hit the 90 s cap before the level loaded. The rerun with 240 s: 13.6 fps average, one 36.3 s stall, 31 fps on the driver's frame counter, 157.8 MB VRAM, free memory down to 9.8 MB. The same with Debian's defaults (115 programs): 10.7 fps, a 28.3 s stall, 23 fps on the counter, 159.7 MB VRAM. Picture right on the webcam, no driver bug seen: the game is memory-bound. SuperTuxKart quit after 29 s with a fatal error: "SPMeshLoader: Not little endian machine" (a model file). BananaBread with GPU skinning ran to the 170 s cap with 0 on the counter and no fps line (the game plan has 11 fps by its own counter, against 28 for CPU skinning). BananaBread with CPU skinning: 19.6 fps over 601 frames, longest frame 380 ms, 135 MB VRAM, load 27 s. Single runs.
`base`	the recipe as it is	-	-	-	-	Mesa ps3.246, ps3rsx 0.249	whole run	48.9	100.0	-	-	-	13.8	0	-	-	-	-	-	-