SuperTuxKart

SuperTuxKart 1.5 runs on its legacy GL 2.1 renderer with our big-endian fixes; without them the game quits while loading its track models. It is the heaviest game we play: at the lean settings, now the package’s default for a fresh configuration, it races at 19-22 fps by the Gallium HUD in the benchmark, and its played session on Mesa ps3.850 (2026-10-26) had a 24 fps median over five tracks with no crash and no glitches. Light tracks play well, heavy ones (Ravenbridge Mansion) are slow, and a track’s load takes about 20-30 s.

Packages and patches

supertuxkart, supertuxkart-data (1.5-2+ps3.N, packages/supertuxkart), replacing Debian’s. supertuxkart-data is Debian’s data, rebuilt because supertuxkart needs it at its own version. 839 MB with the data (752 MB of it data), so it deploys by name and is in no suite.

Controls (0007). A pad’s bindings come from its SDL game controller mapping (GamepadConfig::initSDLMapping), once, when STK first sees that pad; 0007 rewrites that table. A pad that already has an entry in ~/.config/supertuxkart/config-0.10/input.xml keeps it (delete the entry, or the file, to get the new scheme). R2 or R1 accelerate, L2 or L1 brake and reverse, the left stick or d-pad steer (and move in menus), Cross skids (selects), Square fires the item, Circle nitro (back), Triangle looks back, Select rescues, Start pauses. STK allows one binding per action, so 0007 adds a second one (DeviceConfig::setAltBinding, saved as a second <action ... alt="true">; setting a binding by hand clears it). A pad with fewer buttons gets the game’s older default. Hot-plug: InputManager::update looks every 2 s for a pad SDL lists that isn’t open.

How it performs

• Two frame rates. The game’s own “Average FPS” (105-111 for lean) is its physics tick rate, not a frame rate; the HUD’s 19-22 is (the investigation).
• The load is the suite’s longest: 54.3 s on the USB root, 31.1 s on the SSD root, where the main thread’s 23.8 s of CPU is 53% decoders (png 4.2, zlib 3.9, audio 2.2, jpeg 2.1 s) (PROFILING.md); all threads (batch 2026-10-19-ssdroot2-startup-profiles): the game 5.35 s, png 4.2, zlib 3.9, audio 2.2, jpeg 2.1, Mesa 1.3, linking 0.9. It is the one game where decoders matter: twice as fast, the main thread would lose 2.7 s of the game’s load path, 2.1 of png, 2.0 of zlib, 1.1 each of audio and jpeg. Our libpng16 +ps3.560 took the png part from 4.0 to 1.6 s and the load from 30.3 to 27.6 s (batch 2026-10-19-ssdroot6-libpng); our libvorbis -0.7 s, zlib-ng -0.9 s, and libjpeg-turbo’s AltiVec path is in use (JSIMD=none +1 s) (batch 2026-10-19-ssdroot5-load-libraries).
• Gameplay CPU (batch 2026-10-19-ssdroot2-gameplay-profiles, 20 fps profiled): the game 36.5% (the main thread: Irrlicht’s driver and Bullet by the symbolised profile of 10-18; __dynamic_cast 0.8%), Mesa 35.5%, libc 15.1% (unsymbolised but for __memcmpeq 0.7, cfree 0.7, malloc 0.5), the kernel 5.1%, ps3rsx 2.6%, the audio thread 3.3% with the “buffer size too low” warnings (HOTPATHS.md).
• Played (rules 2.0): on Mesa ps3.827 a crash on Ravenbridge Mansion after GART ran out, with garbage textures from dropped uploads before it; Mesa 0049 (ps3.850) fixed both, and the next session played five tracks with a restart, textures and kart shadows as on the PC (the investigation).

The benchmark (recipe): profile mode (--profile-time) starts a race at once with every kart AI-driven, on lighthouse with 4 karts (STK_TRACK, STK_KARTS), fullscreen 1920x1080, --no-start-screen; with STK_PROFILE_WARMUP=60 and --profile-time=180 it drives 240 s. The load ends at the “Track: Overall scene complexity” line; GL 2.1 picks the legacy renderer by itself (“Using the fixed pipeline”). setup() writes the whole config.xml every run; base is the game’s defaults with HD textures on. The race is AI-driven (rand() seeded from the clock, frame-time physics): close between runs, not identical. Its GPU timers are garbage on the RSX (timer queries return a pixel count). The sound state is read at 70 s: at 15 s on the slow USB root the game hadn’t opened its audio device yet, so the runs of 2026-10-17 and 10-18 logged sound=none.

Known problems

• Slow on the heavy tracks (the legacy fixed pipeline on the PPE); objects popped in and out on Ravenbridge Mansion in the ps3.827 session (the dropped uploads, since fixed).
• OpenAL logs “Wait timeout… buffer size too low?” in about half the runs on the stock kernel: the sound card’s DMA stopping, fixed by kernel local/0047 (batch 2026-10-20-ssdroot12-dma-watchdog).
• Log noise: irr_driver: Using the fixed pipeline (old GPU, or shaders disabled) and OpenGL: OpenGL version is too old! in every run (the modern renderer needs GL 3.3, by design); 30 User Config: Unknown value for X; expected true or false and Couldn't find parameter group ... lines in 25 runs, because the recipe’s config.xml holds only the attributes it sets (all keep their defaults); SFXBuffer: Positional audio is not supported with stereo files for WilhelmScream.ogg and a car sound; “out of VRAM” lines. Writing a full default config once would clear the config noise.
• The RSX wedged after the ps3.827 crash: X kept running but nothing drew, and a fresh X couldn’t draw either; why the FIFO stopped is open (docs/TESTS.md).

What was tried

Investigations

• 2026-10-17 the big-endian port: the .spm loader, the colours, the minimap target, VRAM 210 to 132 MB.
• 2026-10-19 the two frame rates: the “Average FPS” is a tick rate.
• 2026-10-26 the GART crash and the garbage textures (Mesa 0049).

Research

What the surveys and plans said about it, newest first; each line names its source, the section and the date.

• 2026-10-15, the user’s first wish list (backlog.txt, commit 7d58e3d), “2. GPU driver and game support”: a stretch goal (may work, but RAM or CPU will hurt), in its legacy GL 2.1 renderer mode; the assets are big, so memory will be the problem.