All games

X-Moto

Platinum · 96 0.4 h played, 0 crashes

A 2D motorbike trials game: ride through physics-based levels without falling off, collecting strawberries.

Genre
racing platformer
Players
single player
Input
supports gamepad
View
2D side-on
Keywords
bike physics levels

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 kernel6.12.111+ps3.747 Walnut's build
Mesa26.2.4-1+ps3.721 Walnut's build
ps3rsx0.735+k6.12.111+ps3.747 Walnut's build
DateLauncherGame buildRulesPlayEndedPicture
2026-10-24 X-Moto xmoto 0.6.3+repack-1+ps3.788 1.026 minquit ok Details
2026-10-23 X-Moto xmoto 0.6.3+repack-1+ps3.721 1.01 minquit ok Details
2026-10-23 X-Moto xmoto 0.6.3+repack-1+ps3.721 1.06 minquit 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.

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
xmoto 0.6.3+repack-1
2026-10-24
from 2026-10-23
Platinum · 96 1.0 98899810091-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 gamethe recipe as it is, without a variant
autooffMesa ps3.299 switches, to bisect its cost here: 0027 (adaptive submission) off, 0030 (index upload) off
idxoff-
glstatsour 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):
nobatchDebian's drawing: glBegin/glEnd, a draw per block polygon (~1960 draws a frame)
noblocksbatching only, the blocks polygon by polygon (~1000 draws a frame, ~40 with base)
fpvram0031 (fragment programs from GART after a constant change) off; 0028 (index buffer fenced) off
idxlate-
streamour 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 saw

25 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.

  • ps3-rt-audio put the audio thread on SCHED_RR 1 in every run with it: SDL's audio thread in dsda-doom, X-Moto and Neverball, and Extreme Tux Racer's unnamed audio thread.
  • Audible dropouts a run (about 200 s), median, without and with it: dsda-doom 29 to 2 (audible time 0.8-1.2 s to 50-113 ms), Extreme Tux Racer 26 to 2 (0.65-0.92 s to 58-124 ms), Neverball 3 to 0, X-Moto 0 to 0 (logged underruns 78 to 11).
  • Steady fps unchanged within 0.4%: dsda-doom 39.75 and 39.8, X-Moto 161.7 and 161.0, Neverball 82.73 and 82.72.
  • 1% lows a little lower with it in the light games, ranges touching: X-Moto 113.4 to 109.4, Neverball 57.9 to 56.6, dsda-doom 20.6 to 19.0.
  • Extreme Tux Racer's were higher with it: HUD 1% low 19.8 to 29.2, steady 56 to 59. The previous batch had no such gap (29.9 against 28.6).
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
  • Same boot, two runs per arm interleaved, kernel .472, ps3rsx 0.443, set per run and put back.
  • ClassiCube: steady 46.11 fps in both arms. 1% low 30.1 off, 29.7 on. CPU 80.3 against 86.3 s, within the 79.8-86.6 s the same setup showed across the boot.
  • BananaBread: 39.15 fps off against 39.7 on (the unprofiled baseline spread is 39.06-40.3). Stalls 0.05 against 0.15 s, VRAM equal.
  • X-Moto: 158.4 against 159.0 fps, 1% low 98.1 against 97.5.
  • No gain resolved at two runs on three games; the switch stays off.
  • In the ClassiCube and BananaBread profiles, the code the switch affects is 2-6% of the CPU, the most it could save.
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
  • 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).
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
  • Same boot, one run each. BananaBread's demo is now first-person with the full data (gun and HUD visible): heavier than the earlier spectator runs, not comparable.
  • ClassiCube with its alternative chunk drawing (neighbouring faces in one draw): 50.9 fps against 48.4 (+5%). The staging pool: same fps, CPU -4%.
  • BananaBread: as built 25.0 fps steady and 30.3 smooth. With the query wait capped at 200: 45.6 and 50.0, 1% low 4.9 to 16.9. With the water's occlusion queries lagged a frame: 39.4 and 43.5. Single runs, repeat pending.
  • X-Moto with its streaming draw path: 163.1 fps against 160.4, longest frame 146 against 404 ms.
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
  • X-Moto: GL calls per frame from 18,500 to 165 and draws from 1,960 to 40 (counted on the PC). Credits replay from 44.5 to 166.5 fps (HUD median), against the old drawing on the same boot. The picture was identical on the webcam.
  • Extreme Tux Racer: calls from 19,400 to 850 and draws from 697 to 72. Race replay from 52 to 59 fps, against the old drawing.
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 saw

Same 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
  • Clean runs only, two per game, watched by a webcam script with a single SSH connection.
  • Armagetron: 61.5 fps (50 on ps3.282).
  • OpenArena (compressed textures): 52.4 (51.3).
  • ClassiCube: 46.3, against 46.9 on ps3.282 on the same boot: noise.
  • X-Moto: 44.5, against 47.0 on ps3.282 on the same boot: a real -5%. Turning off adaptive submission (45.5) or the index change (45.0) does not restore it. Fragment constants from VRAM (46) and the late index upload (46) each win back about a frame: 0031 and 0028 cost about one frame each.
  • 0031 checked on the webcam with OpenArena's OpenGL 2 renderer: right picture, no GPU hang. The driver tests pass.
  • Earlier runs that day, made with an old webcam watcher that logged in over SSH every 5 s, were slowed and are left out.
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
  • Mesa ps3.282. Two runs as built and two with a submission every 100 draws, per game, interleaved.
  • OpenArena (compressed textures): 52.2 and 50.4 fps as built, 52.2 and 53.9 with the setting (+3%). CPU 36-38 s in all. Longest frame 892-935 ms as built, 954-1216 ms with it.
  • X-Moto (HUD): 47 and 48 as built, 42 and 44 with it (-9%). CPU 88-90 s in all. Underruns 22-43 with it, 22-29 without.
  • ClassiCube fly-through (own counter): 48.1 and 48.5 as built, 48.8 and 49.0 with it (about +1%, neutral), but 59-60 s of CPU against 54.6 s (+9%).
  • With the Armagetron batch: patch 0019 cost Armagetron its CPU/GPU overlap, and relocations or a submission every 100 draws get it back. But the fixed setting does not suit every game.
  • Spread between two runs of the same variant: 1-2 fps.
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
  • 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 - - - 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
  • 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 - - - 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
  • Mesa ps3.246: no fence reference work when the fence is unchanged, one fence read per validate, no duplicate references. Same command stream.
  • Texture upload, format, mipmap and readback tests all pass.
  • X-Moto 37 fps on the driver's frame counter (35 on ps3.223); underruns 208 down to 126.
  • ClassiCube demo 44.9 fps (43.2 on ps3.225).
  • OpenTTD with libsdl3 +ps3.242: colours right (the user checked), but 2 fps on the counter and 937 underruns, because the framebuffer was converted on the CPU twice per frame. Killed at the 60 s cap.
  • Single runs.
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
  • Each game was profiled for 15 s, so the fps are lower than in plain runs (the run records don't show the profiling). One run per game.
  • X-Moto 34.6 fps (own counter), 208 underruns.
  • OpenArena with compressed textures 37.2 fps, longest frame 3.1 s.
  • ClassiCube 54, Extreme Tux Racer 40 (in its menu), Armagetron 102 (a live first-run game); all three on the driver's frame counter.
  • Result: Mesa took 28 to 56% of the CPU and ps3rsx 6 to 16%.

not comparable every game was profiled with perf during the run, which slows it.
base
not 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
  • Debian X-Moto 0.6.3, single run.
  • 35.04 fps by the game's own counter (5075 frames in 144.83 s).
  • CPU-bound: 165 s of CPU in a 167 s run.
  • 196 underruns.
  • Picture right; the effects play, but the music masks the engine sound.
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
  • Debian X-Moto 0.6.3, credits replay, single run.
  • Exited normally after 206 s but printed no frame-rate line. The cause is not recorded.
  • The driver frame counter's median is 320 fps (10th percentile 249). That is not the replay's frame rate; the table holds this number.
  • 67 underruns.

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.
base
invalid
the recipe as it is - - - 320 Mesa ps3.186 1920x1080 whole run 50.5 25.8 - - - 146.9 67 - - - - - -