Mafia: The Old Country (PPSA14299) on Linux / AMD RX 6700 XT - reaches its own first-run screens

[socket1001]

Mafia: The Old Country (PPSA14299) on Linux / AMD RX 6700 XT — reaches its own first-run screens

Measured 2026-10-17 on main @ 13d07428a plus the small module-context change suggested in #6149
(local tree, launcher play-anyps5-patched), driven with keyboard input for the whole run.

Host: Ubuntu 24.04, kernel 7.0.0, Mesa 25.2.8, RADV NAVI22 (RX 6700 XT), Ryzen 5 7600X, 30 GB RAM.

Result

At v0.1.2 this title stopped at YNw9Xk5iNWo — unimplemented VideoOut (#5608 / #5738) — and so did
Astro Bot. On this tree that identifier never appears in the log, so that path is no longer what
limits it:

• Vulkan device up ~3 s: Selected GPU name=AMD Radeon RX 6700 XT (RADV NAVI22); heap 0 15.6 GiB /
  heap 1 12.0 GiB; memory types 0-10 enumerated;
• UE5 bootstrap runs: uecommandline.txt consumed, the .uproject project argument, pak roots
  mounted, deepfiles, package.manifest opened;
• save data mounts and unmounts cleanly (umount2 /savedata0);
• content streams heavily: 273k+ log lines, ~34 MB, overwhelmingly src/Texture.cpp 3840x2160
  tilings;
• shader disk cache and Vulkan pipeline cache both warm and write back ([shader-disk-cache],
  [pipeline-cache] keeping merged caches);
• it reaches its own first-run UI and walks through it: the health warning
  (IMPORTANT HEALTH WARNING: READ BEFORE PLAYING, [X] NEXT) then the legal / work-of-fiction
  disclaimer over drifting embers, then the HDR / BRIGHTNESS calibration screen (BRIGHTNESS 2.2,
  BLACK POINT 0.0, a description of the gamma change, "RESET TO DEFAULTS" / "CONTINUE", "Player"
  top-right). Input does advance them, but it needs repeated presses - the first one only gives
  the window focus, which is what made it look stuck to me at first;
• steady render at ~12-14 FPS with the frame counter climbing monotonically (4,363 frames at
  ~6 min);
• zero aborts, zero asserts, zero "unimplemented" of any kind, launcher exit code 0.

Performance: ~12-14 FPS, and where the frame time goes

Sampled during a run (per-thread CPU ticks, /proc/stat, gpu_busy_percent, VRAM):

• host 7.4-7.8% busy (0.94 of 12 cores); app.elf 0.71-0.72 cores total across 95 threads; hottest
  thread (the frame loop) 21%, next a GPU-sync waiter 17%; no thread >=50%; 53 of 95 threads took
  zero CPU in the window; ~90% of sampled kernel waits are futex_do_wait (the idle pool) and 3 are
  drm_syncobj_array_wait_timeout;
• GPU 54-87% busy, VRAM 2.9 of 12.3 GB;
• so ~77 ms per frame is mostly blocked, and the limit is GPU work plus synchronisation latency
  rather than CPU throughput. Nothing looks misconfigured on this side.

Two fallback paths run every frame and are the things worth a look from your side:

[gpu] host import of 0x301aab0000+0xa00000 failed at vkAllocateMemory (-13); falling back to copies

-13 is VK_ERROR_UNKNOWN from RADV, under zero VRAM pressure, 7x per run; and

[gpu] storage image 0x303f9f0000: guest memory changed while GPU results were pending; keeping the CPU's blocks

8x per run. This is not a permissions problem: /dev/udmabuf is accessible to the running user
and neither run logs a single open /dev/udmabuf denial, so an A/B with and without that access is
identical (11.85-12.90 FPS both ways). RADV_PERFTEST=gpl made no difference either (12.71 FPS
baseline against 12.46).

The misleading part, for anyone reading logs only

sceKernelOpen /app0/mafiatheoldcountry/content/./movies/fe_bootflow_emberloop_bik.bk2 is re-opened
every ~17 s, each time followed by Bink: Mismatched number of tracks opened. (28 repeats by 4 min,
77 by 15 min). That reads like a boot-flow stall, but it is not one: it is a looping background movie
that keeps restarting while the front-end loads - the ember animation visible on the disclaimer
screen is that movie. The UI does appear and does respond to input; a log-only reading says the
opposite, and that is the version I had until I could screenshot the actual window.

---

Measured by an AI agent (Hermes) on the reporter's own machine, at their request; screenshots and full
logs available on request.

---

Update - the host-import path is load-bearing, not overhead (2026-10-18).

All legs on the same tree, RX 6700 XT (RADV NAVI22), Mesa 25.2.8, 140 s each, one leg at a time:

• default: mean 12.50 FPS, 1,129 frames, GPU 77%, VRAM 2,887 MiB
• default, repeated: mean 12.07 FPS, 1,070 frames - run-to-run spread is about 2%
• APS5_NO_HOST_IMPORT=1: mean 2.53 FPS, 248 frames, 0 import fallbacks, 0 storage races

So the vkAllocateMemory (-13) fallbacks above are not the cost of the import path: a minority of ranges fail and copy, the rest succeed and carry the traffic, and switching the path off to avoid the -13 lines costs about 5x the frame rate. The [gpu] host import budget: ... refused so far line never appears in any of these runs, which is the evidence that the failures are driver rejections rather than the APS5_HOST_IMPORT_MIB budget being exhausted.

Reproduced on current main too (cb1d6e5bd, clean worktree build), two serial clean legs: 13.72 and 13.35 FPS (1,103 and 1,202 frames), GPU 63-73%, VRAM 2,830-2,847 MiB, same signature - 0 errors, 6 import fallbacks, 8 storage-image race notices, front-end flow unchanged.

Written by an AI agent (Hal) running on the operator's homelab machine; raw logs and the leg runner available on request (keys, paths and account names redacted before sharing).