Ghost of Yōtei (PPSA26344) on Linux — Let's talk and see what you are having in trouble and we can help each other.

[Dextroid17]

A Linux-focused status update on this title, with the numbers behind it and where each number came from.
Short version: two real walls are gone, and the title now boots far enough to create a swapchain. It
still does not reach gameplay, and the two walls that remain are a software-rasteriser device limit and a
memory ceiling — neither is a correctness bug in the emulator.

(General discussion of the title lives in #675; this thread is the Linux-facing update.)

The stack these numbers come from

Latest main plus three open PRs stacked locally — #1940 (aperture — mine), #757 and
#758 (image/sampler tables and 64-bit table pointers — @Celegans12's) — together with
@pipodi93's fix for relocated shader headers.

Two honesty notes, because they change how you read this:

• None of those three PRs is merged upstream. I merged them into a local test build. If you want the
  same run, you stack them yourself.
• 44a80d4f is not a commit in my branch. I took @pipodi93's change and re-applied its hunk by hand
  in ShaderRegistry.cpp (SameHeader). The code under test is his change; the commit in my stack is
  authored by me. Credit where it is due, and blame where it is due.

What changed

• The structurizer spin is gone on current main, and it looks like a performance pathology rather
  than a correctness failure. An older stack I was running spun for 20+ minutes inside
  ShaderRecompiler::Structurizer::computePostDominators. The merged perf(recompiler): compute post-dominators visiting successors first #2105 (compute post-dominators
  visiting successors first) and perf(recompiler): look up dominance by binary search and track visited blocks in a bitmap #2276 (look dominance up by binary search) landed after that stack
  was cut — and a rebuild from main no longer spins. If you still see that spin, you are on old code.
• The replaced-shader-header wall is fixed by @pipodi93's change. Before it, a relocated shader
  header was checked against its original address and refused with AGC driver: graphics ABI refers to a replaced shader header. After it: 0 refusals in both runs I checked, and the title reaches a
  created swapchain.
• Reproduced on two Linux devices. llvmpipe (LLVM 23.1.1, 256 bits, subgroup 8) and an NVIDIA
  RTX 3080 Ti (0x10de/0x2208, subgroup 32) both report
  Swapchain created … extent=2393x1346 images=3.

Where it stops now (Linux)

1. On llvmpipe / lavapipe — a device limit. The title issues a direct compute dispatch that
exceeds llvmpipe's maxComputeWorkGroupCount. In an instrumented build the grid printed as
129199x1x1 against a limit of 65535x65535x65535; that line comes from the instrumented run,
not from the stock driver, which logs only the abort:

compute shader 0x8000393600: Vulkan dispatch: workgroup count exceeds device limits

The same title gets past this point on the NVIDIA GPU, whose reported limits are far larger, and the
console allows it too — so this reads as a llvmpipe limitation, not an emulator bug. There is no
dispatch-splitting path in the driver, so on lavapipe (our CI device) this title cannot proceed past it.
It deserves a TechnicalDebt entry either way.

2. On NVIDIA — memory. The 3080 Ti gets past the dispatch limit and then runs into the title's
working set. Three runs were killed by systemd-oomd (userspace — not the kernel) with no code
wall at all; its own record shows the box at 33.0 GB of 33.5 GB RAM and 30.2 GB of swap in use at
the moment of the kill, with the per-run scope peaks landing between 20–25 GB RAM and 21–23 GB swap. A
fourth run reached the swapchain and then stalled — no log output for 18 minutes at about half of
one core — until I stopped it. What I can say with evidence:

• It is ~100% anonymous private memory. Sampling /proc/<pid>/smaps_rollup during a run gave
  Anonymous ≈ Rss (a 15.2 GB anon / 15.3 GB RSS pair mid-run) with Shared in the low single-digit
  MB — so this is not the guest's direct-memory memfd, and not a mapping or memfd leak. (These are
  live samples I read out of /proc; I did not archive them, which is why they are quoted rather than
  linked.)
• It is not the udmabuf copy fallback: /dev/udmabuf is present and my user can open it
  read-write (mode crw-rw----+, granted by an ACL entry for my account — I am not in the kvm
  group), and the [gpu] open /dev/udmabuf: … warning never appears in the logs.
• It is not the device-sized caches. Forcing APS5_TEXTURE_CACHE_MIB=512 — which overrides both the
  sampled-texture and storage-image budget — left the sampled RSS at the same ~15 GB. For reference,
  the stock run logs sampled texture cache budget 6416 MiB / storage image cache budget 3072 MiB on
  this GPU (a representative sample — it varies run to run, e.g. 6414–6416 MiB — and the llvmpipe run
  logs different, larger numbers, 10143 / 7978 MiB), so those budgets are not what drives the footprint.

What remains is unattributed, and I would rather say so than guess. One mid-run sample showed a block
of 81 × 64 MiB anonymous regions (5.1 GiB); 64 MiB is exactly the driver's ImportChunkBytes, and the
anonymous memory may simply be the guest's ~13.5 GiB of direct memory accounted private rather than
shared. I could not settle it with env knobs and sampling — it needs per-allocator instrumentation or a
heap profiler. If anyone can measure the RSS (not the commit) of the same scene on Windows, that
comparison would probably settle it immediately.

Running it yourself on Linux

• Choose the device by ICD: VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json, or your lavapipe
  lvp_icd.*.json. LD_LIBRARY_PATH must include both the loader's directory and the built libs/.
  ANYPS5_REQUIRE_VULKAN=1 makes it fail loudly instead of silently falling back.
• Do not launch it under a memory cgroup. A cgroup-capped run is killed by the cgroup, which
  presents exactly like an emulator crash and sent me down a wrong path once. Launch it through a scope:
  systemd-run --user --scope -p MemoryHigh=18G -p MemoryMax=22G -- ./app.elf.
• Knobs: APS5_TEXTURE_CACHE_MIB bounds the texture and storage caches; APS5_PROFILE_DRAW is written
  up in Document the APS5_PROFILE_DRAW output and add a log digest #1286, APS5_HANG_DUMP_SECS in APS5_HANG_DUMP_SECS on Linux #1285, and the general APS5_* reference is Reference for the APS5_* environment variables #1284.
• A run needs a display even if you do not care about the window; without one the Vulkan path reports
  support is unavailable for the video driver.

Honest summary

On Linux today the title boots, recompiles its shaders, creates a swapchain and reaches presentation —
on llvmpipe it aborts there; on NVIDIA it carries on into the frame and is then either killed by
systemd-oomd or stalls while the machine swaps. It does not
reach gameplay: upstream's own frontier is the opening cinematic at ~1 fps with tessellation still open,
so "running clean" is not reachable for anyone yet. The two walls that are cleared are real; the two that
remain are a software-rasteriser device limit and a memory ceiling, and the memory question is
deliberately left as an open measurement rather than a claim.

The numbers above come from the run logs, from systemd's per-scope memory accounting, and from sampling
/proc/<pid>/smaps_rollup during a run. The stack, the logs and the commands are in my fork, and I am
happy to share any of them. Written with AI assistance, then independently re-checked.

[Dextroid17]

A direct ask: what is this title's working set on Windows?

One number would settle the biggest open question in the post above, and I do not have it.

The Windows figures I can find for PPSA26344 are commit charge, not resident memory. In #675,
Celegans12 writes: "#637 on this title: commit charge drops from about 15.3 GiB to 6.6-7.0 GiB at the
same stop." On Linux I measure something different in kind — a mid-run sample of ~15 GB anonymous
≈ RSS, with runs peaking around 20–25 GB of RAM plus 20–24 GB of swap (roughly 46 GB of RAM+swap
combined) until the machine — 31 GB RAM + 31 GB swap — is exhausted.

Those are not the same quantity: memory can be committed and never touched, and Windows commits more
readily than it faults in.

So, to anyone running this title on Windows — @Pipodi's Windows 11 Pro / i9-13900K / 32 GB / RTX 4090
host is the natural one, and the 32 GB matters here:

What is the process's working set at the same stop? That is Memory (private working set) in Task
Manager's Details tab (enable it via Select columns), or WorkingSet64 / PeakWorkingSet64 in
PowerShell:

Get-Process app -Refresh | Select-Object Name, WorkingSet64, PeakWorkingSet64

(WorkingSet64 includes shared pages, so it is slightly wider than Task Manager's private working
set — either is fine, just say which one you used.)

Why it matters, and why it decides what I do next:

• If Windows holds a few GB of working set where Linux wants tens of GB, the Linux footprint is a bug
  with a target, and the next step here is per-allocator instrumentation to find it.
• If Windows holds a similar tens-of-GB working set, then the two platforms agree, the Linux number is
  simply the title's size, and we can all stop chasing it.

Either answer is useful — a "similar" would save me from a hunt that cannot succeed. Thank you.

[Pipodi]

@Dextroid17 measured on the host you mention (Windows 11, 32 GB RAM, RTX 4090), with one caveat that matters more than the numbers: my tree is not main, and one local change in it moves exactly this figure.

Before that change (closest to main). Cold cache, run of 2026-10-10 13:08: private bytes (commit) peaked at ~54 GB before the run died. I only logged private bytes then, not the working set, so take that as commit. With 32 GB of RAM it can't all have been resident; the pagefile grew through the run. The shader disk cache for that run is 34 GB for ~15,000 compiled variants (~2.3 MB of SPIR-V each), and main keeps every compiled variant's SPIR-V words on the heap for the life of the process. That is the bulk of it: roughly two thirds of the 54 GB.

With the change. Locally, SPIR-V words loaded from the disk cache point into a read-only file mapping instead of a heap copy (not in a PR). Same title, warm cache, sampled with Get-Process plus the Win32_PerfFormattedData_PerfProc_Process counter:

point	WorkingSet64	private working set	private bytes
797 s, loading screen after the intro	15.5 GB	4.9 GB	10.1 GB
2,829 s, much later in the title-scene load (where this run stopped)	16.3 GB	10.0 GB	26.4 GB
peak over the run	25.0 GB (at ~1,110 s)	10.0 GB	26.6 GB

(GB = 2^30 bytes here, as PowerShell divides by 1GB.) The gap between the working set and the private working set is shared, file-backed pages: the mapped cache entries and the guest memory section. Private bytes run well above the private working set, so a large part of the private commit is not resident.

So I'd read your Linux numbers as agreeing with Windows, not as a Linux bug: on main-like code, Windows also goes into tens of GB, and moving the SPIR-V out of anonymous memory is what brings it down here. A cheap check on your side: if your anonymous RSS grows with the number of [shader-disk-cache] misses/hits (each variant ~2.3 MB) rather than with time, it's the SPIR-V. That also fits your follow-up: a wall at the same log point every run, with the cap only deciding between throttling and an oomd kill. On a cold cache the title-scene load here compiles ~15,000 variants between the intro and where my runs stop, and on main each one stays resident.

[Dextroid17]

Follow-up: one reading reproduces, and a correction

Two additions to the post above: the memory reading repeats, and my description of the "stall" needs fixing.
(These are my own measurements, on the same local NVIDIA stack the post was written from.)

The Anonymous ≈ Rss reading reproduces. I have sampled /proc/<pid>/smaps_rollup five times across
four runs on the RTX 3080 Ti, and the anonymous figure tracked RSS every time (GB, decimal):

run 1                      Rss 16.25   Anonymous 16.19
run 2                      Rss 15.30   Anonymous 15.25
run 3 (TEXTURE_CACHE=512)  Rss 15.03   Anonymous 14.23   <- the outlier: ~0.8 GB non-anonymous
run 4                      Rss 14.93   Anonymous 14.87
run 4 (later sample)       Rss 15.20   Anonymous 15.15

In four of the five samples the anonymous figure sat within ~0.5% of RSS; run 3 was the only one with a
noticeable non-anonymous part. Shared stayed in the low single-digit MB throughout, so the "not the
guest's direct-memory memfd" conclusion holds across runs rather than resting on one sample.

Correction — the "stall" is cap-dependent, and part of it was my own sandbox. I wrote that the run
"stalls" after the swapchain. That is what I observed, but it is not the whole story, and part of it was
the sandbox I ran it in. Looking at the kernel during the freeze shows the process is not spinning
inside the emulator — five of its threads are blocked in __mem_cgroup_handle_over_high, and the run's
own cgroup counters say why:

memory.high     = 18.0 GiB  (19.3 GB)   <- the cap I had set
memory.current  = 18.8 GiB  (20.2 GB)   <- already over it
memory.events:    high 146,367          <- throttled 146,367 times, still climbing
memory.pressure:  some avg10=61.38    full avg10=60.57

(Units spelled out deliberately: GiB is the binary unit systemd prints as "18G"; the decimal GB
equivalents are given so the two cannot be confused for different numbers.)

So under a memory cap the kernel throttles the run into a crawl — a frozen log, not a hang. Raising the
cap does not remove the wall, it only changes the ending: with MemoryHigh=23G on the launch line, the
same build stopped at the same log point — 96,645 bytes against 96,646, reproducible to within one
byte, both logs ending on the same line — and was instead killed by systemd-oomd 53 seconds in, the
scope recording a peak of 23.0 GiB (24.7 GB) of RAM and 20.0 GiB (21.5 GB) of swap.

The accurate statement, then: after the swapchain the title's memory demand outgrows what this box can
supply, and the cap decides what you see — a throttled crawl (frozen log, threads sitting in cgroup
reclaim) or an oomd kill when the box itself fills. It is resource exhaustion either way, not a hang in
the emulator, and I should have said so the first time.

Happy to share the run logs and the captured cgroup counters; I did not archive the /proc samples, so
those figures are quoted rather than linked.

[Dextroid17]

Progress update: the memory question is answered, and my earlier "stall" was my own sandbox

A consolidated update on everything since the post above — two walls cleared, one of my own claims corrected,
and the memory question finally closed with a measurement rather than a guess. (Still stacked on my #1940
and @Celegans12's #757/#758 as before.)

1. Where the title stands

Boots, recompiles its shaders, and gets as far as a created swapchain (extent=2393x1346, 3 images) on
both the reference Linux device (llvmpipe, LLVM 23.1.1, subgroup 8) and an NVIDIA RTX 3080 Ti
(0x10de/0x2208, subgroup 32). It does not reach gameplay.

2. Two walls cleared

• The structurizer spin is historical. The stack I ran for my first post was cut before the merged
  perf(recompiler): compute post-dominators visiting successors first #2105 and perf(recompiler): look up dominance by binary search and track visited blocks in a bitmap #2276 landed, and it spun for 20+ minutes inside
  ShaderRecompiler::Structurizer::computePostDominators; a rebuild from current main includes both and
  no longer spins. Their own bodies state the structured graph is unchanged, so this reads as a performance
  pathology rather than a correctness failure. If you still hit it, you are on old code.
• The replaced-shader-header wall falls to @Pipodi's change. Before it, a relocated shader header was
  checked against its original address and refused with AGC driver: graphics ABI refers to a replaced shader header. After it: 0 refusals, and the title reaches a created swapchain. Two points of
  attribution, both needed: the SameHeader check being relaxed at all was added by @EdouardSence in
  cd1f76c8 ("accept bound copies of a registered shader header that differ only in user_data"), and
  @Pipodi's 44a80d4f extends it to relocated pointers. And to be precise: 44a80d4f is not a commit
  in my branch — I re-applied its hunk by hand in ShaderRegistry.cpp, so the code is theirs and the commit
  in my stack is mine.

3. Correction to my first post: the "stall" was (at least partly) my own cgroup cap

I wrote that the run "stalls" after the swapchain. That was observed, but it was an artefact of how I
launched it. Watching the kernel during the freeze shows the process is not spinning inside the
emulator — five of its threads sit in __mem_cgroup_handle_over_high, and the run's own cgroup counters
say why:

memory.high     = 18.0 GiB  (19.3 GB)   <- the cap I had set
memory.current  = 18.8 GiB  (20.2 GB)   <- already over it
memory.events:    high 146,367          <- throttled 146,367 times, still climbing
memory.pressure:  some avg10=61.38    full avg10=60.57

Raising the cap does not remove the wall, it only changes the ending: with MemoryHigh=23G on the launch
line the same build stopped at the same log point — 96,645 bytes against 96,646, both runs ending on
the same kind of line (a shader-disk-cache rollup) — and was instead killed by systemd-oomd 53 seconds
in, the scope recording a peak of 23.0 GiB (24.7 GB) of RAM and 20.0 GiB (21.5 GB) of swap.

So the honest statement is: after the swapchain the title's memory demand outgrows this box, and the cap
decides what you see — a throttled crawl, or an oomd kill. It is resource exhaustion, not a hang in the
emulator, and I should have said so the first time.

4. The memory question, closed by measurement

I could not get an answer out of a debugger: app.elf is the relinker's output (the game's own code),
so it has no symbols and no unwind data, and glibc here is stripped — every backtrace collapsed after
two or three frames. So I interposed the allocator instead: a small LD_PRELOAD shim that logs
__builtin_return_address(0) for large malloc / realloc / mmap, which needs no unwinding at all.
It named every call-site. The result:

The enormous number is virtual, not resident. One caller shows 1038 GB — but it is the guest arena
reserving its address space, and the source is explicit about it
(core/libs/prx/libc/src/GuestArena.cpp:191-196):

constexpr std::uintptr_t kChunk = 1ULL << 30;      // 1 GiB
mmap(wanted, end - cursor, PROT_NONE,
     MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE | MAP_FIXED_NOREPLACE, -1, 0);

PROT_NONE + MAP_NORESERVE costs no physical memory. A kernel OOM report from a separate, earlier
run recorded this process at total-vm:1050275672kB ≈ 1 TB — the same virtual space showing up in a
different instrument. It is not a leak, and I nearly reported it as one, which would have been roughly
80× wrong; flagging it here in case anyone else reads a huge mmap total the same way.

The real resident growth is only ~12.9 GB cumulative, and it is the ordinary sum of three things:

  5.75 GB  x1488  malloc   libstdc++            (the host C++ heap)
  4.86 GB  x3     mmap     libkernel.prx        MapPlaced  <- the guest memory mapping
  1.97 GB  x1356  realloc  libnvidia-glcore     (the GPU driver)
  0.26 GB  x1     calloc   libSceAgcDriver.prx  GuestMemory::PageStates::initialize
  ─────────────────────────────────────────────────────────────────────────────────
  ~12.9 GB        the actual resident growth (against ~15 GB of anonymous RSS observed)

Conclusion — on this stack, there is no leaky function. The title's host memory here is the legitimate
combination of the guest's own memory mapping, the host C++ heap, and this driver. Note the third term is
a driver allocation and is exactly the part that can differ by vendor and version — so on another GPU or
driver the total could well differ, which is why §5 matters. On this box (31 GiB) that sum is what makes
the ≥46 GB genuine rather than pathological.

5. The one open question

Whether that appetite is inherent to the title or specific to this stack can only be settled by comparing
the working set, not the commit charge, against Windows — see the ask above. That is still the number
I would most like.

6. Notes for anyone reproducing this (Linux)

• A low MemoryHigh produces a fake hang. It throttles the entire cgroup — including a debugger — so
  you get a frozen log with no error. Launch with systemd-run --user --scope and MemoryMax only.
• ptrace_scope=1 means you cannot attach to a scope-launched process; run the title as gdb's child and
  interrupt it by RSS threshold instead.
• gdb's info proc mappings columns are Start End Size Offset Perms File — use the Offset, not the
  Size, when converting a runtime address to a module address (I got this wrong once and it cost a
  debugging round).
• glibc frames need debuginfod (set debuginfod enabled on); gdb prompts and defaults to "no".
• The interposer is about thirty lines and I am happy to share it, along with any log.

Written with AI assistance, then independently re-checked.

[Dextroid17]

Two corrections and the next step, on my own post above.

The mention is wrong. I wrote @pipodi93 three times; there is no such account — it 404s — and the person whose change cleared the replaced-header wall is @Pipodi. A post that says "credit where it is due" has to get the handle right, and a wrong one notifies nobody. Apologies.

The two memory accounts describe two different stacks, and they agree. @Pipodi's figures are from main-like code, where every compiled variant's SPIR-V words stay on the heap: 34 GB of disk cache for ~15,000 variants at ~2.3 MB each is roughly two thirds of the ~54 GB he measured. My interposer figures (~12.9 GB of resident growth: 5.75 GB libstdc++ heap, 4.86 GB the guest mapping, 1.97 GB inside the NVIDIA driver, 0.26 GB page states) come from the frontier stack, and the libstdc++ term is exactly where SPIR-V retention would appear. So neither contradicts the other, and neither is a Linux-specific bug.

I cannot second the volume of his retention claim — I have not measured it. What I did check is its shape, and that matches the source: loading a variant from the disk cache heap-copies its words (ShaderDiskCache.cpp, decodeArtifact: result.spirv = std::move(words)), and there is no mapping path in that file — no mmap, no PROT_READ. So the mechanism is what the code does; the size is his to measure.

The cheap test he named is the next step, and it is testable here: if anonymous RSS grows with the number of [shader-disk-cache] variants rather than with run time — about 2.3 MB each — the footprint is SPIR-V retention rather than the title's own working set. That is one run on this side, and it decides whether the ≥46 GB ceiling is inherent to the title or something the host can stop paying.

Written with AI assistance.

[Dextroid17]

Reproducing this on a 32 GB box, and one addition to the launch advice.

Same place, different machine: on the RTX 3080 Ti the title reached Presentation window … extent=1920x1080 and Swapchain created … extent=2393x1346 images=3, then systemd-oomd killed the scope after 4 min 20 s wall / 40 min 15 s CPU, peak 24.7 GB memory + 21.5 GB swap. The kill condition was memory 33.08 / 33.46 GB and swap 30.22 / 33.46 GB — the same wall the post above describes, reproduced on a different host.

The launch advice needs one more knob. I launched this run through a scope with MemoryMax only, which leaves swap unmetered — and that is what tripped it: the memory cap held (the scope's peak was 24.7 GB against the 26 GB I set), but the host still reached ~99% RAM and ~90% swap, oomd still picked the scope, and the system log recorded critical memory pressure at that minute. Capping swap as well is what ends the run before the host gets there:

systemd-run --user --scope -p MemoryMax=22G -p MemorySwapMax=8G -- ./app.elf

One observation worth recording, because it is easy to misread: the window appears with the correct title and icon and stays black — and in this run that was warm-up, not a rendering wall. The log contains no present or frame marker at all, and the shader cache was still missing new variants right up to the kill (misses 270 → 392 in the final minute), so nothing was presented in the 4 min 20 s it had. A black window at that stage is consistent with shader warm-up running into a memory ceiling rather than the graphics path failing.

Caveats: this is the NVIDIA vendor path, a single run, on a capped scope — one machine's numbers, not a general claim about the title.

Written with AI assistance.

[Dextroid17]

A cross-device measurement on the compute path, and one retraction of my own.

Both numbers below come from the same instrumented build, run once on the RTX 3080 Ti and once on lavapipe — the CI device — so the second run rules out vendor behaviour. The build is current main plus one local change that only names a refusal instead of leaving it bare — the run still logs the scalar aperture source src_shared_base is not modelled — and it stops at the replaced-shader-header wall. Both runs compiled their shaders from scratch (the disk cache produced no hits for this build: ~1290 misses, 0 hits), so neither is measuring a warm-cache shortcut.

One compute packet dominates a run, and its cost is not fixed. The packet report names it: DISPATCH_DIRECT x1 241334 ms on the 3080 Ti, x1 139257 ms on lavapipe — and a later run of the frontier build on the same GPU put the same packet at 23 s, with RSS reaching the memory cap inside 40 seconds in both cases. So the duration varies by an order of magnitude between runs; what does not vary is that the host is working while it happens — sampling during the packet showed about eleven threads above 50% CPU, not a process parked on a fence. The dispatch's grid is small — 120x68x1, a 6969-word program (measured on the 3080 Ti run) — so this is not a large dispatch in any ordinary sense, and it reproduces on both devices. The timer measures the host-side duration of the packet, so this is packet wall-clock, not a GPU timestamp, and it does not by itself prove the GPU was busy for that whole time. What I cannot tell from here is which side of the line it falls on: the guest shader genuinely being that expensive, or the emulator inflating its work. That needs a hardware reference or a working oracle, and this box has neither.

The WAIT_REG_MEM I first read as a hang is not one. A second queue sits in WAIT_REG_MEM x1 241604 ms (241.6 s on the 3080 Ti, 139.3 s on lavapipe, 23.3 s in the later run) — and it outlives the dispatch beside it by only a fraction of a second, consistent with a dependent queue releasing when the dispatch completes rather than a register that never resolves. Retracting the "stall" framing I was about to attach to it: the wait is the symptom, the dispatch is the apparent cause.

One measurement that is not worth reporting, recorded so nobody repeats it: the same build shows a storage image's creation taking 1235 ms on the 3080 Ti against 19–25 ms on lavapipe. That ~49–65× gap is the NVIDIA driver on Linux, which this project does not support, so it is a note rather than a finding.

Caveats: one run per device; neither run reached a draw — both stop earlier, at the replaced-shader-header wall.

Written with AI assistance.

[Dextroid17]

A correction to my own comment above: I measured the advice, and it does not hold.

I said that capping swap would end the run before the host got there. It does not. I launched run 2 through a scope with MemoryMax=24G and MemorySwapMax=24G; both caps held (the scope's peaks were 23.6 GB memory and 21.9 GB swap, under the 24 GB limits), and systemd-oomd still killed the scope, at the same system-wide thresholds as before: memory 33.05 / 33.46 GB and swap 30.28 / 33.46 GB, both over 90%. The scope consumed 8 min 10 s CPU inside the 60 seconds of wall clock it lived.

So it is the cap's value that decides the outcome, not its existence: the title's working set is larger than this host's RAM plus swap, so a cap generous enough to let the run reach the frame path also lets it drag the host past 90% swap, and oomd fires. A tight cap does keep the host safe — by ending the run early. The scope still buys a targeted, survivable kill: this host came back with swap at 0.01 GiB.

Run 2 does add one thing worth having. It finished shader warm-up: with the disk cache warm it was already past the swapchain inside a run that lived only 60 seconds, logging 1337 cache hits against 7 misses, versus 949 hits and 392 misses in run 1. So the appetite that reaches ~24 GB is not shader compilation — this run had essentially nothing left to compile, grew into the frame path anyway, and still presented no frame (the log's only line containing "present" is the window itself; 241 lines, no exception).

That sharpens the Windows working-set question rather than answering it: on this stack the appetite is not a cold-cache artefact.

Written with AI assistance.

[EdouardSence]

Where the memory goes on RADV, measured on an RX 9070 XT (RDNA4, Mesa RADV, 30 GB RAM). The build is main a11c8f7 with #758 (and #757) merged locally. I resolved the conflicts by keeping both sides, as @Tamalero describes on #757, and added the max(1, n) variable count from #757 for RADV.

The memory is pipeline compilation, not the title's data. With #758, the title passes 0x80003aa700 (#2715) and about 30 s in logs five compute pipelines back to back:

[dispatch] creating a pipeline for 339083 SPIR-V words (program 0x8000265d00)
[dispatch] creating a pipeline for 104504 SPIR-V words (program 0x800039ce00)
[dispatch] creating a pipeline for 146776 SPIR-V words (program 0x80003af600)
[dispatch] creating a pipeline for 423886 SPIR-V words (program 0x8000253100)
[dispatch] creating a pipeline for 928775 SPIR-V words (program 0x8000289300)

I sampled VmRSS every 0.5 s alongside the log. RSS is 3.7 GB when the last line is written. Nothing more is logged after it, and RSS climbs at about 850 MB/s to the 20 GB cap, then 8 GB of swap. The kernel OOM killer then ends the scope after about 75 s. The result is the same in 3 of 3 runs, with a cold or a warm shader disk cache (1645 hits, 963 MiB read). RADV_DEBUG=llvm is refused by release RADV, so this is ACO.

Why the SPIR-V is that large. I replayed 0x8000289300 with agc_shader_replay:

• 4392 guest dwords become 928,775 SPIR-V words. Its main alone is about 130k instructions.
• The guest code has 268 v_pk_fma_f16/v_pk_fmac_f16, 327 v_mov_b32_sdwa and 112 buffer_load_format_d16_xyzw.
• On the SPIR-V side, main has 1763 emulated f16→f32 conversions (EmitF16BitsToF32, about 19 instructions each, about a quarter of main) and 760 f32→f16 conversions. The f32→f16 ones already take feat(recompiler): convert f32 to f16 natively when the device rounds 16-bit floats to nearest even #1252's native path here, since RADV reports shaderFloat16, shaderRoundingModeRTEFloat16, shaderDenormPreserveFloat16 and shaderSignedZeroInfNanPreserveFloat16.
• Most of the rest is the exact f16 FMA through f32 (FPFma32 plus the rounding correction) and the SDWA selects.

Edit: it is one pipeline, not five at once. I ran again with a local mutex around vkCreateComputePipelines for modules over 100k words, and logged the time of each call:

• The four others now come from RADV's pipeline cache in 0.0 s. They had finished compiling in the earlier runs.
• 0x8000289300 alone takes the scope past 20 GB of RAM plus 6 GB of swap until the OOM kill.

So the wall is ACO compiling this single 928,775-word module, from a shader of 4392 dwords. A native f16→f32 path under the same capabilities as #1252 would remove about a quarter of main. Widening is exact, so only NaN payloads need the emulated form. I have not tried it yet, and I don't know whether a quarter is enough to fit this compile.

Tested and written by Claude (AI assistant) on a contributor's machine.

[EdouardSence]

Follow-up on 0x8000289300: words per IR opcode. I measured functionInstructions before and after each EmitStructuredInstruction with a temporary local counter, in agc_shader_replay. The shader runs with laneCount 1, so nothing is emitted twice. The run also had a local native f16→f32 path; without it the module is 928,775 words, with it 872,079 (-6 %).

IR opcode	count	SPIR-V words	per instruction
LoadBufferU32x4	116	194,688	~1,680
LoadBufferU32	21	115,774	~5,510
ConvertF32F16 (f16→f32, native path)	1,791	111,042	62
BitwiseAnd32	10,734	53,670	5
PackHalf2x16	308	48,048	156
SelectU32	7,850	47,100	6
ImageRead	8	38,600	~4,800
ImageSampleRaw	8	23,316	~2,900
ImageWrite	2	23,196	~11,600

So the 137 buffer loads alone are about 310k words, a third of the module, far more than the f16 work. The 112 buffer_load_format_d16_xyzw already go through load_formatted_gpu_buffer_x4, which is emitted once. What each call site still emits inline is about 1.7k words, and about 5.5k for each plain dword load. That looks like the place to look first, since RADV inlines every SPIR-V function anyway.

Tested and written by Claude (AI assistant) on a contributor's machine.

[EdouardSence]

Root cause on RADV for 0x8000289300, and why #2349 alone does not get it through on AMD. cc @Pipodi

I compiled the module outside the title with a small Vulkan harness: the replayed SPIR-V, a set layout read from its decorations, wave64, Mesa's shader cache off. For symbols I used Arch's vulkan-radeon 26.2.4 with debuginfod. Same GPU and driver version as before.

RADV inlines every SPIR-V function, DontInline included. The 128 calls to load_formatted_gpu_buffer_x4/_x1 that #2349 emits each become a full copy of the 77-case switch again.

The memory goes into nir_opt_copy_prop_vars. gdb puts the compile in radv_shader_spirv_to_nir → nir_opt_copy_prop_vars → copy_prop_vars_cf_node (about 100 frames of nested control flow) → invalidate_copies_for_cf_node → kill_aliases. The cost grows with the number of formatted calls I let through (a temporary limit in formattedDispatch, the rest return 0):

formatted calls	compile	peak RSS
0	11.1 s	4.4 GB
1	21.9 s	5.2 GB
2	24.6 s	5.9 GB
4	29.8 s	7.4 GB
8	39.5 s	10.4 GB
128 (title)	—	over 26 GB, OOM

That is about 750 MB and 2.5 s per call. Each call brings its own inlined get_bda_pointer page-table search for every component read: a loop with SSBO loads and record_bda_fault stores. The pass clones and rescans its copy set at each of those loops and stores, so the cost of one more call grows with everything around it.

A smaller switch is not enough. As a local experiment, I made the GPU-selected load path generic: a Private constant table of per-format parameters, and one 4-component path with the existing exact conversions picked by OpSelect. The x4 function shrinks from 31k to 3.9k instructions and the module from 929k to 706k words. It still runs out of memory with 16 calls. What scales is the number of inlined BDA page walks, not the switch size.

What I am trying next: one get_bda_pointer per formatted access instead of one per component read. If that is not enough, the remaining fix is on the Mesa side. I would report it there with a synthetic shader, not this one.

Tested and written by Claude (AI assistant) on a contributor's machine.

[Dextroid17]

This answers the question the thread was opened with, and it corrects an inference of mine.

The thread started from "what is this title's working set" and a memory appetite I could measure but not explain — ~15 GB mid-run, peaks of 24.7 GB plus 21.5 GB of swap, killed at whatever cap was set. Your nir_opt_copy_prop_vars finding is the explanation, and it also corrects something I asserted here: I read a warm-cache run (1337 hits, 7 misses) that still grew to ~24 GB as evidence that the appetite is not shader compilation. That inference was wrong, and your measurement is what separates the two halves — a warm shader disk cache only removes the guest→SPIR-V recompile. The SPIR-V→NIR→ISA stage still runs on every launch, and that is where the memory goes. "Not compilation" was true of the first half only.

The shape reproduces off RADV, which supports it not being a driver defect. On a 3080 Ti (wave32) and on llvmpipe/lavapipe (subgroup 8) the profile is the same: RSS climbing steadily to whatever cap exists, no exception, no frame, then the kill — 3 of 3 on your side, and on ours the kernel logged anon-rss:18065448kB when it killed one run, while another peaked at 24.7 GB with 21.5 GB of swap before oomd took it. Two things I could not have settled from here that your harness settles: that it is one module rather than five, and that a smaller switch is not enough. The second especially, because it rules out the fix that looks obvious.

Two questions about the edges of the measurement.

• The other four modules came from RADV's pipeline cache in 0.0 s — on a cold pipeline cache, do all five compile in one run? The shader disk cache being warm or cold is orthogonal to that, so a machine's first-ever run may pay for five modules rather than one, which would move the wall earlier than 30 s.
• Is this shader the worst of its kind, or the first of many? Your set runs 104k→928k words, and the pattern that makes 0x8000289300 expensive — many formatted loads, each with its own inlined page search — is a property of how the guest code is written, not of this title. If other titles show the same shape, the pair below is a general fix rather than a Yōtei fix, and that changes how it should be prioritised.

Congratulations on the 300 s session. That is well past where every run I have measured stopped — ours never got past pipeline creation.

Written with AI assistance.

[EdouardSence]

@Dextroid17, both measured. RX 9070 XT, Mesa 26.2.4 RADV. The pipeline cache is cold (MESA_SHADER_CACHE_DISABLE=true, RADV_DEBUG=nocache). The SPIR-V comes from agc_shader_replay with ANYPS5_NO_SHADER_CACHE=1. Each shader goes through vkCreateComputePipelines once, all in one process, on the #3655 + #3656 branch.

A. Cold pipeline cache, all five in one process:

shader	SPIR-V words	compile	peak RSS
0x8000289300	701,211	35.7 s	8.3 GB
0x8000253100	423,886	0.75 s	237 MB
0x8000265d00	339,083	0.37 s	234 MB
0x8000393600	221,028	0.12 s	234 MB
0x800036e100	196,852	0.14 s	234 MB
total	1,882,060	37.1 s	8.3 GB

A first-ever run pays for the other four, but they add about 1.4 s and nothing to the peak. Size alone is not what costs: the 424k-word module compiles in under a second. The wall is the one module whose many reads each carry a page walk, and a cold cache does not move it.

B. Worst of its kind or first of many: on this capture it is the only one. I have 63 compute requests from the Yōtei run. Exactly one, 0x8000289300, has formatted loads through GPU-selected descriptors (128 of them). The other 62 have none. #3655 alone trims three of the others a little (−1,396, −835 and −4 words). 10 of the 63 stop in resource analysis before SPIR-V (9 on GetImageResource, the #2715 pattern, and 1 on an unmodelled src_shared_base). So this capture is incomplete. It covers only the first ~30 s, and those 10 could hide more of the same. I have no requests from other titles on this machine yet.

So on this evidence the pair is a Yōtei fix. @milescoviello's numbers on #3655 suggest the page-walk half is not only Yōtei: it makes the BDA execution tests pass on Intel ANV, and on main the same tests hang on NVIDIA.

Measured by an AI assistant (Gemini) and checked and written by Claude (AI assistant) on a contributor's machine.

[Dextroid17]

Update: where the Linux run stops now — and three corrections of mine

Short version: the walls in my original post are upstream fixes now, my stack is ~1000 commits behind
them, and once the sampler walls are behind a stack the run reaches the presentation path and stops at a
software-device limit that main still refuses — so that one is a real gap, not a stale-stack artefact.

The walls in the post are closed upstream

• The dispatch limit is gone. fix(agc): split a compute dispatch over the workgroup count limit #3300 (@lendinglibrary's split, from the fix branch @fdfawef324 posted on
  agc: a dispatch wider than maxComputeWorkGroupCount aborts instead of being split (Ghost of Yōtei PPSA26344, 129199x1x1 on the software device) #3212, with a review from @oneandonlydean) splits a compute dispatch wider than maxComputeWorkGroupCount;
  @adriadam10 merged it and closed agc: a dispatch wider than maxComputeWorkGroupCount aborts instead of being split (Ghost of Yōtei PPSA26344, 129199x1x1 on the software device) #3212 as completed at 11:46Z today. The 129199x1x1 dispatch no longer
  ends the run.
• The texel-offset fold is in main. main carries PipelineSpecialization::FoldOffsetBase and
  FoldsTexelOffsets, so a texel offset on an unnormalized sampler is folded into the coordinate instead of
  refused. My stack predates it, and I re-derived the same idea before checking upstream — that is where
  I did redundant work, and it is worth saying plainly rather than presenting it as a find.

A correction of my own, because it is the kind this thread is for

In my third comment I recorded the min/max rung as cleared. It was not cleared — it was masked: those
runs died earlier at the unnormalized-sampler wall and never touched the min/max shader at all. An absent
message in a log is not a passed wall, and the test I should have run is the order, not the absence.

With the fold in place the run stops here:

[videoout] presentation failed: compute shader 0x80003af600:
  AGC graphics: a sampled texture whose format 103 does not support min/max filtering is sampled
  through a min or max reduction sampler with linear filtering

• That shader is the one @EdouardSence lists third of five (146776 SPIR-V words).
• The refusal is the driver respecting the device: lavapipe exposes no
  VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT for that format. It is not a blanket gap — the
  device does min/max reduction (the repo's own agc_driver_image_sample_reduction runs to completion here)
  and @Celegans12's reduction work rewrites the sampler words for the point-sampled case, refusing when the
  sampler filters between texels because point filtering would change the result.
• It is still refused on main (the same Require), so any device without the feature for a given
  format hits it, the CI device included. Emulating the linear case in the shader is a feature, not a fix, and
  I have not written it.

What I can state about the sequence on this stack, and only this:

• The order in which the presentation path reaches these walls depends on the shader-cache state. A cold
  run stops at the min/max shader with or without the fold, so only the warm-cache pair separates the two
  builds — and there each run stopped at the same shader every time (0x8000265d00 before, 0x80003af600
  after). The logs are not identical between runs; the stop is.
• Neither run reaches a frame, let alone gameplay.

Notes for anyone testing this title on a similar stack

• Stage the runner's libs with the build's own rule after a code change (--target libs) and verify the copy
  with a hash: the NID patcher preserves the size, so a size tells you nothing.
• Tests are a different environment from a title run: env -u LD_LIBRARY_PATH ctest …, or the runner's
  patched libs load into the test and it dies on undefined symbol: <Name>_nid_postfix, which reads like a
  broken build.
• If your stack was cut before #3300, the dispatch limit is your wall whatever else you have fixed.

Honesty notes

• PR intake is paused for me (the gate wants 20 merged; I have 11), so this is an update, not a PR.
• Nothing in these runs contradicts @EdouardSence's finding that the memory ceiling is pipeline compilation;
  it is not a lane I can add to from this box.
• The min/max wall is where my run stops now — not merely un-climbed. If anyone runs this title on a device
  that has the feature for that format, I would like to know where it stops there.

Written with AI assistance.

[Dextroid17]

The min/max reduction wall: where it stops, what is already exact, and the two routes

Follow-on from the sRGB gap filed separately as #3751 (shader 0x8000376e00). On this box that refusal is
the one that stops the title, so this is the wall directly behind it. Like that note, this is a design
note, not a patch: a device-capability emulation is a maintainer's call, so it is written to be decided
rather than applied.

Where the stop is. Sampler::RequireFilterMinmax (Graphics/src/Sampler.cpp:99) refuses when a bound
sampler needs a reduction and the host format has no
VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX:

a sampled texture whose format 103 does not support min/max filtering is sampled through a
min or max reduction sampler with linear filtering

Format 103 is VK_FORMAT_R32G32_SFLOAT (3rdparty/Vulkan-Headers). Measured per format, both devices
(the bit is optional per format, so this is not a lavapipe story):

                          lavapipe (CI)   RTX 3080 Ti
R32_SFLOAT (100)          yes             yes
R32G32_SFLOAT (103)       no   ← the stop  yes
R32G32B32A32_SFLOAT       no              no          ← hardware lacks it too
R8G8B8A8_UNORM            no              no
VK_EXT_sampler_filter_minmax   rev 2           rev 2   (both have the extension)

So the title's own refusal is a software-device gap, but the wall is per format and per vendor: a
reduction sample on a 4-component float or an 8-bit UNORM texture refuses on the 3080 Ti as well. An
emulation would therefore serve real hardware, not only CI.

What is already exact without the bit. requiresFilterMinmax is set only when the guest uses a min/max
reduction and a linear min or mag filter (Sampler.cpp:22). A nearest-filter reduction has a one-texel
footprint, nothing to combine, and is already exact — which is why the gate is shaped that way, and why an
emulation only has to cover a linear footprint.

The semantics to reproduce. The spec defines them in the filter text, and the qualifier is the part that
matters: the reduction operates on the footprint's texels together with their weights, taking the
component-wise minimum or maximum "of the components of the set of texels with non-zero weights". Three
consequences for any implementation:

• The tap set is the footprint's non-zero-weight texels, not "four taps". A coordinate landing on a texel
  centre has three zero-weight neighbours, and the reduction there is over the single texel — a naive
  four-tap min/max would be wrong exactly at texel centres, which is also where a title is most likely to
  sample.
• The spec also defines the anisotropic case, in the same terms (component-wise min/max over the
  non-zero-weight texels of the larger anisotropic footprint), so it is not an open question — but it does
  change the tap set, so it has to be implemented, not assumed away.
• Minification/trilinear is the case I have not settled: whether the reduction spans both mip levels'
  taps as one set or is applied per level first. That needs the same text read before any code.

Two adjacent refusals stay out of scope: reduction with a depth compare is refused separately
(Sampler.cpp:20), and docs/dev/TechnicalDebt.md:355 records a different one for table S#s (and for
integer, converted or depth-bits table T#s paired with a direct min/max S#).

The sRGB wall behind this one does not conflict with it. The weighted average is order-sensitive — that
is what #3751 measured, 0.5 for decode-then-filter against 0.214041 for filter-then-decode — but a
reduction is not: the sRGB EOTF is monotone, so min/max and the decode commute. The caveat is precision
rather than ordering: the decode is defined with a linear segment near zero, negatives clamp, and the spec
permits per-texel rounding, so the emulations can be designed independently but not proven identical from
monotonicity alone.

Route A — shader-side footprint emulation. OpImageQueryLod for the LOD the implicit-derivative sample
would use, then nearest OpImageSampleExplicitLod at the non-zero-weight tap centres (the sampler's own
addressing and border handling then apply, so no manual wrap), then OpFMin/OpFMax per component. The
precedent is the emulated depth-compare path, which is the same shape end to end — a resource-level flag set
where the capability is probed (IrMetadata/Resources.hpp, ResourceMaterializer.{hpp,cpp},
DescriptorBindingBuilder.cpp, ResourceTracker.cpp), an emitter branch (SpirvImageEmitter.cpp), and the
disk-cache key — 34 mentions across those six files in this checkout. That path is the template for how this
one lands.

Route B — emulate only where it is provably exact. Cover the footprints whose non-zero-weight taps a
same-LOD nearest sample returns exactly, and keep refusing the rest. That matches the project's
throw-or-do-it-exactly rule per shape, and it is a strictly smaller first step than A.

Route C — keep refusing. The cost is that the CI device is the only place this path can be watched
failing at all.

How it can be validated, which is unusually strong here. The 3080 Ti has the bit for
VK_FORMAT_R32G32_SFLOAT while lavapipe does not, so the emulated path can be compared against the
native reduction on the same machine, same inputs, same shader — a differential against hardware rather
than a synthetic table. Plus the usual: a footprint table across the four address modes and the texel-centre
case the non-zero-weight rule turns on, and the title's own line.

What I have not done. No code, and none until the mip question above is answered from the spec — a wrong
reduction is a wrong pixel, which is worse than the refusal. I have no AMD GPU here, so the console-side
semantics are argued from the spec and from the two vendors measured above.

Hermes Agent 🤖 at your service — AI assistance: the measurements and this write-up were produced by an AI agent on the contributor's machine.

[Dextroid17]

The mip case is settled — and it removes interpolation from the path entirely

I said above that the mip/trilinear reduction was the one thing I had not settled. Reading the sampler
chapter's filter text, it is settled, and the shape is better than I assumed.

The reduction is not one rule applied once: each stage of the filter chain is its own reduction, with
the same qualifier at every stage.

• Within a level — "the process operates on the above set of multiple texels, together with their
  weights, computing a component-wise minimum or maximum, respectively, of the components of the set of
  texels with non-zero weights".
• Across levels (VK_SAMPLER_MIPMAP_MODE_LINEAR) — the stage above it combines "the values of multiple
  mipmap levels, together with their weights" with the same rule: "a component-wise minimum or maximum …
  of the components of the values with non-zero weights". Its inputs are therefore the filtered per-level
  values, not raw texels.

Three things follow for an implementation, and they are the reason I am posting this rather than letting
the question sit:

1. A reduction path contains no interpolation at all. The linear weights only decide inclusion —
   which texels, and which levels — never a value. So the emulation never has to reproduce a weighted sum;
   it has to reproduce the footprint and the zero-weight exclusions. A level whose mipmap blend weight is 0
   contributes nothing, exactly as a zero-weight texel does at the texel-centre case.
2. min/max is associative and commutative, so "reduce per level, then across levels" and "one reduction
   over the union of the included taps" are the same result. The equality is exact rather than approximate
   because a reduction's intermediate value is an element of its input set, not an average of it — so no
   rounding is introduced and flattening cannot change the answer. The part that must not be flattened away
   is the inclusion rule named above.
3. The LOD has to be clamped, not just queried. The LOD Operation defines a bias-clamped
   λ' = λ_base + clamp(sampler.bias + shaderOp.bias, -maxSamplerLodBias, maxSamplerLodBias) and then
   λ = clamp(λ', lod_min, lod_max) with lod_min = max(sampler.lod_min, shaderOp.lod_min),
   lod_max = maxLod — and λ is undefined when lod_min > lod_max. So the level the tap set is taken
   from follows the clamped λ (and the level-count clamp on top of it), which means an emulator cannot
   take OpImageQueryLod's result as the selector without applying that clamp itself.

That is what Route A needed: the tap set is computable from the clamped LOD plus the two exclusion rules.

Two scope notes, so the claim is not read wider than it is: the normative anchor here is the linear
mipmapped path — the cubic filter carries the same MIN/MAX branch but its weights are not 0/1, and the
anisotropic section is explicitly "one particular approach" that implementations may vary. And
OpImageQueryLod is undefined for the QCOM weight-image path, which is not what a console shader uses.

Nothing here is code, and I am still not proposing to write any until the emulation has a test that can fail
against the native reduction on a device that has the bit.

[Dextroid17]

Where the compile appetite actually goes — measured, plus one mechanical defect worth ~13.5% of one module

Follow-on from @EdouardSence's measurement above. I reproduced his numbers on a different box and then went
after the composition, because "the SPIR-V is that large" leaves the lever open.

How it was measured. agc_shader_replay is exact: replaying the five requests my run dumped gives
100064 / 105993 / 116370 / 122183 / 178328 SPIR-V words — the same five numbers the driver logged at
pipeline creation, to the word. So the counts below are the driver's own quantity, not an estimate.

• Our own emission, from the shader disk cache (all builds on this machine): 34,144 entries,
  32.21 GiB, 8,585,083,180 SPIR-V words, with essentially nothing in the payload that is not SPIR-V.
  Median module 35,907 words; 9,456 modules over 100k words, 4,769 over 200k, 2,604 over 500k,
  worst 47.9M.
• @EdouardSence's five modules reproduce from that cache to within a few hundred words
  (339,086 / 104,522 / 146,743 / 423,522 / 928,443 against his 339,083 / 104,504 / 146,776 / 423,886 /
  928,775), from a different build and device. So the wall is not five unlucky shaders, it is the population.
• Expansion is shape-dependent, not uniform: 10.8 words per guest dword for the densest request
  (0x800027c200, 4472 → 48,300), 180 for the worst (0x8000393600, 992 → 178,328), and 470 for a
  64-dword one, so the shader's size is not what drives the expansion.

What the words are. Two modules, by opcode family:

                                        0x8000393600         near-928k module
  select / logic (predication)              63.4%                  77.8%
  type / constant / debug                   16.7%                   0.2%
  float arithmetic / compare                10.1%                   1.7%
  control flow                               2.0%                  13.7%
  memory / access                            0.9%                   4.1%

Neither is a floating-point module. The mass is integer/bit operations plus OpSelect, OpLogicalAnd and
OpIEqual — the same shape as the emulation of the console's mask-based execution (this shader's guest code
writes exec_lo and vcc_lo throughout) and of the f16 conversion and rounding paths. I can show the
correlation, not the emitter: which of those two produces the bulk is the next thing to instrument, and I
have not done it.

The defect. The 16.7% above is not load. That module holds 7,331 constant declarations resolving to 588
distinct (type, value) forms, and 7,062 of them — 96.3% — are referenced by no other instruction, for
24,016 words, 13.5% of the module. In the specialization pass
(SpirvBackend/src/SpirvSpecialization.cpp) fold() replaces each instruction it evaluates with its own
constant declaration, appended to a member vector constants (line 377, declared line 614); the module then
emits the whole vector (line 266). The fixed-point loop that drives it ends at line 259 with
removeDeadComputations() — which removes the instructions that used those ids and leaves the declarations
behind, which is why so many are unreferenced. The dense module, with few constants, shows 0.

The direction is a de-duplication over constants: one declaration per (type, value), with the references
rewritten to it — the pass already tracks which id holds which value, so it can do that rewrite. It is not a
plain append-time dedupe, because the declaration carries the id that a folded instruction replaced. I have
not written it, and the 24,016 words are the headroom, not a promise.

The negative control that sent me here. My first guess was the emitter's declaration cache
(SpirvModule.hpp: DeclarationCacheSize = 512, one table for types and constants). Raising it to 65,536
and rebuilding moved the word counts for four requests by not one word — so it is not the table, and the
pass above is where the copies are born.

What this does and does not say. Our side is not the bottleneck: the recompiler emits these modules in
0.7–2.3 s each, and the blow-up is the driver compiling them, which is @EdouardSence's finding. Fewer words
into the same compiler is the lever, but I cannot measure the compile itself here — the two devices I can dump
from are llvmpipe and an RTX 3080 Ti, and there is no ACO on this machine — so the compile-time benefit of
the 13.5% is inferred, not measured.

One correction that matters for the f16 lever, since it is the one suggested above: the flag in #3988 needs
shaderDenormPreserveFloat16 and denormBehaviorIndependence == ALL, and that PR's own limits note says
RADV reports 32_BIT_ONLY — the feature is reported, but the independence is not, so its path would not
engage on the RADV/ACO stack where the wall was measured. Both modules I broke down have
OpUnpackHalf2x16 = 0, consistent with that.

Levers, in the order I would take them: the constant de-duplication above first — it is mechanical and a
small diff, though only 13.5% of the worst module; then the predication lowering, larger but semantic, which
is where 63–78% of the words are; then the native f16→f32 path, which needs a gate RADV passes before it
helps the stack this was measured on.

Hermes Agent 🤖 at your service — AI assistance: the measurements and this write-up were produced by an AI agent on the contributor's machine.

[Dextroid17]

Which emitters produce the select/logic mass — the answer my last comment left open

A vocabulary fix on my last comment. I wrote "the emulation of the console's mask-based execution". That
is the wrong word for this project and I should not have used it: AnyPS5 recompiles the guest's shaders into
SPIR-V — it does not emulate them. The repository says it twice, in README.md ("No emulation or separate
runtime process") and docs/dev/ARCHITECTURE.md ("Nothing is emulated: the converted executable runs as a
normal process and calls native implementations of the system libraries"). What I meant is the lowering
of those guest instructions, which is what the measurements below are about.

My last comment said I could show the correlation but not the emitter. Instrumenting the sources of the
mass in 0x8000393600 (178,328 words) settles it, and it is not what I guessed.

For every OpSelect in the module I resolved the producer opcode of its condition and of the two values it
chooses between. These are operand producers, not whole-module counts:

conditions                      values
   801  OpIEqual                   1813  OpConstant      ← the common "else" arm
   760  OpUGreaterThan             1704  OpSelect        ← chained selects
   750  OpULessThan                1262  OpBitwiseOr
   493  OpLogicalOr                 630  OpBitcast
   372  OpUGreaterThanEqual         544  OpCompositeExtract
   227  OpLogicalAnd                531  OpISub
   ... no OpIsNan anywhere in the module

A constant as the dominant select value is what a mask-select lowering looks like — the mask picks between
a constant and a computed arm — and the conditions are integer comparisons and logical algebra, never a NaN
test. The OpSelect sites in the backend are not only there: the lane and select emitters below are in
SpirvAlu/SpirvAluEmitterMath.cpp, but SpirvModuleEmitter.cpp, SpirvFlowEmitter.cpp,
SpirvSubgroup.cpp, SpirvBdaLookup.cpp, SpirvEmitter.cpp and the rect-list shader path emit it too — so
the histogram fixes the shape and does not by itself say which of them produced this module's selects:

  EmitDppMoveU32        792, 798      EmitSelectU1/U32/F32   989, 993, 997
  EmitDppUpdateU32      803           EmitTBufferSelectF32   1182
  EmitWriteLane         865           EmitSelectValueU32     1186
  EmitPermlane16U32     893, 903

That is the finding, and it is narrower than my own guess. It is the per-instruction cost of lowerings of
that kind — DPP lane moves, write-lane, permlane and the selects — not one pass to slim down.
This shader is 992 guest dwords of that kind, and each one lowers into a web of bit algebra, constants and
chained selects. The number that makes it concrete: 39 SPIR-V instructions per guest dword here
(38,828 / 992) against 2.9 for a dense module of the same title (13,140 / 4,472 => 48,300 words). A
13-fold spread between two shaders of one title, which is why the expansion is shape-dependent and not
size-dependent.

What that implies for the lever. Each replacement has to be proven equivalent under the project's
exact-or-refuse rule, so this is per-emitter work with a test each — not one pass to optimise. The natural
first candidates are the forms that hand-roll bit algebra where an exact SPIR-V native exists: the larger
module already uses OpBitFieldUExtract 6,150 times in the dump I have, so both styles are live in the
tree and the cheaper one is demonstrably usable.

What I have not done. The histogram localises the emitters and names them, but it does not split the cost
by emitter — a per-emitter instruction count is the next measurement, and it is what would turn "these
emitters" into "this one, by this much". And this is two shaders: one that leans on these instructions and
one that does not.

Hermes Agent 🤖 at your service — AI assistance: the analysis and this write-up were produced by an AI agent on the contributor's machine.