RESIDENT EVIL requiem (PPSA31246)

[QRMOE]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

RESIDENT EVIL requiem (PPSA31246)

Content version tested

01.200.000

AnyPS5 commit

main 88795ed with #10935, #10304, #9950, #11199, #11369 and #11485 merged, and the merge of #8898 reverted locally (on current main the title stops at boot; #11580 implements the missing path).

System tested

Windows 11 Home 26200, WinLibs GCC 15.2.0 r7 (Release), AMD Radeon RX 9070 XT (AMD 32.0.31021.1015, Vulkan 1.4.349), Ryzen 7 9800X3D

Furthest point

Menu

What is shown

Logos, then the main menu (Main Story, Bonuses, Options, PlayStation Store) at about 5 fps at 3840x2160; pad input works and the menu can be navigated. Parts of the menu background are drawn as black blocks. Main Story > New Game > Standard shows the "requiem" title card, then a black screen while the title keeps drawing and reading data at about 1 fps; gameplay was not reached. One run left there for about 40 minutes stopped on VK_ERROR_OUT_OF_DEVICE_MEMORY (host imports about 4.5 GB over a 2.7 GB budget).

Current blocker

Open pull requests the title needs, in the order it hits them:

• fix(libScePad): return an error for unsupported port probes #10935 (pad port probes)
• fix(agc): keep buffer owners when a staged address space dissolves #10304 (buffer owners when a staged address space dissolves)
• feat(agc): publish a written native multisample D32 depth surface to its guest planes on access #9950 (publish a written native multisample D32 depth)
• fix(shader): keep pixel helper lanes out of guest lane masks #11199 (pixel helper lanes in guest lane masks; GPU hang, AGC: RESIDENT EVIL requiem (PPSA31246) loses the device in a 160-index draw into its 1920x1080 scene target during the intro #11052)
• fix(agc): release a resident multisample depth before a GPU buffer may write over it #11369 (resident multisample depth under a GPU buffer write: guest writes over native multisample depth are not implemented after the logos)
• fix(shader): load and store 16-bit data of converted packed images #11580 (on main since fix(shader_recompiler): pack format 11_11_10 float image stores in shader #8898, a boot stop: compute shader ...: reads or writes a converted float image with 16-bit data, which is not implemented)

Performance: #11485 (menu 214 → about 185 ms per frame). Remaining: the slow story load after New Game and the out-of-memory stop, not yet investigated; the black blocks on the menu background.

How it was run

python tools/unwrap_self.py eboot.bin eboot.elf
relinker --windows --registry eboot.elf app.exe

app.exe next to the title's app0/ and the built libs/, started from that folder. Runs used APS5_LOOP_GUARD=100000 and a separate ANYPS5_SHADER_CACHE_DIR; nothing beyond the usage guide was needed.

[QRMOE]

Update: the opening cutscene, and where the time goes

Same machine (RX 9070 XT, AMD 32.0.31021.1015, Ryzen 7 9800X3D, 32 GB RAM, Windows 11 26200). Tree: main 74acfad with #10935, #10304, #9950, #11199, #11369, #11485 and #11580 merged. That needs two local-only changes, neither proposed:

• libSceHttp2 from 88795ed: current main's sceHttp2SendRequestAsync throws, and the title calls it about 150 s in.
• A bypass of the MSAA_ENABLE on a single-sample target for primitives other than triangles and rectangles refusal: the opening cutscene draws a line list (VGT_PRIMITIVE_TYPE 2) that way. I don't know the hardware's line rasterization there, so the bypass isn't a fix.

With #11580, current main no longer stops at boot on the converted 11_11_10 float image.

Furthest point: the opening cutscene ("FBI Midwest Field Office"), through to the next area's load. Skipping a shot needs triangle held for about 90 s at these frame rates.

Settings: APS5_LAZY_SHADER_PREPARE=1 APS5_NO_GPL=1, taken from the Resident Evil Village thread (#5169). Without them the title prepares about 30,000 shaders after New Game. The pipeline library store keeps every library, so committed memory reaches 58-61 GB, and the cutscene runs at 3.0-3.4 s per frame. With them it prepares about 4,200 shaders, uses 27.8 GB, and runs at 0.95 s per frame.

Where the time goes in the cutscene (warm caches, unprofiled, APS5_TRACE_SUMMARY_EVERY=30):

• About 1,060 draws and 265 dispatches per frame. GPU busy is about 140 ms per frame; queue worker 0x0 is about 100% busy.
• APS5_PIPELINE_STATS: each draw costs about 1.1 ms on the draw committer (3,100-3,500 commits per 10 s). Its samples (APS5_SAMPLE_COMMITTER) put nearly all of that in ShaderResources::ShaderResources: prepareAddressBindings / GuestBufferMemory::AcquireRegistered, then buildComplete and resolveImageTables. Queue worker 0x0's samples are mostly waits in DrawPipeline::Drain and Enqueue.
• APS5_TRACE_DRAW_CACHE: 0 hits out of 7,000-10,000 lookups per 10 s. About 99% of the misses are "no entry: user words/pointers only". The register-key miss lines show user data changing on 4,000-5,500 misses per 10 s.
• A temporary counter at the data-hit branch (Draw.cpp, decode == nullptr && drawDataHits() && !drawParameters.indirect) put every one of those misses in the indirect-draw bucket. This title's draws are almost all indirect, and indirect draws are excluded from several fast paths in Driver::draw:
  • data hits;
  • shape refresh (shapeNeedsEntry);
  • draw recipes (registerKey && !drawParameters.indirect);
  • the draw finisher hand-off;
  • the queue-0 draw pipeline. pipelined && !drawParameters.indirect, then drainBeforeInline(), so each indirect draw drains the committer and is recorded inline.

Tried, as local experiments:

• Indirect draws on the data-hit path. With APS5_VERIFY_DRAW_DATA_HITS=1 there were no mismatches over a 10-minute run: 380-560 data hits per 10 s, 0 stages reused, 760-1,120 compiled. Without verification the cutscene ran slower, at 1.5-2.8 s per frame against 0.95-1.1 s at the same presents. Each draw points at its own per-object constants, so the stages' captured reads never hold, and the relocation path (content-keyed) can't match them either.
• APS5_NO_PIPELINE_LTO=1 without APS5_NO_GPL: memory grew about 1.6 MB per shader instead of about 3.5 MB.

So in this title the per-draw resource build runs for every draw, on two threads in lockstep. Reusing a draw's resource layout with new buffer addresses, and letting indirect draws through the draw pipeline, look like the changes that would matter here. I haven't attempted either.

AI-assisted: yes (Claude Code).

[QRMOE]

Screenshots from today's run: Main Story > New Game > Standard (Modern), into the opening cutscene, skipped forward by holding triangle.

These are the frames the title presented, read back with APS5_DUMP_FRAMES (960×540). Settings are as in the description: APS5_LAZY_SHADER_PREPARE=1 APS5_NO_GPL=1. The build is main 74acfad with #10935, #10304, #9950, #11199, #11369, #11485 and #11580 merged, plus the local-only libSceHttp2 and MSAA-lines workarounds listed in #11795.

Main menu. Readable and navigable. There is block corruption in the background on the right.

Opening cutscene, FBI Midwest Field Office. The scene renders. Blocks of stale or wrong tiles show in the sky and along the bottom edge.

Office cutscene. The characters render, with horizontal smearing on the clothing.

Later in the same cutscene. The hands are detailed. Bands and blocks of an older image show through.

A conversation in the office, a little later. Not every frame shows artifacts: this one renders cleanly.

The blocks and bands look like regions that keep an earlier frame's contents, or are never written. I haven't traced them to a cause yet. Frame times in this run were 1-4.5 s, slower than usual because a build was running on the same machine. #11795 has the CPU-side analysis.

AI-assisted: yes (Claude Code).

[QRMOE]

The block corruption and the white glare both come from the clear-key hand-over (#7427). With APS5_NO_CLEAR_HAND_OVER=1 the menu and the whole opening cutscene render cleanly. It's the same bug as Ghost of Yōtei's glare in #9860; its candidate fix is #9999, which I'm testing on this title next.

How I narrowed it down:

• Same build and settings, one switch at a time on the main menu, where the blocks show within a minute.
• I tried the three main defaults the Ghost of Yōtei branch turns off. Only APS5_NO_CLEAR_HAND_OVER=1 changed anything. With APS5_NO_RESIDENT_LINEAR=1 or APS5_NO_DEFERRED_SETTLES=1 the menu was still covered in blocks.
• Then I ran the full opening cutscene with the switch. Each pair below is the same build, left with main's defaults, right with the switch.

The cutscene pairs are the same dump index from two runs. The cutscene runs on wall-clock time, so the shots can be a few seconds apart, but each pair is the same part of the scene.

A correction to my screenshots above: the hazy, snow-like look of the FBI building, the "hands over fire" shot and the long white screens were all the glare, not the scene.

• The building has a blue sky and a dark road.
• The "fire" shot is hands on a keyboard.
• The white screen is an "Investigation Summary Report" document ("Fourth Victim of Unidentified Disease").

The black bands and stale tiles in the office scenes are gone as well.

Settings for this title are now APS5_LAZY_SHADER_PREPARE=1 APS5_NO_GPL=1 APS5_NO_CLEAR_HAND_OVER=1.

The build is the local tree from the description: main 74acfad with #10935, #10304, #9950, #11199, #11369, #11485, #11580 and #11357, the two local workarounds, and an address-space change I'm measuring for a separate PR. RX 9070 XT, AMD 26.6.2, Windows 11 26200. The remaining blockers are unchanged: about 1.2 s per frame in the cutscene (#11795), and a GPU memory wall loading the area after the intro.

AI-assisted: yes (Claude Code).

[QRMOE]

Past the memory wall: with #12074 the title gets through the load after the opening cutscene and reaches the next area, a rainy city street. #9999 is on top, so it renders without the corruption.

Without #12074, that load filled both GPU heaps and aborted on a failed heap-mirror slab allocation (-2) every time. With it there's no allocation failure, at 35 GB committed. Details are on #12074.

The build is the same local tree as in my previous comment, plus #12074 and #9999. Settings are APS5_LAZY_SHADER_PREPARE=1 APS5_NO_GPL=1; with #9999, APS5_NO_CLEAR_HAND_OVER isn't needed.

Still open:

• speed, about 1.2 s per frame in the cutscene (perf: RESIDENT EVIL requiem cutscene at ~1 s per frame: about 1 ms of resource building per draw, and its indirect draws miss the draw cache #11795);
• the intermittent VOP2 opcode is not implemented abort after New Game, fixed on main by fix(shader): skip undecodable words that only follow s_branch or s_endpgm #11112;
• one close-up with a few remaining blocks.

AI-assisted: yes (Claude Code).

[QRMOE]

Gameplay reached, with the HUD, then a growing slowdown from texture-cache churn.

After the street shot in my previous comment, the title is in player control. The objective "Head to the Wrenwood Hotel" is shown, and the inventory opens with the SBS M232 handgun. This is a frame dump at 480×270, scaled up:

The build is the same as in my previous comments: the local tree with #11357, #12074 and #9999, and APS5_LAZY_SHADER_PREPARE=1 APS5_NO_GPL=1.

The problem: in this area every frame is slower than the last. The median frame time, by time since launch:

Since launch	~20 min (arrival)	~25 min	~30 min	~37 min	~52 min	~90 min
Frame time	7 s	21 s	32 s	48 s	81 s	159 s

What a stack sample of the draw committer shows (APS5_SAMPLE_COMMITTER, about 40 minutes in). The draw committer spends its time building each draw's resources:

• ShaderResources::buildComplete → resolveImageTables → cachedTexture → Texture::Texture, where textures are created again and again.
• Import and address-space work is only about 3%.

The [texture] counters (APS5_PROFILE_DRAW).

• About 10,000 textures were created up to the end of the opening cutscene.
• By 40 minutes it was 882,800, nearly all of them fresh uploads.
• So the area's textures are rebuilt every frame, and more of them each frame as the area streams in.

Where the memory goes.

• The sampled-texture cache is pinned at its 2,048 MiB floor.
• Device-local heap 1 has 13.5 of 14.3 GB in use.
• Cached storage images hold 4,751 MiB, above their own 3,764 MiB storage budget.

With APS5_TEXTURE_CACHE_MIB (which sets both the sampled and the storage budget):

APS5_TEXTURE_CACHE_MIB	Frame time in the area	Outcome
unset (2 GB sampled floor)	7 s, climbing to 159 s	ran 90 min
3072	about 5 s for about 5 minutes, up to 27 s, then 15–17 s at 45 min (the default was 60–66 s then)	no allocation failure in 45 min
6144	flat at 6–7 s for about 10 minutes	aborted after 31 min: a 128 MiB vkAllocateMemory failed with -2, host-visible heap 15.29/15.39 GB

So the area's sampled working set is somewhere between 3 and 6 GB, and APS5_TEXTURE_CACHE_MIB=3072 is the best setting tried so far on this machine. Making room for it here means the storage-image cache has to give back what it holds over budget. Another option is to build one texture per surface, not one per dynamic-resolution size (#6099/#10256, which cut Wolverine's storage-image builds from 62,675 to 1,044). Both are driver changes, not settings. All of this is one run per setting on one machine (RX 9070 XT, 16 GB VRAM, 32 GB RAM).

AI-assisted: yes (Claude Code).

[QRMOE]

Filed the texture-cache churn from my previous comment as #12190, with the stack sample, the [texture] counters, the budget lines and the code path. In short, the storage-image cache holds more than its budget and nothing trims it back, so the sampled cache sits at its 2 GiB floor and rebuilds this area's textures every frame. Until that is fixed, APS5_TEXTURE_CACHE_MIB=3072 is the best setting I've found for this title on a 16 GB card.

AI-assisted: yes (Claude Code).

[QRMOE]

Slowdown on the loading card and in the first level: the cause in my 02:45 post was incomplete, and a budget prototype

Same rig as before: RX 9070 XT (16 GB), AMD 26.6.2, Windows 11 26200, Ryzen 7 9800X3D. The play tree is main 74acfad65b plus the PRs listed earlier, #12074 and #9999, with APS5_LAZY_SHADER_PREPARE=1 and APS5_NO_GPL=1, a default texture cache and no profiling. The pad script only skips cutscenes. Correction (edited): in the runs from builds with #11112 (the trim, the diagnostic and the prototype runs here), the game sits on the first level's loading card ("Facing the Past") for a long time after New Game, and only then goes into the level, the rainy street. The trim run reached the level after about 20 min and the prototype run after about 30 min. The earlier default-cache and APS5_TEXTURE_CACHE_MIB=3072 runs never showed the card and were in the level throughout. So in the table below, the prototype's +5 to +20 columns are on the loading card and its later columns are in the level, while the default and 3072 rows are in the level. Those columns don't compare like with like.

Correction. At 02:45 I said the sampled-texture cache sits at its 2 GB floor because storage images are held over their budget. That is not the main reason.

• Trimming storage made it worse. I tried trimming idle, non-dirty storage images down to the storage budget on every cache hit, the direction proposed in AGC: textures refused by a full sampled-texture cache are rebuilt on every lookup within the same present (RESIDENT EVIL requiem) #12190. Storage then stayed inside its budget (2850 to 3060 MiB), but the sampled budget still read 2048 to 2358 MiB. Frame time at 45 min was 159 s/frame, against 63 s on the same build without the trim. I have not opened it as a PR.
• Why: SampledTextureBudget (ShaderResources.cpp) subtracts max(TextureCacheBudget, storage bytes) and budget / 8. TextureCacheBudget is a quarter of the heap: 4076 MiB on this 16 GB card. So about 4 GB stays reserved for storage images even when they hold less. At the end of a default run: a heap budget of 14099 MiB, minus 7045 MiB of other use, minus the 4076 MiB reserve, minus 1762 MiB of headroom, leaves 1216 MiB. That is under the floor, so the cache gets the 2048 MiB minimum.

What uses the device-local heap. I logged every vkAllocateMemory/vkFreeMemory by call site with a local diagnostic (not for upstream), 27 min into a default run. The heap reported 13217 MiB in use.

	MiB
storage images	3463
sampled textures	3045
device buffers (BufferPool), of which ~1400 idle in the pool's device tier, which keeps up to heap/8 = 1927 MiB	2345
heap mirrors (#12074), rising during gameplay	928
unit shadow slabs, depth targets and copies, other	~1300
not from AnyPS5's allocations (driver: pipelines, descriptors, swapchain)	~2150

Prototype (local, not a PR yet): (A) reserve the storage images' actual bytes instead of max(heap/4, storage), and (B) when a sampled texture doesn't fit, free device-tier pool buffers that have been idle for a second (BufferPool::ReclaimIdleDevice, which the storage cache already uses), then read the budget again. The sampled budget then moved between 2.2 and 3.1 GB, the cache filled it, storage stayed at about 2.96 GB, and the run had no out-of-memory error.

p50 frame time of the 30 s summary interval. Minutes are counted from the first frame over about 5 s, because the cutscene skips take a different time in each run. One run per build.

minutes after the slowdown starts	+5	+10	+15	+20	+26
default cache	12.9 s	31.8 s	39.4 s	51.2 s	63.1 s
storage trim	6.1 s	14.0 s	~30 s	~100 s	~90 s
prototype A+B	14.5 s	8.3 s	7.0 s	12.7 s	24.1 s
APS5_TEXTURE_CACHE_MIB=3072	5.3 s	13.5 s	18.8 s	16.1 s	15.3 s

The prototype holds 7 to 13 s for about 20 minutes, against 30 to 60 s at default, but it climbs again after that (43 s and then 64 s in the last 3 minutes, at +32 min). The forced 3072 MiB budget stays flat, so something else keeps growing. The heap mirrors are the category that grew in the diagnostic run, so I'll look at them next, before turning A and B into PRs.

AI-assisted: yes (Claude Code)

[QRMOE]

Follow-up: why the prototype climbs again late, and the bigger cost behind the slowdown

Device-local use was flat in the second half of the prototype run (12.2 to 12.9 GB in use, sampled budget 2.5 to 3.0 GB), so the late climb isn't a memory squeeze, and it isn't the heap mirrors growing.

What does track the frame time is how many sampled textures get created. The run's stdout logs one line per Texture (Texture.cpp:356), so I counted them between frame dumps, which come every 20 presents:

run, window	creations per present	distinct textures	creations per texture per present
default cache, 35 to 56 min	120,000	1,027	117 (up to ~720 for some 2048x2048 ones)
prototype, 16 to 21 min (slow phase)	27,400	790	35
prototype, 28 to 32 min (the ~7 to 8 s/frame plateau)	881	831	1.1

Per 5 minutes, the prototype's distinct texture addresses went from about 730 to about 1,640 at 30 to 40 min, and the creation rate went from 40,000 back up to 390,000. The game's texture working set grew past the larger budget, and the rebuilds came back. Edited: in this run the prototype left the level's loading card for the level itself at about 30 min. That move is the jump in distinct textures, so the late climb is the level's larger texture set bringing the rebuilds back, after the lighter card.

The multiplier is the important part. Once the sampled cache is full of textures used in the current present, admitTexture turns new ones away ("used uncached"), and an uncached texture is rebuilt at its next lookup. In this title most draws resolve image tables, so the same texture is rebuilt dozens to hundreds of times within one present. The budget only decides when that starts. Keeping a texture that was turned away alive for the rest of its present, so later lookups in that present reuse it, would cap this at about one rebuild per texture per present whatever the budget. That's what I'll look at next. It's a generic cache change, not one for this title.

AI-assisted: yes (Claude Code)

[QRMOE]

The texture fix from my last two posts is up as draft PR #12575: a texture the full sampled cache refuses is kept for the rest of its present instead of being rebuilt on every lookup. On my integration tree (with an earlier version of it) the first level held 10.5–13.6 s/frame, flat for 45 minutes, against 30–60 s and climbing without it. The clean main-vs-PR A/B is still to come.

AI-assisted: yes (Claude Code)

[QRMOE]

Where the level frame goes (profiling update, Windows / RX 9070 XT, local branch with #12575 and per-entry image-table reuse from #6340)

Level frames are about 10–12 s (0.08–0.10 fps). I sampled both driver threads in the first level (APS5_SAMPLE_COMMITTER / APS5_SAMPLE_WORKER, about 5 minutes each):

• Draw committer: waiting for work about 63% of the time. It runs about 1,200 commits per 10 s at about 2.6 ms each. Most of that is resource resolution in ShaderResources (image tables, cachedTexture about 7%, DepthSurfaceTexture about 2.4%).
• Queue worker 0:
  • about 35% waiting on the committer (DrawPipeline::Enqueue and Drain);
  • about 13% waiting for the GPU mutex (dispatches, FlushForAccess);
  • about 17% drawing CPU-path indirect records itself: only the last record of an indirect draw is queued, the others drain and draw inline;
  • about 16% re-materializing the patched stage for each record.

Tried and not helping:

• Keeping 256 image tables per thread instead of 4: table reuse rose to 37%, but frames didn't improve. Tables are dropped at every collect epoch, about every 6–7 draws here.
• Queuing every indirect record on the committer: the committer saturated instead (about 6 ms per commit) and the scene loaded no faster.

The two threads mostly take turns, because draw recording runs under the global GPU mutex that the worker's own GPU work also needs. Moving work between them doesn't speed the frame up. What would help is less work per draw under the lock: resource resolution, and the roughly 117 sampled textures re-created per second in this level, about 0.66 ms each just to allocate. #9248 (patched user word as push data) would remove the per-record re-materialization.

A visual issue to look at separately: in the level, triangle edges show on most meshes (coats, umbrella, faces).

[QRMOE]

Why requiem's draws never reuse anything across frames (draw cache diagnosis)

Nearly every draw builds its resources from scratch: 971,000 ShaderResources builds in one run. The draw cache gets 0 hits in the first level, and draw recipes get 0 hits. I counted per frame with temporary instrumentation, during the loading card and in the level:

• Keys: the full draw key matches the previous frame's for 0% of draws, even within a frame. The shape key (registers without the user words) matches for about 95–99%, and the shader set for about 99.7%. So the draws are the same every frame and only the user-data pointer words change.
• Where the draws go (112k draws): about 44% are CPU-path indirect draws, which cacheDrawStages never caches. About 38% are refused by admitDrawKey, 17% are admitted, and about 1% hit.
• Relocation (DrawRelocate.cpp): it's learned for only 22 shader sets. It's applied to 8–45% of lookups and is never productive, because the alias key hashes the content read through the moved words, and that content changes every frame.
• Resource cache: it stays at its 1,024-entry floor. It grows only when evicted keys come back, and here they never do, so it isn't too small. Its keys just don't repeat.

So the reuse machinery is there, but its keys include per-frame data. Reuse across frames here needs that per-frame data (moved buffer bases and the values read through them) treated as refreshed inputs rather than as part of the key. The CPU-path indirect draws also need to be cacheable; #9243 does that behind APS5_DRAW_CACHE_INDIRECT.

Separately, the refused-texture fix in #12575 now keeps refused textures alive while frames keep using them. That cut sampled-texture rebuilds from about 118k to about 15k per run, but level frames barely changed (10.7–11.4 s against 10.9–12.3 s).

[QRMOE]

Draw-cache follow-up: #9243 and a local port of #5609 on requiem

• perf(agc): cache CPU-path indirect draws behind APS5_DRAW_CACHE_INDIRECT #9243 alone (APS5_DRAW_CACHE_INDIRECT=1): CPU-path indirect draws now enter the draw cache (about 330 inserts per 10 s), but hits stay at 0. Their keys change every frame like the others.

• perf(agc): reuse cached draw stages when only buffer base addresses moved #5609 ported onto our tree: it needed main's SRT tape bypassed while user-data use is traced. The tape records the reads but not the source leads, read instructions or operand reads that perf(agc): reuse cached draw stages when only buffer base addresses moved #5609 uses to find buffer base words, so its own agc_driver_draw_cache_moved_buffer test got 0 hits on current main until the bypass.

  • With the bypass, 11 of the 12 draw-cache tests pass with 0 VUID- errors. The exception is agc_driver_draw_cache_relocation_evicted from fix(agc): let draw relocation aliases name a cached key, not hold its entry #9396, because perf(agc): reuse cached draw stages when only buffer base addresses moved #5609's stage donors outlive evicted entries by design.
  • In requiem, hits went from 0 to roughly 1–2% of lookups during loading. Not enough to change frame times.

• Why so few: of about 70,000 cached stage variants:

  • 84% have no buffer base words the recompiler can attribute to a single source;
  • 10% are skipped because main's stage-data hits record dataPositions before tagBufferWords runs, and tagBufferWords returns on a variant that already has them;
  • 6% are tagged.

  So most of what changes frame to frame behind the moved user-data pointers is not a recognisable buffer base address.

Reusing these draws across frames would need the per-frame data behind those pointers treated as refreshed input in general, not just buffer bases.

[QRMOE]

#9243 + #9248 help requiem by about 10%

With #9243 (APS5_DRAW_CACHE_INDIRECT=1) and #9248 (APS5_DRAW_CACHE_PUSH_WORD=1) on top of the refused-texture fix (#12575), the first level runs at about 0.11 fps on the on-screen counter, up from 0.09–0.10. In the log, level frames went from 10.4–11.7 s to 8.2–9.9 s once the scene settled.

#9248 forwards about 2,400–2,600 indirect-record words per 10 s as push data instead of re-materializing the stage. About 1,850–2,000 stages per 10 s are still re-materialized, and about 3,600–3,900 words are refused because the shader reads the patched word as an address or value. Those refused words are the next thing to look at, because the worker that re-materializes them limits the frame here.

The draw-cache tests these two touch (agc_driver_draw_cache_reuse*, agc_driver_draw_cache_relocation*, agc_driver_pipelined_indirect_draw, agc_driver_draw_data_hit*) pass 18 of 18 with the validation layer and 0 VUID- errors on this branch.