Walnut Games

All games

OpenTTD

Gold · 83 with OpenTTD (OpenGL) 0.1 h played, 0 crashes

A transport simulation: build railways, roads, ships and airports and run a profitable company.

Genre
strategy management simulation
Players
single player online multiplayer
Input
made for keyboard and mouse
View
2D
Origin
remake or clone
Keywords
transport tycoon

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, openttd 15.1-1+ps3.721

The platform builds under it (3)
Linux kernel6.12.111+ps3.747 Walnut's build
Mesa26.2.4-1+ps3.819 Walnut's build
ps3rsx0.735+k6.12.111+ps3.747 Walnut's build
DateLauncherRulesPlayEndedPicture
2026-10-25 OpenTTD (software) 1.03 minquit ok Details
2026-10-25 OpenTTD (OpenGL) 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.

OpenTTD (OpenGL)

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
openttd 15.1-1		 2026-10-25 Gold · 83 1.0 74649710090-96 0.1 h
1 test

OpenTTD (software)

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
openttd 15.1-1		 2026-10-25 Untested 1.0 --7910090-- 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: OpenTTD 15.1 with OpenGFX/OpenSFX/OpenMSX. base: a real game. assets/openttd-bench.sav: 1962, 30 towns, 318 stations, 132 trains, 600 road vehicles, 5 ships, 83 aircraft.

The recipe's full description

OpenTTD 15.1 (Debian, our openttd package for the GL driver) with OpenGFX/OpenSFX/OpenMSX. base: a real game (2026-10-19). assets/openttd-bench.sav: 1962, 30 towns (65000 inhabitants), 318 stations, 132 trains, 600 road vehicles, 5 ships, 83 aircraft (a 256x256 map, played by six AIs for 12 years on the PC, then every company made a human one: no script runs, no AI window, no news; made with assets-src/). Loaded from the command line (-g), 1920x1080 fullscreen, the camera on Taningville (a city of 5000 with a rail station and a bus hub, ~35 vehicles within 16 tiles) at the normal zoom, the game at normal speed for the whole run (OpenTTD has no timedemo: a fixed duration; the game thread's work per frame is the same, the vehicle positions drift with the wall clock). The GL driver (-v sdl-opengl, our package) with the package's default blitter (8bpp-optimized since patch 0003; the ps3.297 package and Debian's use 32bpp-anim: the batches of 2026-10-19 ran the old default as `base`), fps from the Gallium HUD (the load ends at the HUD's first frame, 60 s warm-up, 120 s measured, then the game is stopped). Sound and music on as in play: the SDL sound driver at 44.1 kHz and the FluidSynth music driver with the first soundfont it finds (TimGM6mb on the image), OpenMSX playing. setup()'s config turns autosave off, the news popups off (no pause dialogs) and the survey off (OpenTTD 14+ asks on the first start). The AI window can't open: no AI is left in the save. The PS3 needs the image's openttd, openttd-opengfx, openttd-opensfx, openttd-openmsx and fluidsynth with a soundfont (all from Debian), no NewGRF, no AI. sw: the same game with the SDL software video driver through plain X11 (SDL3's accelerated window framebuffer shows a blue cast on big-endian until the SDL3 fix): no GL, so no HUD and no fps (CPU profiles, stalls, memory); the window starts at the savegame's load line ("Loading savegame version", -d sl=1) + 60 s, 120 s measured swaccel: sw with SDL3's accelerated window framebuffer (HUD fps: the SDL renderer is GL) zoomout: base from assets/openttd-bench-far.sav: the same city one zoom step out (4x the area, ~4x the sprites and station names on screen) scroll: base with the camera panned by the keyboard (xkeys.py through XTEST): Right for 3 s, Left for 3 s, over and over from the window's warm-up on; OpenTTD scrolls by the clock, so the pan covers the same ground at any frame rate. Left/Right only: Up/Down clamp at the map's edge from this camera and don't come back nosound: effects off (-s null); nomusic: music off (-m null); quiet: both off hz22, buf2048, buf4096: the SDL sound driver at 22.05 kHz (the mixer's rate, which the FluidSynth music renders at too: half the synthesis), and with a 2048 or 4096 frame buffer (46 or 93 ms at 44.1 kHz; the default is 1024 = 23 ms): sound candidates for underruns blit8, blit32, blit32anim: base with the 8bpp-optimized, 32bpp-optimized or 32bpp-anim blitter (32bpp-anim, the stock default and ours before patch 0003, is a 32-bit video buffer plus an 8-bit animation buffer, both mapped from a pixel buffer object that the CPU blends sprites into): blit32anim is the old default, for comparisons with the batches before 0003 title: until 2026-10-18 base: the title screen's own demo game (trains running, the camera panning by itself) with the software driver through X11, no HUD (the window starts at the title game's load + 60 s). The title game is a savegame with its random state (deterministic, no AIs), but its ticks and the camera's sign-driven pans run on the wall clock. gl, accel, accel8 are title variants too (the GL driver; SDL3's accelerated framebuffer; that with the 8bpp-optimized blitter), as they were. simplay: the bench save's simulation only (null driver, 6000 ticks, exits by itself) sim: simulation only, no video (null driver): a new game from a fixed seed, run for 20000 ticks and timed (a CPU benchmark; it exits by itself) The PS3 runs: `run.sh smoke openttd` (one run, 360 s at most), `run.sh bench openttd "base zoomout"`.

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

20 variants of the recipe
base stands for the gamethe recipe as it is, without a variant
sw-
swaccel-
zoomout-
scroll-
nosound-
nomusic-
quiet-
hz22-
buf2048-
buf4096-
blit8-
blit32-
blit32anim-
titlethe title screen's demo game, as base was until 2026-10-18 (software video, no HUD)
simplaythe bench save's simulation without video: 6000 ticks (a quarter of a game year; 7 s on the PC, 830 ticks a second there against the 33 a second the game needs in real time): the CPU cost of 800 vehicles and 30 towns, no drawing, no sound; exits by itself
sim-
glthe title game with the sdl-opengl driver (the package's default blitter: 32bpp-anim before patch 0003, with sprites drawn on the CPU and the palette animation and the screen upload on the GPU); needs our openttd package (gamedb/games/openttd/packages/openttd/: Debian's refuses nv30, no ARB_texture_rg); compare with title and accel -d driver=2: the GL renderer, the luminance fallback and shader compiler warnings on stderr
accelthe title game with SDL3's default accelerated framebuffer (to check the SDL3 fix)
accel8the accelerated framebuffer with OpenTTD's cheapest blitter (8-bit palette; the default is 32bpp-anim, which redraws palette animation per pixel in software)

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.
OpenTTD, 8bpp the recipe as it is 38.3 13.4 - - - warm-up + 120 s 41 18 0.4 210 3500 - - - - - - - - right, choppy (3500-4700 underruns)
OpenTTD, 32bpp the recipe as it is 11.0 5.7 - - - warm-up + 120 s 17 18 52.0 311 3500 - - - - - - - - right, choppy (3500-4700 underruns)
RT audio thread: SCHED_RR 1 from outside (RTPRIO=10+RTTHREAD) and nice -20 (NICELIM=40) against none on dsda-doom software (owncfg), Extreme Tux Racer and OpenTTD (kernel .874) 2026-10-28 · 2026-10-28-rt-audio-thread
Tested: Whether putting the game's own audio thread on real-time priority (SCHED_RR 1, set from outside) or running the game at nice -20 stops the audible dropouts in dsda-doom (software renderer), Extreme Tux Racer and OpenTTD.
Result: SCHED_RR clearly helps: median dropouts a run fell from 19 to 2 in dsda-doom and from 24 to 3.5 in Extreme Tux Racer, at no frame-rate cost. nice -20 helped less and cost dsda-doom 2%. A per-game opt-in was recommended; not shipped in this form.
What we saw

38 runs in four rounds, order rotated. 14 were interfered by another agent's SSH logins and left out. Every counted run was fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.

  • Audible dropouts a run (about 200 s), median. dsda-doom: 19 with nothing, 10.5 with nice -20, 2 with SCHED_RR.
  • Extreme Tux Racer: 24 with nothing, 3.5 with SCHED_RR.
  • OpenTTD: 2 with nothing (2 clean runs), 1 with nice -20; logged underruns 2019 to 1095.
  • No fps cost from SCHED_RR beyond the noise: dsda-doom 40.1 against 40.3, Extreme Tux Racer 59 against 59. nice -20 cost dsda-doom 2% of its steady fps and two points of 1% low.
  • SDL's own real-time hint does nothing without RTKit: the thread stayed at normal priority.
base nicelim40 43 15.4 0 43 - warm-up + 120 s 45.3 17.9 0.0 98.2 - 257.5 1095 98.2 - - - - -
base real-time priority 0 42.0 15.3 1.0 42.0 - warm-up + 120 s 44.6 17.9 0.1 101.3 - 261.5 2018.5 101.3 - - - - -
batch ssdroot5 FluidSynth on OpenTTD base x3: divide-free reverb (libfluidsynth3 +ps3.549), Debian's stock (LDPATH), effects off (SSD root .472 Mesa ps3.544) 2026-10-19 · 2026-10-19-ssdroot5-fluidsynth
Tested: Whether our FluidSynth build with a reverb that avoids divisions (libfluidsynth3 +ps3.549) is faster than Debian's, and what turning the synthesizer's effects off would save, on OpenTTD with its music, three rounds.
Result: Our build gave 35 against 34 fps (+3%) and later replaced Debian's on the PS3. With the effects off OpenTTD ran 40 fps (+18%); turning them off waits for the user to judge the music by ear.
What we saw

9 runs rotated.

  • Steady fps: 35 with our library, 34 with Debian's (+3%).
  • With the synthesizer's effects off: 40 fps (+18%).
base stall recorder at 10 ms 35 13.2 8 34 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 43.7 17.9 0.9 133.1 - 259.9 3808 133.1 0 0 0.0 0.0 0.8
base stall recorder at 10 ms
switch fxoff		 40 14.3 3 38 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 38.1 17.9 0.3 118.3 - 251.4 2730 118.3 0 0.0 0 0 0.3
base stall recorder at 10 ms
switch ldstock-fluid		 34 13.3 7 32 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 37.1 17.9 0.8 145.0 - 263.6 3925 145.0 0 0 0 0.0 0.7
batch ssdroot5 OpenTTD views with Mesa 0040 on: base, zoomout, scroll x2 (SSD root .472 Mesa ps3.544, 8bpp-optimized) 2026-10-19 · 2026-10-19-ssdroot5-openttd-views
Tested: How OpenTTD's heavy views (zoomed out, and a scrolling camera) run with Mesa 0040's staging pool on, after both had dropped to 7 fps without it; 8bpp-optimized blitter, two rounds.
Result: The pool lifts them: zoomed out from 7 to 23 fps and scrolling from 7 to 31 fps, compared with the blitter batch without the pool. The 8 MB staging buffer per frame was the cost of those views.
What we saw

The staging pool on in every arm, 8bpp-optimized blitter, 6 runs.

  • Normal view (base): 52 fps steady, 1% low 18.6.
  • Zoomed out: 23 fps, 1% low 11.1.
  • Scrolling: 31 fps, 1% low 14.3.
  • Without the pool (the earlier blitter batch, another boot) zoomed out and scrolling both ran 7 fps.
base stall recorder at 10 ms
switch staging_pool_mb24		 52.0 18.6 1.0 50.5 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 41.7 17.9 0.1 110.3 - 230.5 3135.0 110.3 0.0 0.0 0.0 0.0 0.1
scroll stall recorder at 10 ms
switch staging_pool_mb24		 31.0 14.3 5.0 33.0 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 38.8 17.9 0.8 280.4 - 252.3 3506.0 280.4 0.0 0.0 0.1 0.0 0.5
zoomout stall recorder at 10 ms
switch staging_pool_mb24		 23.0 11.1 12.5 22.5 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 34.2 17.9 1.5 161.1 - 253.2 3454.0 161.1 0.0 0.0 0.1 0.0 1.2
batch ssdroot4 Mesa 0040: NV30_STAGING_POOL_MB=24 against off on OpenTTD base (32bpp-anim) and blit8 (8bpp-optimized) x3, the 1962 savegame (SSD root .472 Mesa ps3.544) 2026-10-19 · 2026-10-19-ssdroot4-staging-pool
Tested: Whether Mesa 0040 (a 24 MB pool that reuses big staging buffers for texture uploads) speeds up OpenTTD, which uploads its whole screen as a texture every frame; on both the 32bpp-anim and 8bpp-optimized blitters, three rounds.
Result: Yes, by a lot: the 8bpp blitter went from 34 to 52 fps and 32bpp-anim from 11 to 20 fps, whose stalls fell from 43 to 4.3 s, with the same picture. The pool is off by default in Mesa; no decision to turn it on is recorded.
What we saw

12 runs rotated, plus one profiled run of base with the pool (not for comparison).

  • 8bpp-optimized blitter: 34 to 52 fps steady with the pool (Gallium HUD), 1% low 13.0 to 18.4, frames over 100 ms 5 to 1 (0.4 to 0.1 s).
  • 32bpp-anim (base): 11 to 20 fps, 1% low 5.8 to 9.4, stalls 43 to 4.3 s.
  • Same picture in every arm.
  • The pool takes the 8 MB staging buffer each frame needed out of the memory allocator.
base perf recording
switch staging_pool_mb24		 20 9.6 30 20 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 13.9 25.8 4.7 532.2 - 263.1 3905 532.2 - - - - -
base stall recorder at 10 ms 11 5.8 350 10 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 21.2 17.9 43.7 323.9 - 271.5 3548 323.9 0 0.1 0.1 1.5 40.3
base stall recorder at 10 ms
switch staging_pool_mb24		 20 9.4 39 20 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 16.6 17.9 5.1 521.7 - 256.4 3943 521.7 0 0.0 0.7 0.2 3.7
blit8 stall recorder at 10 ms 34 13.0 5 33 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 38.8 17.9 0.6 128.1 - 264.4 4027 128.1 0 0 0 0 0.5
blit8 stall recorder at 10 ms
switch staging_pool_mb24		 52 18.4 1 51 Kernel ps3.472, Mesa ps3.544 warm-up + 120 s 38.7 17.9 0.1 108.5 - 229.9 3166 108.5 0.0 0 0.0 0 0.1
batch ssdroot3 OpenTTD C: blitters and view on the 1962 savegame (base against blit8, blit32, zoomout, scroll, x3 rotated) 2026-10-19 · 2026-10-19-ssdroot3-openttd-blitters
Tested: Which OpenTTD blitter and view runs best on the 1962 savegame: the default 32bpp-anim against the 8bpp-optimized and 32bpp-optimized blitters, plus a zoomed-out view and a scrolling camera, three rounds.
Result: The 8bpp-optimized blitter triples the frame rate (11 to 34-43 fps) and nearly removes the stalls, with the same picture since OpenGFX is 8-bit art; our package's patch 0003 made it the default. Zooming out or scrolling drops the game to 7-8 fps.
What we saw

OpenGL driver, all three rounds finished, picture right on the webcam.

  • 32bpp-anim (base): 11 fps, 1% low 5.5-5.7, 43-54 s of stalls.
  • 8bpp-optimized: 34, 35 and 43 fps, 1% low 13-15, 0.3-0.5 s of stalls, free RAM 41 MB against 17-21. The picture matches base's (OpenGFX is an 8-bit set).
  • 32bpp-optimized: 13-14 fps, 26-35 s of stalls.
  • Zoomed out one step (4 times the sprites): 7 fps, 115-120 s of stalls.
  • Camera panned with the keyboard: 7-8 fps, 100-116 s of stalls.
  • Underruns stay at 2600-4500 with the 8bpp blitter: the music still runs.
base stall recorder at 10 ms 11 5.5 410 10 - warm-up + 120 s 16.6 17.9 52.8 472.3 - 280.4 4587 472.3 0 0.1 0.1 1.8 48.0
blit32 stall recorder at 10 ms 13 6.5 264 12 - warm-up + 120 s 24.2 15.9 32.7 447.6 - 273.3 4301 447.6 0 0.0 0.1 1.7 29.0
blit8 stall recorder at 10 ms 35 13.4 3 32 - warm-up + 120 s 40.3 17.9 0.4 191.9 - 264.3 3997 191.9 0 0 0 0 0.3
scroll stall recorder at 10 ms 7 4.1 804 7 - warm-up + 120 s 18.4 17.9 115.1 611.4 - 280.2 4484 611.4 0.1 0.3 0.2 3.7 106.1
zoomout stall recorder at 10 ms 7 4.0 833 6 - warm-up + 120 s 13.1 17.9 119.1 491.0 - 274.9 4415 491.0 0.0 0.3 0.0 4.1 110.3
batch ssdroot3 OpenTTD B: audio buffers on the 1962 savegame (base against hz22, buf2048, buf4096, x3 rotated) 2026-10-19 · 2026-10-19-ssdroot3-openttd-buffers
Tested: Whether a lower mixing rate (22.05 kHz) or bigger audio buffers (2048 or 4096 samples) stop OpenTTD's underruns and frame drops on the 1962 savegame, three rounds.
Result: None of them helps. Every arm, base included, swings between about 11 fps with thousands of underruns and 14 fps with a few hundred, which seems to follow how heavy the music is in that run. No gain, so nothing changed.
What we saw

OpenGL driver, 32bpp-anim blitter, picture right on the webcam.

  • No arm helps. Each run is either 10-12 fps with 1800-4700 underruns or 14 fps with 80-700, in every arm including base.
  • base itself: 14 fps with 702 underruns in round 1, 11 fps with 4500 after.
  • The spread probably follows how much the music costs in that run (the playlist is random); not confirmed.
  • The room was noisy from about halfway through, so the microphone clips of the last runs are void.
base stall recorder at 10 ms 11 5.7 414 10 - warm-up + 120 s 19.3 17.9 52.7 312.2 - 280.1 4528 312.2 0.0 0.1 0.1 1.8 48.2
buf2048 stall recorder at 10 ms 11 5.9 360 10 - warm-up + 120 s 21.8 17.9 45.1 296.1 - 274.6 3505 296.1 0 0.1 0.1 1.7 40.7
buf4096 stall recorder at 10 ms 11 6.2 360 11 - warm-up + 120 s 18.2 17.9 43.9 548.8 - 265.4 1795 548.8 0 0.1 0.0 1.7 37.6
hz22 stall recorder at 10 ms 12 6.1 330 11 - warm-up + 120 s 13.2 17.9 41.1 315.3 - 267.9 2878 315.3 0 0.0 0.0 1.3 37.6
batch ssdroot3 OpenTTD A: sound switches on the 1962 savegame (base against nosound, nomusic, quiet, x3 rotated) 2026-10-19 · 2026-10-19-ssdroot3-openttd-sound
Tested: Which part of OpenTTD's sound costs frame rate on the 1962 savegame: music and effects (base) against the sound driver off, the music driver off, and both off, three rounds.
Result: The music is the cost: about 3 fps (20% of the frame rate) and 25-30 s of stalls. The sound effects cost almost nothing. No decision recorded.
What we saw

OpenGL driver, 32bpp-anim blitter (the package's default then), 120 s measured per run, webcam picture right in all 12 runs. Stalls are the time spent in frames over 100 ms.

  • base: 10-12 fps steady, 1% low 5.5-6.3, 32-53 s of stalls, 2326-4668 underruns.
  • Sound driver off: 14 fps, 19.5-21.4 s of stalls, 0 underruns.
  • Music driver off: 13 fps, 24-28 s of stalls, 63-107 underruns.
  • Both off: 14 fps, 19-21 s of stalls, 0 underruns.
  • base's first round (12 fps, 2326 underruns) was lighter than its other two.
base stall recorder at 10 ms 11 5.5 396 10 - warm-up + 120 s 14.6 17.9 50.7 220.3 - 280.6 4632 220.3 0 0.1 0.0 1.8 46.3
nomusic stall recorder at 10 ms 13 7.3 235 13 - warm-up + 120 s 16.9 17.9 27.5 374.5 - 246.4 88 374.5 0 0.0 0.1 1.1 25.3
nosound stall recorder at 10 ms 14 7.7 175 13 - warm-up + 120 s 20.5 17.9 20.1 310.0 - 234.2 0 310.0 0 0.0 0.1 0.8 18.5
quiet stall recorder at 10 ms 14 8.0 173 13 - warm-up + 120 s 21.0 17.9 19.4 241.8 - 233.4 0 241.8 0 0.0 0 0.8 18.1
batch ssdroot3 OpenTTD smoke: the 1962 savegame, software X11 video and simulation only (SSD root, .472) 2026-10-19 · 2026-10-19-ssdroot3-openttd-smoke
Tested: First runs of OpenTTD on our 1962 benchmark savegame: whether its software video path starts with the right picture, and how fast the game's simulation runs with no drawing and no sound.
Result: Both work. The simulation alone ran 6000 ticks in 82.7 s, about 2.2 times real time, so the simulation is not what limits the frame rate.
What we saw

One run each.

  • Software video through X11: starts with the right picture and loads in 4.75 s. This path has no frame-rate counter. 3991 sound underruns; free memory fell to 15.9 MB.
  • Simulation only (no video, no sound): 6000 ticks of the savegame in 82.7 s with 83 s of CPU, about 2.2 times real time. Free memory 50.9 MB.
simplay the recipe as it is - - - - - whole run 49.7 - - - - 82.9 - - - - - - -
sw SDL_FRAMEBUFFER_ACCELERATION=0 - - - - - whole run 15.6 - - - - 225.7 3991 - - - - - -
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.
gl
not comparable		 perf recording 18 6.5 101 18 - warm-up + 120 s 26.3 25.8 14.7 661.7 - 241.4 4172 661.7 - - - - -
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.
gl waker kick at 10 ms 21 9.2 40 20 Mesa ps3.408 warm-up + 120 s 17.0 25.8 6.3 642.4 - 236.3 3893 642.4 - - - - -
Mesa ps3.407 switches (QuakeSpasm LUT, ClassiCube fence pool), profiler checks (ps3-gpu-tools 0.412), all with WAKER kick 2026-10-18 · 2026-10-18-mesa-407-switches
Tested: Two more Mesa ps3.407 switches (the vertex lookup table on QuakeSpasm, a fence pool on ClassiCube), plus profile checks of dsda-doom, OpenTTD and Armagetron with ps3-gpu-tools 0.412.
Result: Both switches are neutral: QuakeSpasm keeps 91 fps with about 3% less CPU, ClassiCube is identical. The Armagetron run is invalid (it sat in the language menu).
What we saw
  • Same boot, all with the 10 ms waker kick.
  • QuakeSpasm with the lookup table: steady 91.0 and 90.8 fps against 90.9 and 91.0 without (no change). CPU 104 and 101 s against 108 and 106 (about -3%).
  • ClassiCube with a pool of 16 fence buffers: identical (48.4 fps).
  • dsda-doom profile fine: 40.3 fps steady, no stalls.
  • OpenTTD reached its title game without the survey dialog (webcam OK).
  • Armagetron: invalid. It was stuck at the first-start language menu (webcam); its 183 fps is the menu.
base waker kick at 10 ms
perf recording		 - - - - Mesa ps3.407 whole run 18.3 - - - - 171.3 3759 - - - - - -
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 - - - - Mesa ps3.262, ps3rsx 0.249 whole run 25.9 - - - - 40.8 868 - - - - - -
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 - - - - Mesa ps3.246, ps3rsx 0.249 whole run 32.5 - - - - 55.5 1429 - - - - - -
ps3rsx 0.249 first boot (Mesa ps3.246; SDL3 ps3.254) 2026-10-17 · 2026-10-17-ps3rsx-249-first-boot
Tested: The first boot with ps3rsx 0.249 and libsdl3 ps3.254: Neverball without the wedge, OpenTTD's native upload, and the first runs of Luanti and BananaBread (the Cube 2 engine).
Result: Neverball runs without wedging (76.4 and 70.2 fps), and OpenTTD rose from about 2 to 8 fps (12 with the 8-bit blitter). Luanti and BananaBread run but are memory-bound; BananaBread's first run was killed for lack of memory.
What we saw
  • The GL tests pass and switching virtual terminals works with a GL program running (those runs aren't in the records).
  • Neverball (our +ps3.257 with its own benchmark, about 23 s) runs without the wedge: 76.4 and 70.2 fps by its own count, longest frames 320 and 378 ms, 15 and 36 underruns.
  • OpenTTD with libsdl3 ps3.254 (native BGRA upload): from about 2 to 8 fps on the driver's frame counter (9.5 across the two runs), 12 fps with the 8-bit blitter. The game's own software drawing is the limit.
  • Luanti, first run: load 37 s, 67 fps on the counter (10th percentile 23, dropping to 0 while map chunks load), free memory down to 31 MB.
  • BananaBread (CPU skinning), first runs: the first was killed by the out-of-memory killer (free memory down to 10 MB); the second reached 15 fps on the counter, 236 underruns.
  • Smoke runs, single or paired.
base the recipe as it is - - - - Mesa ps3.246, ps3rsx 0.249 whole run 33.9 - - - - 48.2 1169 - - - - - -
accel the recipe as it is - - - 9.5 Mesa ps3.246, ps3rsx 0.249 whole run 29.1 31.7 - - - 50.2 1037.0 - - - - - -
accel8 the recipe as it is - - - 12 Mesa ps3.246, ps3rsx 0.249 whole run 42.4 31.7 - - - 55.0 1098 - - - - - -
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.
accel the recipe as it is - - - 2 Mesa ps3.246, ps3rsx 0.219 whole run 30.4 31.7 - - - 46.8 937 - - - - - -
Group 3 OpenTTD first smokes (Mesa ps3.225) 2026-10-16 · 2026-10-16-openttd-smokes
Tested: OpenTTD's first runs: the simulation without video, the title-screen demo through SDL's accelerated framebuffer and through plain X11, and the GL driver.
Result: Big-endian and driver problems: a strong blue colour cast at 5 fps, and a GL driver that refuses to start without single-channel textures. Plain X11 had the right colours. libsdl3 +ps3.242 fixed the cast at about 2 fps, and +ps3.254 brought it to about 8 fps.
What we saw
  • Debian OpenTTD 15.1.
  • Simulation alone (20000 ticks, no video): 13.4 s.
  • Title-screen demo through SDL's accelerated framebuffer: a strong blue cast, 5 fps on the driver's frame counter, 1091 underruns.
  • Through plain X11: colours right, 1260 underruns, no frame counter on that path.
  • The GL driver refuses to start: "Single element texture formats not supported" (the GPU has no RG textures).
  • libsdl3 +ps3.242 fixes the blue cast but converts every frame on the CPU (about 2 fps); +ps3.254 uploads natively (about 8 fps).
base the recipe as it is - - - 5 Mesa ps3.225 whole run 32.3 23.8 - - - 59.7 1091 - - - - - -
gl the recipe as it is - - - - Mesa ps3.225 whole run 87.2 0.0 - - - 3.9 - - - - - - -
sim the recipe as it is - - - - Mesa ps3.225 whole run 81.8 - - - - 5.6 - - - - - - -
x11fb the recipe as it is - - - - Mesa ps3.225 whole run 29.9 - - - - 49.9 1260 - - - - - -