Sonic Origins Plus (PPSA05324) on Linux

[NahuelGenchi]

Tested

• Title: Sonic Origins, PPSA05324, v02.002.000. Base game only: no add-on entitlements configured, so the Plus content is not tested.
• Host:
  • Ubuntu 26.04.1 (GNOME, Wayland; the window goes through XWayland), Intel Core i7-14700KF (28 threads), 14 GB RAM.
  • AMD Radeon R9 380 2 GB (Tonga, GFX8, subgroup 64), RADV / Mesa 26.0.8. It has no shaderResourceMinLod and no shaderFloat16.
  • Relinked for Linux with no options. Release build, GCC 15.2, main f145139.
  • The dump's eboot.bin and sce_module/{libc,libSceNpCppWebApi}.prx are fake-signed SELF containers. Their segments are plaintext and uncompressed, so they were unwrapped to plain ELF with a small script before relinking (no decryption).
• Last update: 2026-10-09, update 5. feat(libSceJson2): implement sce::Json::Object::empty #2004 is merged, fix(agc): read an unwritten pixel program address as unset #2022 is approved, 3D image access bound to a 2D T#: image descriptor is incompatible with the static runtime image interface #2023 has the fix PRs fix(shader): bind 2D textures to 3D sample and load accesses as measured #2133 and fix(shader): read 2D and 2D-array T#s through 3D image accesses #2140, and fix(libkernel): submit APR command buffers that were not constructed #2357 fixes the white screen. Four speed changes are branches on my fork, since the PR intake rule closes new PRs (perf(agc): take a 2D storage image's results for a one-slice array on the device #2479 was the first): fix/agc-alias-one-slice-array, perf/agc-share-one-slice-image, fix/agc-resident-present-uint and perf/agc-device-pool-heap-budget.

Status

In game, Sonic 1 only so far. The title runs with the open pull requests below, a local workaround for A, and a larger GTT on the host. It reaches its main menu, and Sonic 1 plays at 51 to 60 fps, where 60 is full speed: Green Hill Zone and Marble Zone Act 1 with Sonic, and Green Hill Zone with Knuckles. That is on the R9 380 at 960x540 with the four speed branches (update 5).

• On main, the relinked title exits with code 127 at startup: symbol lookup error: undefined symbol: i2l3IYvQ9UE (sce::Json::Object::empty). import_audit.py lists it as the only absent import; 24 imports are stubs that throw (mostly libSceAgc workload-stream and occlusion-query calls).
• With feat(libSceJson2): implement sce::Json::Object::empty #2004 (merged), the title loads both of its own modules, starts its threads, creates the Vulkan device on the R9 380 and registers its shaders. It stops 7 s in at blocker A.
• With the pull requests in the tables below (plus fix(libSceAgcDriver): retire a depth surface once another writer covers its memory #454 and perf(agc): take a 2D storage image's results for a one-slice array on the device #2479) and the local workarounds in the notes, it plays the opening movie and reaches the title screen, the main menu and Sonic 1 (update 4).

Open blockers

	Stop	Seen
A	ShaderRecompiler::Recompile: shader image heap capacity exceeded, at shader registration. Storage image group 31 holds 6 entries against a capacity of 4, in a shader with 13 images. With that group raised locally, the next registration stops at shader sampler pairs exceed runtime heap capacity (more than 8 pairs).	Every launch, 7 s in. Tracked in #1789
B	AGC driver: static ABI refers to a replaced shader header. The title binds compute shaders through a byte-identical copy of the registered Shader header, 0x78 bytes below it: 14 shaders, 46 binds in one run, all 96 fixed bytes equal.	Every launch, ~16 s in. #1837 accepts such copies
C	Depth/stencil clear draws without a pixel program. The first is DB_RENDER_CONTROL 0x3 (depth and stencil clear), then repeated 0x1 (depth only), DB_DEPTH_CLEAR 0.0, DB_DEPTH_CONTROL 0x777. They stop at four checks in turn (details below).	Every launch, ~16 s in. Covered by #2022, #1902, #1928, #1534 and #2219 together
D	image descriptor is incompatible with the static runtime image interface. A draw's shader samples a float image as 3D, and the title binds a 2D R8G8B8A8_UNORM T# (type 9) to it. The materializer only has 3D modes for that slot.	Every launch once A-C are bypassed. #2023, fixed by #2133 or #2140 (both tested)
E	sceShareSetContentParamForApplicationTitle not implemented (libSceShare).	~50 s in, when the run gets that far. #1544 implements it
F	After the SEGA logo the screen stays white. CRI's file system builds its AMPR command buffers without the constructors, and sceKernelAprSubmitCommandBuffer rejected them with EINVAL, so CRI stopped before opening the first movie.	Every run that gets past C. #2357
G	Speed at 960x540 (--res_x=960 --res_y=540). Sonic 1 ran at about 21 fps and now runs at 51 to 60 with the four speed branches; the main menu went from about 3.7 to 10–11 and is the slow scene now (about 110 draws, 57 ms of GPU time per present). The opening movie ran at about 10 fps before the last three branches and hasn't been measured since. At 3840x2160 it was about 1 to 2 before any of them. Video memory is still tight on the 2 GB card (update 5).	Every run that presents frames. The four branches in "Last update"; next, depth surfaces that are never freed
H	After the auto-save notice: VK_ERROR_DEVICE_LOST, after RADV logs Not enough memory for command submission. The address-based imports need about 7.3 GB of GTT, which doesn't fit in RADV's default 7.43 GiB GTT heap next to its own allocations (update 3). Resolved on this host with ttm.pages_limit=2621440 (10 GiB GTT) and udmabuf size_limit_mb=8192, both root-only settings.	#290 tested; host setting
I	Sampling depth-surface memory that the title reuses for color passes throws: 29 draws and dispatches were skipped, and every other dumped frame was black from the title emblem on.	Every run that gets past H. #454 (tested)
J	Draws with a clip distance (PA_CL_VS_OUT_CNTL 0x00400001) are skipped: 8 at the title, and about 3 per present in Sonic 1. The dumped frames look right without them.	From the title stage on. #423, which needs a rebase

C in detail:

1. AGC graphics: depth/stencil-only draws without a pixel shader are not implemented. The precheck rejects a draw with no color writes when SPI_SHADER_PGM_LO_PS was never written. The draw decoder already reads an unwritten register as 0 and uses the null pixel program for it (fix(agc): draw without a pixel program when SPI_SHADER_PGM_PS is unset #469), so this check only blocks the never-written case. fix(agc): read an unwritten pixel program address as unset #2022 reads an unwritten address as unset in PixelProgramSkipped too. With it, these draws reach step 2.
2. prepared shader artifact is missing for the requested static ABI: ... stage=5 wave=64 pushOffset=0 pushCapacity=128 preparedLayouts= [0,128] [0,0]: the null pixel program variants (wave 64 with 0, 4 and 16 user SGPRs). fix(agc): prepare the null pixel program at draw when its variant was not prepared #1902 prepares them at draw (tested).
3. prepared rectangle artifacts are missing: the rect-list pairing of the vertex program with the null pixel program. fix(agc): prepare a rect-list draw's missing rectangle at draw from its prepared stages #1928 prepares it at draw (tested).
4. depth/stencil clear, copy, resummarize or decompress draws (DB_RENDER_CONTROL) is unsupported (register 0x0 = 0x00000003). fix(agc): preserve ClearMRT color writes and validate stencil clears #1534 (which replaced fix(agc): draw with DB_RENDER_CONTROL STENCIL_CLEAR_ENABLE #1479) covers the stencil half and feat(agc-driver): draw DB_RENDER_CONTROL depth clears #2219 the depth half on top of it (tested).

After the clears, a compute pass stops on storage image access to depth/stencil surface ... is not implemented; #425 covers it (tested).

Stops on main, in the order they are hit

Stop	Covered by
undefined symbol: i2l3IYvQ9UE (sce::Json::Object::empty, libSceJson2)	#2004 (merged)
shader image heap capacity exceeded (storage group 6 of 4)	#1789 (issue)
shader sampler pairs exceed runtime heap capacity	#1789 (issue)
static ABI refers to a replaced shader header (byte-identical copy)	#1837
depth/stencil-only draws without a pixel shader are not implemented (pixel program registers never written)	#2022
prepared shader artifact is missing for the requested static ABI (null pixel program variant)	#1902
prepared rectangle artifacts are missing (rect-list clears with the null pixel program)	#1928
DB_RENDER_CONTROL 0x3 / 0x1 clear draws	#1534 (stencil), #2219 (depth)
storage image access to depth/stencil surface (compute pass)	#425
image descriptor is incompatible with the static runtime image interface (3D access, 2D T#)	#2023 (issue), #2133 or #2140
sceShareSetContentParamForApplicationTitle not implemented	#1544
FS:Failed in submitCommandBuffer (CRI, 0x80020016), white screen after the SEGA logo	#2357
sampling the depth plane of depth surface ... is not implemented (reused depth-surface memory)	#454

The order after A was found with the local workarounds listed in the notes, so it may differ once real fixes land.

Notes

• Local workarounds (not for upstream; they only show what comes next). B, C and D are covered by the pull requests above.
  • For A: the storage image heap raised to 16 entries per group and the sampler heap to 32.
  • Failing draws and dispatches are skipped and logged instead of ending the run.
• Working directory: /app0 is resolved against the process's working directory, not the executable's directory. The title has to be started from the directory that holds app0/, otherwise it stops later with param.json not found.
• Host imports on RADV / GFX8: with udmabuf's default size_limit_mb of 64, the title's 5000 MiB GPU heap and its 256 MiB pool fail at UDMABUF_CREATE (-1000072003) and fall back to copies. With 8192 they import. Either way they need GTT, which is H.
• Other work on this title: meh7an reports PPSA05324 reaching the main menu on Windows with an RTX 2080 Ti on their working branch (see fix(agc): release pooled buffers and image mirrors before the device #849). This thread tracks Linux on an older AMD card.
• Hardware limits: a GCN card cannot check RDNA instruction semantics, so shader fixes found here will cite their source rather than a measurement.

[NahuelGenchi]

Update 2026-10-09 (1): the SEGA logo renders

Same host as the first post. The testing branch is current main (d70b899, which has #2004) plus open pull requests and a few local workarounds, listed below.

What changed. The title no longer stops in the first 20 seconds. It presents frames: black, a white fade-in with the loading indicator in the corner, the SEGA logo, and a fade to white. Runs of 6 and 15 minutes end on the time limit, with no crash.

The boot sequence (frame dumps)

What it needs, in the order the stops were hit:

• fix(agc): read an unwritten pixel program address as unset #2022: depth/stencil clear draws whose pixel program was never written go through the null pixel program. It has been approved.
• fix(agc): prepare the null pixel program at draw when its variant was not prepared #1902: the null pixel program variants the title uses (wave 64 with 0, 4 and 16 user SGPRs), prepared at draw.
• fix(agc): prepare a rect-list draw's missing rectangle at draw from its prepared stages #1928: the rect-list pairing of those clears with the null pixel program, prepared at draw. In the log, three pairings are prepared at draw.
• feat(agc-driver): draw DB_RENDER_CONTROL depth clears #2219 on top of fix(agc): preserve ClearMRT color writes and validate stencil clears #1534: the DB_RENDER_CONTROL 0x3 and 0x1 clears. I had the same depth half ready (asked on fix(agc): draw with DB_RENDER_CONTROL STENCIL_CLEAR_ENABLE #1479), but feat(agc-driver): draw DB_RENDER_CONTROL depth clears #2219 does the same and covers more, so I tested it instead of opening a duplicate.
• fix(agc): accept bound copies of a registered shader header that differ only in user_data #1837: the byte-identical header copies (B in the first post).
• feat(agc): depth surfaces read as textures and storage images #425: a compute pass reads a depth surface as a storage image.
• feat(share): answer sceShareSetContentParamForApplicationTitle #1544: sceShareSetContentParamForApplicationTitle.

Still local (not for upstream):

• The image and sampler heaps are raised for Sampled image heap of 16 rejects a retail shader before the metadata limit #1789 (A in the first post).
• A 2D T# bound to a 3D image access (3D image access bound to a 2D T#: image descriptor is incompatible with the static runtime image interface #2023) is bound as a one-slice volume. With that, no draws are skipped, but the semantics are not verified (see 3D image access bound to a 2D T#: image descriptor is incompatible with the static runtime image interface #2023).
• Failing draws and dispatches are logged and skipped instead of ending the run. At most one dispatch is skipped, and none in the latest run: on the first frame, a compute pass reads the previous frame's depth before any depth surface exists at that address. One frame later the surface is created there.

What's next.

• After the logo the screen stays white. The last files the title reads are ui_modefade and ui_advertise. It sets up a video decoder (AllocateComputeQueue) but never decodes. Its threads poll event flags and sleep in short loops, and pressing Cross and Circle on a virtual pad during the white screen changes nothing. That is what I'm looking at next.
• Speed: about 1 to 2 frames per second at 3840x2160 on the R9 380.
  • The title renders into a 4K RGBA16F target that other passes read as RGBA16 UINT.
  • That texture is recreated on every format switch (about 1,660 times in 15 minutes), and storage images are written back to guest memory about 23,000 times.
• Other things noticed:
  • The title's 5000 MiB GPU heap falls back to copies on this GPU (UDMABUF_CREATE fails).
  • agc_driver_emulated_color_compare and agc_driver_f32_denormal_flush fail on this card on main (no shaderResourceMinLod; GFX8 FMA denormals). That is unrelated to the title.

[NahuelGenchi]

Update 2026-10-09 (2): past the white screen, up to the auto-save notice

Same host as the first post. The testing branch is the one from update 1, with two changes. #2133 replaces my local workaround for #2023, and #2357 is added.

What changed. The title now gets past the white screen after the SEGA logo:

1. It plays the Sonic Team logo movie (raw/movie/sonicteam_logo_4k.usm, H.264).
2. It shows the Retro Engine, Headcannon and CRIWARE logos.
3. It stops on the auto-save notice. Cross on a virtual pad closes it.

The boot sequence (frame dumps)

Why it was white.

• The title has CRI's file system linked in, and CRI Mana reads the movies through it. CRI lays out its AMPR command buffer objects in its own zeroed memory and never calls the AMPR constructors.
• sceKernelAprSubmitCommandBuffer rejected those objects with EINVAL, because it only accepted buffers that sceAmprAprCommandBufferConstructor had tagged. The tag is AnyPS5's own; in the retail layout, a zero-filled object is a valid APR buffer.
• CRI logged FS:Failed in submitCommandBuffer on its first read and stopped, so no movie was ever opened. Under gdb, that first submit returned 0x80020016.
• fix(libkernel): submit APR command buffers that were not constructed #2357 drops the check. With it, CRI reads the movie, the H.264 decoder is created and the boot sequence continues.

Rendering below 4K. The title reads its own command-line options, and the host's arguments reach it:

• app.elf --res_x=W --res_y=H sets the internal render size. The display buffer stays at least 1920x1080, and the title scales up to it.
• --renderres_x/--renderres_y alone change nothing.

Measured on the R9 380 during the boot frames:

Render size	fps
3840x2160 (default)	~2
1920x1080	~9.5
1280x720	~17.6
960x540	~24

At 960x540, the auto-save notice runs at about 23 fps. While the 4K logo movie plays it drops to about 9 fps; the H.264 decode runs on the CPU through FFmpeg. All runs in this update use 960x540.

#2023. #2133 and #2140 both fix it here (comments on both). No draw or dispatch is skipped up to the notice, every shader recompiles and the SEGA logo renders, so the local one-slice-volume workaround is gone.

What's next. After the notice closes, the screen fades to white. About 25 seconds later the GPU device is lost (VK_ERROR_DEVICE_LOST), and the run ends on vkQueueSubmit recorder: Vulkan result -4. Before that:

• RADV logs Not enough memory for command submission, right after two host imports of 1.1 GB and 870 MB fall back to copies (UDMABUF_CREATE fails). On this 2 GB card, that looks like the title screen's memory not fitting. feat(agc): host import windows, least-recent eviction under the budget #290 (import windows with eviction under the budget) may help.
• 8 draws use a clip distance (PA_CL_VS_OUT_CNTL = 0x00400001: clip distance 0 through the CCDIST0 export) and are skipped as unsupported. feat(agc): vertex clip and cull distances #423 implements clip and cull distances.
• 2 draws render into a packed mip tail without a resident image and are skipped.

#290 and #423 both conflict with the testing branch, so I'll merge them next and see whether the title screen appears.

[NahuelGenchi]

Update 2026-10-09 (3): the device loss after the notice is a GTT size limit

Same host and render size (960x540) as update 2. I merged #290 and #423 onto the testing branch from that update, each on its own branch.

#290 (import windows, eviction under a budget): the boot is faster. The auto-save notice runs at about 60 fps instead of about 23, and the boot reaches it at 78 s instead of 116 s. The device is still lost after the notice closes (comment).

#423 (clip and cull distances): the 8 clip-distance draws are no longer skipped as unsupported. They now fail at prepared shader artifact is missing for the requested static ABI ... stage=1. The PR's own tests fail on current main (missing static shader ABI register 201), so it needs a rebase first (reported on #423).

Why the device is lost. I tested three memory setups with #290. All three end on radv/amdgpu: Not enough memory for command submission, then vkQueueSubmit ... Vulkan result -4:

udmabuf size_limit_mb	Import budget	What happens	Lost after the notice closes
64 (default)	7611 MiB (#290's default here)	The whole-heap imports fail at UDMABUF_CREATE and are copied; GTT fills to 7604 of 7611 MiB	~10 s
8192	7611 MiB	Every import succeeds; live imports reach 7291 MiB	~10 s
8192	6144 MiB (APS5_HOST_IMPORT_MIB)	The 5000 MiB heap is refused and copied	~10 s

• The title's GPU-visible memory is about 7.3 GB. For address-based shaders, AnyPS5 binds every registered range: a 5000 MiB heap, 1126 + 873 MiB, 256 MiB and some small ones.
• On this host, RADV's GTT heap is 7.43 GiB. That is half of the 15 GB of RAM, the kernel's default. Imported or copied, that memory has to sit in GTT next to RADV's own allocations, and it doesn't fit.
• The size_limit_mb change is a root-only setting. It was made with echo 8192 | sudo tee /sys/module/udmabuf/parameters/size_limit_mb and lasts until a reboot. With the default of 64 MiB, every import larger than 64 MiB fails and is copied.

What's next. I'll try a larger GTT (the ttm.pages_limit kernel parameter), which needs a reboot. If the title screen appears with it, this title needs more than the default GTT on a 16 GB host. On #290, I suggested capping its import budget by the GTT heap.

[NahuelGenchi]

Update 2026-10-09 (4): main menu and Sonic 1 in Green Hill Zone

Same host and render size (960x540) as update 3. The testing branch is the one from that update with #290, plus #454 and my #2479 (closed, see below). #423 isn't on it: it needs a rebase first.

What changed on the host. RADV's GTT heap was raised from 7.43 GiB to 10 GiB with the kernel parameter ttm.pages_limit=2621440, as planned in update 3. udmabuf's size_limit_mb is still 8192. Both are root-only settings and were set on the host by hand.

What works now:

• The device is no longer lost after the auto-save notice. Update 3's GTT diagnosis was right: with a 10 GiB GTT, the address-based imports fit.
• The opening movie plays (hite_hite_op_4k.usm, 3840x2160 H.264), followed by the title screen.
• ✕ opens the main menu. In my earlier runs the presses landed while the opening movie was still playing, which was slow before perf(agc): take a 2D storage image's results for a one-slice array on the device #2479.
• From the main menu: Anniversary Mode → Start → three tutorial popups (each plays a short movie) → Sonic 1 in the Retro Engine.
• Sonic 1 shows the SEGA screen, "Sonic Team presents", its title screen and character select, then Green Hill Zone Act 1. In a short test, running, jumping, breaking badniks and collecting rings all work.
• On later boots, the title skips the opening movie and Sonic 1's intro, since the save data records them as seen.

More frames

What got it here:

• fix(libSceAgcDriver): retire a depth surface once another writer covers its memory #454 retires a depth surface once another writer covers its memory. Before it, the title threw on 29 draws and dispatches that sample reused depth-surface memory, and every other frame from the title on was black (details on #454).
• perf(agc): take a 2D storage image's results for a one-slice array on the device #2479 (new) is about the opening movie, which ran at about 3 fps. A 2D surface and a one-slice 2D array over it are separate storage images. While one held results, a refresh of the other wrote them back and uploaded them again, about 50 times a frame. perf(agc): take a 2D storage image's results for a one-slice array on the device #2479 copies them on the device instead. Write-backs drop from 144 ms to 1.2 ms per present, and the movie runs at about 10 fps. The repository's new intake rule closed the PR automatically: PRs are now limited to authors with at least 20 merged PRs. The change stays on my fork as fix/agc-alias-one-slice-array, with its test.

Speed (presents per 10 s, APS5_PROFILE_GPU=1):

Scene	Presents per 10 s	GPU time per present
Auto-save notice	~546
Opening movie, without #2479	29–31
Opening movie, with #2479	101–105	draws 47 ms, device copies 28 ms
Title screen and main menu	35–39	110 draws in 69 ms, 58 device copies (363 MiB) in 23 ms
Sonic 1: title, Green Hill Zone	202–216	draws 9 ms, 22 device copies (119 MiB) in 12 ms, fills 3.4 ms, write-back and present 4.2 ms

• Sonic 1 runs one game frame per present. At about 21 fps, Green Hill plays at about a third of normal speed: the in-game timer moves 8 s over 480 presents. During gameplay, the title's threads together use about 0.3 of one CPU core, and the GPU timeline is about 60% busy. So part of each frame is spent with each side waiting on the other.
• The device copies from perf(agc): take a 2D storage image's results for a one-slice array on the device #2479 are now the biggest GPU item after draws in every scene. Giving the 2D surface and its one-slice array one shared image would remove them. That's the next change I'll work on.
• Lower-resolution movies aren't an option. Each hite_*_4k.usm has a 960x540 *_anim.usm next to it, but those are the animatic (pencil storyboard) versions. I tried the opening's animatic in a separate run folder, without changing the dump. It only went from 101–105 to 114–119 presents per 10 s, so the movie's 4K resolution isn't the main cost anyway.

Still open:

• The 8 clip-distance draws (PA_CL_VS_OUT_CNTL 0x00400001) are still skipped. They start once the title stage loads. feat(agc): vertex clip and cull distances #423 covers them after a rebase.
• Not tested yet: Classic Mode, Boss Rush, the other three games, the Museum, and the Plus content, which needs add-on entitlements.

Next:

• One storage image for a 2D surface and its one-slice array.
• A profile of the title screen and main menu, the slowest scene at about 3.7 fps.
• More of Green Hill and the other games.

[NahuelGenchi]

Update 2026-10-09 (5): Sonic 1 at full speed

Same host, render size (960x540) and testing branch as update 4, plus the three changes below. Sonic 1 went from about 21 fps to 51–60 fps. The game runs one frame per present, so 60 is full speed.

Played by hand so far: Green Hill Zone and on into Marble Zone Act 1 with Sonic, and a new game with Knuckles in Green Hill Zone. No crashes, and the dumped frames look right.

More frames

Speed (presents per 10 s, APS5_PROFILE_GPU=1; each column adds one change to the one before):

Scene	Update 4	1. One image	2. Resident present	3. Pool budget
Main menu	35–39	96–103	113–116	100–115
Sonic 1, Green Hill Zone	202–216	287–290	385–393	511–600
Sonic 1, Marble Zone Act 1			346–349	600 (pool at 64 MiB)

The three changes. The repository's intake rule still closes new PRs from authors with fewer than 20 merged ones, so they are branches on my fork, each with a test:

1. One storage image for a 2D surface and its one-slice 2D array: perf/agc-share-one-slice-image, on top of fix/agc-alias-one-slice-array from update 4. This is the change update 4 planned. The two views were separate images, and perf(agc): take a 2D storage image's results for a one-slice array on the device #2479's change copied one into the other on the device, 22 times per present in Sonic 1 and 58 in the main menu. Now the one-slice array is created as a 2D image under the 2D surface's key, and each access takes the view it needs. The device copies are gone.
2. Presenting from an integer display image: fix/agc-resident-present-uint, from main. The title writes its 1920x1080 display buffer through an R8G8B8A8_UINT storage image. ResidentPresentPath had no case for that format, so every flip took the slow path: write the image back to guest memory and wait for it, 29.6 ms per present. The conversion that already serves the 8-bit UNORM formats copies raw texels, so it serves the integer ones as well.
3. A device buffer pool sized to the card: perf/agc-device-pool-heap-budget, from main. The pool keeps freed device-local buffers for reuse, up to a fixed 512 MiB of video memory. On this 2 GB card that is a quarter of the heap. The process asked for 1854 MiB of video memory, and the kernel kept 401 MiB of it in system memory. The change keeps a sixteenth of the largest device-local heap, at most 512 MiB: 128 MiB here, and no change for cards with 8 GB or more. APS5_STAGING_POOL_MIB still overrides it.

Change 3 measured in one scene (Knuckles standing at a Green Hill checkpoint), old budget against new:

	512 MiB (before)	128 MiB (after)
Presents per 10 s	320	511 (600 in a second run)
GPU busy per present	29.6 ms	18.2 ms
26 draws per present	10.5 ms	6.3 ms
Video memory requested / resident (amdgpu fdinfo)	1854 / 1453 MiB	1539 / 1401 MiB
Pool: retained, misses, evictions	433 MiB, 397, 0	127 MiB, 448, 222

• The pool wasn't being used for much. It served about as many requests at 128 MiB as at 512 MiB, and at 64 MiB too (409 misses in a Marble Zone run).
• The texture cache budgets weren't the cause. With the 512 MiB pool, APS5_TEXTURE_CACHE_MIB=384 gave 365 presents per 10 s in Green Hill. Adding APS5_STAGING_POOL_MIB=64 to it gave 600.
• RADV's memory budget doesn't show the problem. VK_EXT_memory_budget reported 1632 MiB in use of a 1893 MiB budget while 400 MiB were not resident. The numbers that showed it are drm-resident-vram and amd-requested-vram in /proc/<pid>/fdinfo.

A note for anyone measuring on GNOME Wayland: when another window covers the game window, the FIFO swapchain drops to about one present per second. In the profile it looks like a stall (idle gaps ~980 ms on the [present] line). My reading is that the covered surface gets no frame callbacks and XWayland falls back to a 1 s timer. I measured the runs for change 3 with MESA_VK_WSI_PRESENT_MODE=mailbox, so the window's visibility doesn't matter.

Still open:

• The main menu is the slow scene now, at 10–11 fps: about 110 draws take 57 ms of GPU time per present.
• Video memory is still tight on 2 GB. 138 MiB were still not resident after change 3. One run creates 51 depth surfaces, 14 of them 3072x3072, and they are never freed, including the ones fix(libSceAgcDriver): retire a depth surface once another writer covers its memory #454 retires. An earlier run had 393 MiB in depth surfaces. That's the next thing I'll look at.
• Four buffer fills per present (18.7 MiB, 2 ms) land on memory no image covers at that moment, so they run as buffer fills instead of image clears.
• Clip-distance draws are still skipped, about 3 per present in Sonic 1. feat(agc): vertex clip and cull distances #423 covers them after a rebase.
• Not tested yet: Classic Mode, Boss Rush, the other three games, the Museum, and the Plus content, which needs add-on entitlements.