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
The platform builds under it (3)
| Linux kernel | 6.12.111+ps3.747 Walnut's build |
|---|---|
| Mesa | 26.2.4-1+ps3.721 Walnut's build |
| ps3rsx | 0.735+k6.12.111+ps3.747 Walnut's build |
| Date | Launcher | Game build | Rules | Play | Ended | Picture | |
|---|---|---|---|---|---|---|---|
| 2026-10-24 | X-Moto | xmoto 0.6.3+repack-1+ps3.788 | 1.0 | 26 min | quit | ok | Details |
| 2026-10-23 | X-Moto | xmoto 0.6.3+repack-1+ps3.721 | 1.0 | 1 min | quit | ok | Details |
| 2026-10-23 | X-Moto | xmoto 0.6.3+repack-1+ps3.721 | 1.0 | 6 min | quit | ok | 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 | Display | Load | Play |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Walnut 0.1 xmoto 0.6.3+repack-1 |
2026-10-24 from 2026-10-23 |
Platinum · 96 | 1.0 | 98 | 89 | 98 | 100 | 91 | - | 99 | 0.4 h 3 tests |
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: X-Moto 0.6.3: replays the "credits" replay with --timedemo --benchmark, fullscreen 1920x1080, no network.
The recipe's full description
X-Moto 0.6.3: replays the "credits" replay (shipped inside xmoto.bin, which --replay doesn't read: assets/xmoto-credits.rpl is it, extracted, MD5 05a7200d...) with --timedemo --benchmark (draws every frame, prints the average and exits), fullscreen 1920x1080, no network. It sets no swap interval itself: vblank_mode=0. The replay runs in real time (physics steps by the wall clock; --timedemo only lifts the frame cap): ~144 s, so runs before 2026-10-17's steady state (cut at 90 s) never printed the average. Steady state: passes. Our patch 0003 (StateReplaying::update, at the benchmark end) with XMOTO_BENCH_LOOPS=N plays the replay N times (a new StatePreplayingReplay instead of closing), printing the lines each pass. Two passes (~300 s with the reloads): the first is the warm-up, the second (~144 s, starts after 0.9 x 60 s) is counted and covers the 120 s. fps= is the first pass's.
The recipe today runs it at 1920x1080, with vblank_mode=0 XMOTO_BENCH_LOOPS=2 (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).
10 variants of the recipe
base stands for the game | the recipe as it is, without a variant |
|---|---|
autooff | Mesa ps3.299 switches, to bisect its cost here: 0027 (adaptive submission) off, 0030 (index upload) off |
idxoff | - |
glstats | our xmoto (gamedb/games/xmoto/packages/xmoto/, +ps3.N): DrawLib's primitives batched and the GL state set only when drawing (XMOTO_GL_BATCH), the level's blocks and edges from one buffer (XMOTO_GL_BLOCKS); base has both. Draws, vertices and syncs per frame every 5 s on stderr (game.log): |
nobatch | Debian's drawing: glBegin/glEnd, a draw per block polygon (~1960 draws a frame) |
noblocks | batching only, the blocks polygon by polygon (~1000 draws a frame, ~40 with base) |
fpvram | 0031 (fragment programs from GART after a constant change) off; 0028 (index buffer fenced) off |
idxlate | - |
stream | our xmoto 0004 (docs/HOTPATHS.md, target 3): the batches written straight into a mapped stream buffer instead of client memory that Mesa copies at every draw (u_upload_data's memcpy, 5.5% of the CPU, the minimap's circles most of it); the same vertices and draws. streamstats counts its buffer renewals too |
streamstats | - |
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 | Resolution | 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. | ||||||||||||||||||||||
| X-Moto | the recipe as it is | 160.7 | 106.7 | - | - | - | 1920x1080 | warm-up + 120 s | 51 | 37 | 0.0 | 43 | 0 | - | - | - | - | - | - | - | - | right, right |
Real-time audio as shipped: ps3-desktop 0.1013 (limits.d rtprio 10 + ps3-rt-audio, RTAUDIO=1) against none (RTPRIO=0) on dsda-doom software (owncfg), Extreme Tux Racer, X-Moto and Neverball (kernel .874)
2026-10-28 · 2026-10-28-rt-audio-shipped
Tested: Real-time audio as shipped in ps3-desktop 0.1013 (a priority limit plus ps3-rt-audio, which game mode uses to put the game's audio thread on SCHED_RR), against none, on dsda-doom, Extreme Tux Racer, X-Moto and Neverball. Result: Shipped. Audible dropouts a run fell from 29 to 2 in dsda-doom, 26 to 2 in Extreme Tux Racer and 3 to 0 in Neverball, with steady fps unchanged within 0.4%. The 1% lows came out a little lower in the light games, with the ranges touching. What we saw25 runs in three rounds, games interleaved, arm order alternating. Two Neverball runs with it were interfered by the agent's own SSH checks and left out, so Neverball has 2 runs with it. Every run fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.
| ||||||||||||||||||||||
base |
rtaudio | 161.0 | 110.9 | 0 | 159.2 | - | 1920x1080 | warm-up + 120 s | 56.0 | 37.3 | 0.0 | 26.1 | - | 306.9 | 11 | 249.1 | - | - | - | - | - | |
base |
real-time priority 0 | 161.7 | 116.9 | 0 | 160.2 | - | 1920x1080 | warm-up + 120 s | 64.6 | 37.3 | 0.0 | 19.2 | - | 306.4 | 78 | 248.8 | - | - | - | - | - | |
batch ssdroot2 P2: ps3rsx shadow_fast (PS3RSX_SHADOW_FAST=1 against off, STALLS=1)
2026-10-19 · 2026-10-19-ssdroot2-shadow-fast
Tested: A faster path in the ps3rsx kernel driver for copying GPU commands (shadow_fast), switched on and off on ClassiCube, BananaBread and X-Moto. Result: No gain in frame rate, stalls or CPU on any of the three games, so the switch stays off. The code it touches is only 2-6% of the CPU in the first place. What we saw
| ||||||||||||||||||||||
base |
stall recorder at 10 ms | 158.4 | 98.1 | 0.0 | 158.0 | - | 1920x1080 | warm-up + 120 s | 48.0 | 37.3 | 0.0 | 43.8 | - | 303.5 | 206.5 | 264.5 | 0.0 | 0.0 | 0.0 | 0.0 | 0.2 | |
base |
stall recorder at 10 ms switch rsx_shadow_fast1 |
159.0 | 97.4 | 0.0 | 158.9 | - | 1920x1080 | warm-up + 120 s | 46.6 | 37.2 | 0.0 | 58.6 | - | 301.1 | 209.0 | 250.6 | 0.1 | 0.0 | 0.0 | 0.0 | 0.2 | |
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
| ||||||||||||||||||||||
base |
the recipe as it is | 160.7 | 106.7 | 0 | 160.0 | - | 1920x1080 | warm-up + 120 s | 51.0 | 37.3 | 0.0 | 42.9 | - | 299.4 | 148 | 693.0 | - | - | - | - | - | |
stream |
XMOTO_GL_STREAM=1 | 162.1 | 106.3 | 1.0 | 161.9 | - | 1920x1080 | warm-up + 120 s | 49.3 | 37.2 | 0.4 | 380.4 | - | 290.2 | 129.5 | 380.4 | - | - | - | - | - | |
Mesa ps3.416~dev hot spots (staging pool, query wait), cube2 355 oqlag, xmoto 362 stream, ClassiCube chunks1 (kick)
2026-10-18 · 2026-10-18-mesa-416-hot-spots
Tested: Fixes for driver hot spots in Mesa ps3.416 (a staging buffer pool, a cap on waiting for occlusion queries) and game-side changes: BananaBread's lagged water occlusion queries, X-Moto's streaming draw path and ClassiCube's chunk setting. Result: ClassiCube's chunk setting gains 5% and X-Moto's streaming shortens the worst frame; the staging pool saves 4% CPU at the same frame rate. BananaBread's big jump with the query wait cap was a single run and did not hold up in the repeat. What we saw
| ||||||||||||||||||||||
base |
waker kick at 10 ms | 160.4 | 100.4 | 1 | 160.4 | Mesa ps3.416~dev | 1920x1080 | warm-up + 120 s | 52.8 | 37.3 | 0.4 | 403.7 | - | 298.0 | 104 | 713.9 | - | - | - | - | - | |
stream |
XMOTO_GL_STREAM=1 waker kick at 10 ms |
163.1 | 107.8 | 1 | 162.9 | Mesa ps3.416~dev | 1920x1080 | warm-up + 120 s | 47.3 | 37.4 | 0.1 | 145.8 | - | 282.2 | 103 | 675.6 | - | - | - | - | - | |
xmoto ps3.323 + etr ps3.324 (game-side batching) + Mesa ps3.299
2026-10-17 · 2026-10-17-xmoto-etr-batching
Tested: Our X-Moto and Extreme Tux Racer packages with the game's drawing batched into far fewer OpenGL calls and draws per frame. Result: A large win: X-Moto went from 44.5 to 166.5 fps with the same picture, and Extreme Tux Racer from 52 to 59 fps. What we saw
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 166.5 | Mesa ps3.299 | 1920x1080 | whole run | 54.8 | 37.2 | - | - | - | 72.7 | 29.0 | - | - | - | - | - | - | |
nobatch |
XMOTO_GL_BATCH=0 | - | - | - | 44.5 | Mesa ps3.299 | 1920x1080 | whole run | 53.1 | 36.3 | - | - | - | 87.1 | 32.0 | - | - | - | - | - | - | |
Mesa ps3.282 A/B on the ps3.299 boot
2026-10-17 · 2026-10-17-mesa-282-ab
Tested: Mesa ps3.282 reinstalled on the Mesa ps3.299 boot, as the same-boot comparison for X-Moto and ClassiCube. Result: X-Moto runs 47.0 fps and ClassiCube 46.9 on ps3.282, the reference that shows X-Moto's 5% loss on ps3.299 is real and ClassiCube's difference is noise. What we sawSame boot as the Mesa ps3.299 batch, with Mesa ps3.282 reinstalled. Two runs each: X-Moto 47.0 fps, ClassiCube 46.9. | ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 47.0 | Mesa ps3.282 | 1920x1080 | whole run | 52.8 | 36.3 | - | - | - | 86.2 | 26.5 | - | - | - | - | - | - | |
Mesa ps3.299 + ps3rsx 0.249
2026-10-17 · 2026-10-17-mesa-299
Tested: Mesa ps3.299, the third round of driver changes: adaptive submission (0027), a fenced index buffer (0028), state reset (0029), index upload (0030) and fragment-program constants read from system memory (0031). Result: Armagetron gets its frame rate back (50 to 61.5 fps), OpenArena and ClassiCube are unchanged, and X-Moto loses a real 5% that none of the switches fully restores. The picture was right and the driver tests passed. What we saw
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 46.0 | Mesa ps3.299, ps3rsx 0.249 | 1920x1080 | whole run | 51.4 | 36.3 | - | - | - | 84.0 | 33.5 | - | - | - | - | - | - | |
autooff |
NV30_PS3_KICK_AUTO=0 | - | - | - | 45.5 | Mesa ps3.299, ps3rsx 0.249 | 1920x1080 | whole run | 47.6 | 36.3 | - | - | - | 80.1 | 108.5 | - | - | - | - | - | - | |
fpvram |
NV30_FP_CONST_VRAM=1 | - | - | - | 46.0 | Mesa ps3.299, ps3rsx 0.249 | 1920x1080 | whole run | 54.7 | 36.4 | - | - | - | 85.9 | 28.0 | - | - | - | - | - | - | |
idxlate |
NV30_IDXBUF_LATE_REF=1 | - | - | - | 46.0 | Mesa ps3.299, ps3rsx 0.249 | 1920x1080 | whole run | 57.6 | 36.3 | - | - | - | 85.4 | 26.5 | - | - | - | - | - | - | |
idxoff |
NV30_INDEX_UPLOAD=0 | - | - | - | 45.0 | Mesa ps3.299, ps3rsx 0.249 | 1920x1080 | whole run | 46.3 | 36.2 | - | - | - | 80.7 | 112.5 | - | - | - | - | - | - | |
Mesa ps3.282 + ps3rsx 0.249: kick100 against base in OpenArena X-Moto ClassiCube
2026-10-17 · 2026-10-17-mesa-282-kick100
Tested: Whether submitting work to the GPU every 100 draws, which restored Armagetron's frame rate, also helps or hurts OpenArena, X-Moto and ClassiCube. Result: No fixed number of draws suits every game: it gains OpenArena 3%, costs X-Moto 9% and leaves ClassiCube flat but with 9% more CPU. The adaptive submission of Mesa ps3.299 (0027) followed; why X-Moto loses is not established. What we saw
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 47.5 | Mesa ps3.282, ps3rsx 0.249 | 1920x1080 | whole run | 55.8 | 36.2 | - | - | - | 88.8 | 32.5 | - | - | - | - | - | - | |
kick100 |
the recipe as it is | - | - | - | 43.0 | Mesa ps3.282, ps3rsx 0.249 | 1920x1080 | whole run | 54.0 | 36.3 | - | - | - | 88.9 | 25.5 | - | - | - | - | - | - | |
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
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 47 | Mesa ps3.262, ps3rsx 0.249 | 1920x1080 | whole run | 56.7 | 36.3 | - | - | - | 89.6 | 42 | - | - | - | - | - | - | |
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
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 39 | Mesa ps3.246, ps3rsx 0.249 | 1920x1080 | whole run | 70.9 | 36.4 | - | - | - | 83.8 | 45 | - | - | - | - | - | - | |
Mesa ps3.246 + ps3rsx 0.219
2026-10-17 · 2026-10-17-mesa-246
Tested: Mesa ps3.246 (patches 0015 to 0017: less fence bookkeeping per draw, the same commands to the GPU), before the reboot into ps3rsx 0.249. Result: A small gain: X-Moto 37 fps against 35 on ps3.223, ClassiCube 44.9 against 43.2 on ps3.225, and every GL test passes. OpenTTD with libsdl3 +ps3.242 had the right colours but 2 fps, because each frame was converted on the CPU twice. Single runs. What we saw
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 37 | Mesa ps3.246, ps3rsx 0.219 | 1920x1080 | whole run | 70.8 | 36.3 | - | - | - | 86.1 | 126 | - | - | - | - | - | - | |
Mesa ps3.223 + ps3rsx 0.219
2026-10-16 · 2026-10-16-mesa-223
Tested: Where the CPU time goes in five games on Mesa ps3.223, each profiled for 15 s. Result: The driver stack, not the games, takes most of the CPU: Mesa 28 to 56%, ps3rsx 6 to 16%. That started the per-draw work in Mesa ps3.246 and ps3.262 and ps3rsx 0.249. The profiler slowed the runs, so the fps are not for comparison. What we saw
not comparable every game was profiled with perf during the run, which slows it. | ||||||||||||||||||||||
basenot comparable |
the recipe as it is | - | - | - | 34.6 | Mesa ps3.223, ps3rsx 0.219 | 1920x1080 | whole run | 42.6 | 36.4 | - | - | - | 165.7 | 208 | - | - | - | - | - | - | |
Group 1 X-Moto credits replay (Mesa ps3.186)
2026-10-16 · 2026-10-16-xmoto-credits
Tested: X-Moto's credits replay, now with the game's own frame counter working. Result: 35.04 fps, limited by the CPU, picture right. The music masked the engine sound and there were 196 sound dropouts. No decision recorded. What we saw
| ||||||||||||||||||||||
base |
the recipe as it is | - | - | - | 35.0 | Mesa ps3.186 | 1920x1080 | whole run | 58.6 | 36.3 | - | - | - | 165.0 | 196 | - | - | - | - | - | - | |
Group 1 X-Moto first smoke (Mesa ps3.186; no fps line)
2026-10-16 · 2026-10-16-xmoto-smoke
Tested: X-Moto's first run, playing the credits replay on Mesa ps3.186. Result: No game number: the game ran to the end but printed no frame rate, and the 320 fps in its table is the driver's counter, not the replay's frame rate. The next launch printed its fps line. What we saw
invalid the run printed no frame-rate line; the 320 is the Gallium HUD's median over the whole run, not the replay's frame rate. | ||||||||||||||||||||||
baseinvalid |
the recipe as it is | - | - | - | 320 | Mesa ps3.186 | 1920x1080 | whole run | 50.5 | 25.8 | - | - | - | 146.9 | 67 | - | - | - | - | - | - | |