fix(agc): reuse a recycled descriptor set only for a table of its own size by SleglJan · Pull Request #6567 · boykopovar/AnyPS5

SleglJan · 2026-10-15T20:56:03Z

What

DescriptorCache::AllocateRewritten handed out any recycled set of the requested layout. PrepareDrawBindings takes that path for the snapshot sets of recorded draws (every draw unless APS5_SYNC_DRAWS is set).

The variable descriptor count of an image-table binding is fixed when its set is allocated.
PrepareDrawBindings writes the table's present elements, up to its current element count, into whichever recycled set it gets.
A draw whose table has more elements than the table the recycled set was allocated for can write descriptors past the set's allocation. That is undefined behaviour in Vulkan, and the validation layer reports it as VUID-VkWriteDescriptorSet-dstArrayElement-00321.

A set from a chain pool now records the variable count it was allocated with, as a dedicated-pool set already does since #6454. Recycled sets are kept per layout and variable count, so a draw reuses a set only for a table of the same size, and allocates otherwise.

A recycled set is reused only on an exact count match, not for a smaller table.
The sets kept for reuse are now counted per layout and table size, instead of per layout.

Tested

Linux 7.2.10 (CachyOS), RTX 3080 with NVIDIA 615.78.08, GCC 16.2.1, Release, BUILD_TESTING=ON.

Rebased onto main 8a526d4, after perf(agc): share one image table per heap and write epoch through capture, compare, resolution and descriptors #6454 merged. Arch Linux container on a 16-thread Xeon E5-2640 v3, GCC 16.2.1, Release, lavapipe (Mesa 26.2.4).
- main plus only the test hunk: agc_driver_graphics and agc_descriptor_cache fail with a recycled descriptor set served a larger variable image table than it was allocated for.
- With the change, both pass, and so do agc_descriptor_pool_reset_failure and agc_compute_descriptor_layout_flags.
- ctest -R 'agc|shader|recompiler|request|tess': this change 747 of 765 pass, and main 8a526d4 built the same way also 747 of 765. Both fail the same 18; the container does not permit userfaultfd, and 15 of them report guest memory that is not write-watched or needs to be.
- The results below are from the earlier head, on older main.
agc_driver_graphics (descriptorCacheTests, mock device) has a new case: a set allocated for a 3-element table is recycled, then the same layout is asked for with 5 elements and again with 3.
- On main fa9365c it fails with a recycled descriptor set served a larger variable image table than it was allocated for.
- With the change it passes: the 5-element table gets a new set, and the 3-element table reuses the recycled one.
ctest -R '^agc': 596 tests, 1 failure, 1 skipped. agc_driver_store_over_untracked fails on main too (test(agc): wait for the actual image in repeated untracked stores #6359, test(agc): keep waiting for the neighbour copy case's result #6385), and agc_driver_stencil_ref_export is skipped.
007 First Light's menu to frame 260 does not reach this case:
- the base was main 4186f06 with local changes the title needs, plus fix(agc): keep each set's image table writes in its own draw snapshot… #6537's change, without this one;
- the run used the validation layer and a local check of every image-table write against its set's allocated count;
- the check found no write past a count, and the layer did not report dstArrayElement-00321.
- The 00321 messages 007 showed before came from fix(agc): keep each set's image table writes in its own draw snapshot… #6537's cause. This change rests on the test above.
Demon's Souls (PPSA01341), run by fma-rc on main 5d9dcc4 (fix(agc): reuse a recycled descriptor set only for a table of its own size #6567 (comment)):
- on main it crashed on the driver thread in 4 of 6 runs once it reached character creation;
- with a guard-page allocator, both runs on main faulted in the same scene of the opening cinematic, on a store 16 bytes past a 0x208-byte block inside vkUpdateDescriptorSets from ShaderResources::PrepareDrawBindings;
- with this change, two runs with the same steps went through that scene to the end (1550 s) with no fault;
- agc_driver_graphics passes on an RTX 5080 (NVIDIA 615.78.08), a Radeon 610M (RADV) and lavapipe.
Demon's Souls (PPSA01342) on Windows, run by fdfawef324 (Windows Server 2025, RTX 3060, NVIDIA 591.86, MinGW-w64 GCC 15.2.0, Release; main a5e2a80 plus other PRs and a local change, listed at fix(agc): keep each set's image table writes in its own draw snapshot… #6537 (comment)):
- without fix(agc): keep each set's image table writes in its own draw snapshot… #6537 and this PR, all 6 runs died between 190 s and 1491 s (4 heap corruption, 2 access violations); 5 of the 6 changed a setting or the stack, as listed in that comment;
- with both, 2 of 4 runs reached the 3000 s limit in-game; the other two ended on a texture out-of-memory and a device loss that haven't been tied to either PR. Every run with the fix had both PRs, so these runs can't tell the two apart.
Death Stranding 2 (PPSA02015), run by fma-rc on their DS2 stack, Linux, RTX 5080 (fix(agc): reuse a recycled descriptor set only for a table of its own size #6567 (comment)):
- without this change, runs died on glibc heap errors: corrupted double-linked list at 470 s, and munmap_chunk(): invalid pointer at 390 s with MALLOC_CHECK_;
- with it on the same stack, three runs went 460, 536 and 1280 s with no heap error. They ended on device memory (AGC: one draw resolves a 21,489-entry image table into 14.6 GiB of textures and runs the device out of memory #6890) and later stops.
The new test on main 55b968a with RADV on a Radeon 680M, run by fma-rc: main plus only the test hunk fails 3 of 3 runs with a recycled descriptor set served a larger variable image table than it was allocated for. With the change it passes 3 of 3, and main alone, without the test hunk, passes 3 of 3.
Demon's Souls (PPSA01341 v1.07) on Linux, run by fisherjoey (Nobara 44, kernel 7.2.0, RTX 5070 Ti, NVIDIA 595.91.07, GCC 16.2.1, Release; main 93e54ce, from before fix(agc): keep each set's image table writes in its own draw snapshot… #6537, plus fix(agc): keep texture images inside their extent's mip chain #6280's driver commit b9badf4 and a local stencil patch that doesn't touch descriptors; fix(agc): reuse a recycled descriptor set only for a table of its own size #6567 (comment)):
- without this change, 5 of 5 runs died in the first tutorial level between 366 s and 680 s: glibc heap checks in three, SIGSEGV in two; 4 of the 5 changed one setting or the stack, as listed in that comment;
- with 544e7af cherry-picked, swapping only libSceAgcDriver.prx, the run reached the 900 s stop with no heap message, core or device loss. Their own patch with the same ShaderResources.hpp/.cpp hunks, written before they found this PR, did the same in 3 of 3 runs;
- the level ran at 0.80 fps median in both arms;
- agc_descriptor_cache, agc_driver_graphics, agc_descriptor_pool_reset_failure and agc_compute_descriptor_layout_flags pass on lavapipe with 544e7af on main ccb0c09.

fix(agc): keep each set's image table writes in its own draw snapshot… #6537 (merged) fixed another cause of the same validation message: PrepareDrawBindings paired the fragment image table's write with the set-0 binding.
perf(agc): share one image table per heap and write epoch through capture, compare, resolution and descriptors #6454 (merged) added std::optional<std::uint32_t> variableCount to SetAllocation for its kept sets and set it on dedicated-pool sets. This change keeps that member, fills it on Allocate's two chain-pool returns (a hit in an existing chained pool, and a new chained pool), and keys recycled by layout and count. Pooled sets keep a null layout and no sizes, as on main.

Checklist

🤖 Generated with Claude Code

github-actions · 2026-10-15T21:03:03Z

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 1395	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 4040	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 5441	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 5499	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 5500	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 5925	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6146	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6177	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6188	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6192	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6194	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6202	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6223	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6235	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6292	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6340	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6548	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6563	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6612	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6615	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6639	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6647	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6683	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6718	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6762	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6801	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6808	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6820	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6937	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6946	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6947	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 6970	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 6972	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7002	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7085	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7154	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7254	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7256	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7258	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7332	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp` `core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7340	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7390	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7410	`core/libs/prx/libSceAgcDriver/tests/Graphics.cpp`
PR 7484	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7618	`core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7642	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7650	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`
PR 7689	`core/libs/prx/libSceAgcDriver/Graphics/include/ShaderResources.hpp` `core/libs/prx/libSceAgcDriver/Graphics/src/ShaderResources.cpp`

fma-rc · 2026-10-16T07:14:27Z

Demon's Souls (PPSA01341) reaches this. On main 5d9dcc4 it crashes on the driver thread in 4 of 6 runs once it reaches character creation, as a SIGSEGV in the decode memo walk or double free or corruption, so something was overwriting the heap.

I ran it with a small LD_PRELOAD allocator that ends every 0x1f0..0x210-byte block at a PROT_NONE page. It runs slower that way, and both runs on main faulted earlier, in the same scene of the opening cinematic (~1360 s): a store in libnvidia-glcore 615.78.08 16 bytes past a 0x208-byte block, inside vkUpdateDescriptorSets called from ShaderResources::PrepareDrawBindings (from recordDraw / Graphics::Draw). That is the write past a recycled set's variable count you describe.

With this PR on the same main, two runs with the same steps went through that scene to the end (1550 s) with no fault. agc_driver_graphics passes on an RTX 5080 (NVIDIA 615.78.08), a Radeon 610M (RADV) and lavapipe.

SleglJan · 2026-10-16T07:33:15Z

Thanks @fma-rc, that's the first title reported to reach this, and the guard-page runs pin it to the same write. I added your result to Tested.

AI-assisted: yes (Claude Code)

fdfawef324 · 2026-10-16T10:24:18Z

A Windows data point to go with fma-rc's: Demon's Souls (PPSA01342), RTX 3060, NVIDIA 591.86, Windows Server 2025 (26100), MinGW-w64 GCC 15.2.0, Release. The per-run table is on #6537. Every run with the fix had both this PR and #6537 cherry-picked (patch-identical to 544e7af and 9800f3a), so these runs can't say which one matters for this title.

Stack: `main` `a5e2a80` + other PRs and a local change (listed on #6537)	Runs	Result
without #6537 / #6567	6	all died between 190 s and 1491 s: 4× 0xC0000374 (heap corruption), 2× access violation
with both	4	2 ran to the 3000 s limit with no fatal, in-game; 1 texture out-of-memory at 683 s (#6481 now faults such an entry); 1 `VK_ERROR_DEVICE_LOST` at 778 s (still looking into it)

One access violation (d4) is a write fault inside nvoglv64.dll, at the same call as fma-rc's guard-page fault. The first libSceAgcDriver return address on the stack is ShaderResources::PrepareDrawBindings+0x1df9, right after its only vkUpdateDescriptorSets call. This PR's cause and fix(agc): keep each set's image table writes in its own draw snapshot… #6537's both write through that call, so the site doesn't pick between them.
The other access violation (d1) is a read fault in VulkanDevice::PrepareDispatch; we can't tie it to either PR.
The crashes without the PRs don't look like commit running out. Windows logged no low-memory event (2004) during any of these runs. Commit stayed at least 41.7 GB free until the last 25 s before each crash, and in those last 25 s it fell as low as 15.2 GB.

AI-assisted: yes

SleglJan · 2026-10-16T10:33:17Z

Thanks @fdfawef324, a second platform and driver on Demon's Souls: with #6537 and this PR, 2 of 4 runs reached your 3000 s limit, where all 6 without died. I added your result to Tested, with your note that these runs can't tell the two apart.

AI-assisted: yes (Claude Code)

fma-rc · 2026-10-17T22:07:49Z

Death Stranding 2 (PPSA02015) reaches this too, Linux, RTX 5080. On my DS2 stack without this PR, runs died on glibc heap errors (corrupted double-linked list at 470 s, munmap_chunk(): invalid pointer at 390 s with MALLOC_CHECK_). With the PR on the same stack, three runs went 460, 536 and 1280 s and none hit a heap error. They ended on device memory (#6890) and later stops.

The test also holds on current main 55b968a, RADV on a 680M: main plus only your test hunk fails 3/3 with a recycled descriptor set served a larger variable image table than it was allocated for, main plus the PR passes 3/3, main alone 3/3.

SleglJan · 2026-10-17T22:13:41Z

Thanks @fma-rc. Death Stranding 2 is the second game reported to reach this, after Demon's Souls, and the RADV runs show that the test holds on current main too. I've added both to Tested.

AI-assisted: yes (Claude Code)

fisherjoey · 2026-10-18T09:34:17Z

Demon's Souls (PPSA01341 v1.07) on Linux hits this too. Here the base has neither #6537 nor this PR, so the runs separate the two causes.

Setup: Nobara 44 (kernel 7.2.0), RTX 5070 Ti, NVIDIA 595.91.07, GCC 16.2.1, Release. The base is main 93e54ce plus #6280's driver-side commit b9badf4 and a local one-file stencil patch that doesn't touch descriptors. That main predates #6537 (merged 2026-10-18). Every run used the same route (title, character creation, the first tutorial level), the same warm shader cache and the same stop at 900 s, with no compiler running on the host.

Without the change, 5 of 5 runs died in the level between 366 s and 680 s on glibc heap checks: corrupted size vs. prev_size twice (680 s, 452 s), free(): invalid pointer once (366 s) and SIGSEGV twice (415 s, 393 s). In 4 of the 5, the frame content stopped changing first (at about 275 s in three runs, 366 s in one) while [present] and the draw counters kept going, and the abort came 85 to 140 s later. Four of the five runs carried one extra change each (no b9badf4 in one, then APS5_STORE_AT_FLIP=1, #6926 or #6931 cherry-picked). None of them changed the outcome.

With this PR's commit 544e7af cherry-picked onto that base, and only libSceAgcDriver.prx swapped, the run reached the 903 s stop and exited 0: no heap message, no core, no device loss. A patch of ours with the same ShaderResources.hpp/.cpp hunks, written from the same vkUpdateDescriptorSets write before we found this PR, did the same in 3 of 3 runs (two crash checks and one profiled run, 900 s each). So on this base it's 4 of 4 clean with the fix and 5 of 5 crashed without it, same night, same procedure. The level frame rate was 0.80 fps median in both arms (the title is CPU-bound here), so the change costs nothing we can measure.

Your agc_descriptor_cache case passes on lavapipe (Mesa 26.2.1 llvmpipe) with 544e7af cherry-picked onto main ccb0c09, along with agc_driver_graphics, agc_descriptor_pool_reset_failure and agc_compute_descriptor_layout_flags.

AI-assisted: yes (Claude Code)

SleglJan · 2026-10-18T09:53:31Z

Thanks @fisherjoey, I've added your runs to Tested. Like fma-rc's earlier Demon's Souls runs, yours are on a base without #6537, so the fix arm has this change and not #6537's. The Windows runs had both and couldn't tell them apart.

AI-assisted: yes (Claude Code)

fisherjoey · 2026-10-19T02:30:19Z

#6454 has landed on main, so this is now the "whichever lands second" case from the description. The bug is still there on main 40393b0: SetAllocation has std::optional<std::uint32_t> variableCount and the new kept-set path compares it, but recycled is still keyed by layout alone, and the two chain-pool returns in Allocate leave variableCount empty. A recycled set can still go to a draw whose table is larger than the one it was allocated for.

Here is how we resolved it on our local stack, keeping main's struct:

recycled becomes std::map<std::pair<VkDescriptorSetLayout, std::uint32_t>, std::vector<SetAllocation>>.
AllocateRewritten looks up {layout, variableCount.value_or(0u)}, and Recycle files the set under {layout, allocation.variableCount.value_or(0u)}.
Both chain-pool returns in Allocate fill in the count: return {set, pool.handle, index - 1, updateAfterBind, VK_NULL_HANDLE, {}, variableCount, {}}; and the same for chain.size() - 1. The dedicated-pool return on main already records it.

With that on main 40393b0 (plus #6280 and #6926, which don't touch descriptors), lavapipe passes 1535 of 1536 tests. The one failure is application_heap_lazy, which also failed on our previous stack. We haven't run Demon's Souls on this rebased build yet, so the game result in my earlier comment is from the older base.

AI-assisted: yes

… size DescriptorCache::AllocateRewritten handed out any recycled set of the requested layout. The variable descriptor count of an image-table binding is fixed when its set is allocated, and PrepareDrawBindings writes the table's present elements, up to its current element count, into the set it gets. A draw whose table had more elements than the table the recycled set was allocated for could write descriptors past the set's allocation (VUID-VkWriteDescriptorSet-dstArrayElement-00321). A set from a chain pool now records the variable count it was allocated with, as a dedicated-pool set already does, and recycled sets are kept per layout and variable count, so a rewritten draw reuses a set only for a table of the same size. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

SleglJan · 2026-10-19T03:02:48Z

@fisherjoey thanks. The rebase is pushed as 04aef89 on main 8a526d4, and it is the resolution you describe:

main's std::optional variableCount stays;
recycled is keyed by layout and the set's variableCount.value_or(0u) in both AllocateRewritten and Recycle;
the two chain-pool returns in Allocate now fill in the count.

On a Linux container with lavapipe, main 8a526d4 plus only the test hunk fails agc_driver_graphics and agc_descriptor_cache with a recycled descriptor set served a larger variable image table than it was allocated for. Both pass with the change. With the change, the wider agc|shader|recompiler|request|tess set fails the same 18 of 765 tests as main built the same way. Details are in the description.

AI-assisted: yes (Claude Code)

Capmare · 2026-10-19T12:50:14Z

Confirming this on a title: Marvel's Wolverine (PPSA03671), Linux, NVIDIA GeForce RTX 4070 SUPER (driver 615.71.09), on a tree with #7395. Before this change the game died at about present 580, during the first build of an image table with 12,447 entries. The host heap was corrupted, and the crash site changed from run to run. With VK_LAYER_KHRONOS_validation the cause shows as VUID-VkWriteDescriptorSet-dstArrayElement-00321: pDescriptorWrites[106].dstArrayElement (12438) + descriptorCount (1) is larger than pDescriptorCounts (12435) for a recycled set.

I found it independently and made the same change locally: the recycled sets are keyed by layout and variable count. With it, 6 of 6 runs of 240 seconds survive. Before, 6 of 6 crashed at about 110 seconds. So this PR fixes the crash that stops Wolverine there.

EagleBearerYS mentioned this pull request Oct 15, 2026

perf(agc): share one image table per heap and write epoch through capture, compare, resolution and descriptors #6454

Merged

11 tasks done

SleglJan mentioned this pull request Oct 15, 2026

fix(agc): keep each set's image table writes in its own draw snapshot… #6537

Merged

11 tasks done

Dextroid17 mentioned this pull request Oct 15, 2026

AGC: on lavapipe, released descriptor sets stay allocated in chain pools that still hold a live set (about 30 per frame in Ghost of Yōtei PPSA26344) #6608

Closed

MarcZX10 mentioned this pull request Oct 15, 2026

fix(agc): free released lavapipe descriptor sets #6614

Merged

11 tasks done

github-actions Bot added the agc libSceAgc* label Oct 16, 2026

Scramblrrrr mentioned this pull request Oct 16, 2026

perf(agc): reuse eligible image table entries independently #6340

Open

11 tasks done

SleglJan mentioned this pull request Oct 16, 2026

feat(agc): store to images selected through image tables #6402

Merged

11 tasks done

Ondra97 mentioned this pull request Oct 17, 2026

fix(agc): release unpublished descriptor cache objects #7148

Merged

12 tasks done

This was referenced Oct 18, 2026

perf(agc-driver): join a buffer bound from inside a range across the ranges it crosses #5372

Open

perf(agc): partition relocation runs by tagged address #7508

Draft

github-actions Bot added the needs rebase Conflicts with main, rebase needed label Oct 19, 2026

fisherjoey mentioned this pull request Oct 19, 2026

fix(agc): keep texture images inside their extent's mip chain #6280

Draft

12 tasks done

SleglJan force-pushed the pr/rewritten-set-variable-count branch from 544e7af to 04aef89 Compare October 19, 2026 02:59

github-actions Bot removed the needs rebase Conflicts with main, rebase needed label Oct 19, 2026

SleglJan mentioned this pull request Oct 19, 2026

perf(shader): reuse an image table column's records while its words are unchanged #6440

Closed

11 tasks done

adriadam10 self-assigned this Oct 19, 2026

adriadam10 merged commit fdf64db into boykopovar:main Oct 19, 2026
11 of 12 checks passed

SleglJan mentioned this pull request Oct 19, 2026

fix(agc): wait for the display buffer's GPU writers before the presentation lock #7643

Draft

12 tasks done

SleglJan mentioned this pull request Oct 19, 2026

fix(agc): reserve only the sampled textures alive from the storage image budget #7862

Merged

12 tasks done

fisherjoey mentioned this pull request Oct 19, 2026

fix(agc): fail a template's proof on a released texture and audit it with the full walk #8047

Merged

12 tasks done

Navigation Menu

Repository navigation

fix(agc): reuse a recycled descriptor set only for a table of its own size - #6567

fix(agc): reuse a recycled descriptor set only for a table of its own size#6567
adriadam10 merged 1 commit into
boykopovar:mainfrom
SleglJan:pr/rewritten-set-variable-count

SleglJan commented Oct 15, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 15, 2026 •

edited

Loading

Uh oh!

fma-rc commented Oct 16, 2026

Uh oh!

SleglJan commented Oct 16, 2026

Uh oh!

fdfawef324 commented Oct 16, 2026

Uh oh!

SleglJan commented Oct 16, 2026

Uh oh!

fma-rc commented Oct 17, 2026

Uh oh!

SleglJan commented Oct 17, 2026

Uh oh!

fisherjoey commented Oct 18, 2026

Uh oh!

SleglJan commented Oct 18, 2026

Uh oh!

fisherjoey commented Oct 19, 2026

Uh oh!

SleglJan commented Oct 19, 2026

Uh oh!

Uh oh!

Capmare commented Oct 19, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

SleglJan commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Tested

Related

Checklist

Uh oh!

github-actions Bot commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fma-rc commented Oct 16, 2026

Uh oh!

SleglJan commented Oct 16, 2026

Uh oh!

fdfawef324 commented Oct 16, 2026

Uh oh!

SleglJan commented Oct 16, 2026

Uh oh!

fma-rc commented Oct 17, 2026

Uh oh!

SleglJan commented Oct 17, 2026

Uh oh!

fisherjoey commented Oct 18, 2026

Uh oh!

SleglJan commented Oct 18, 2026

Uh oh!

fisherjoey commented Oct 19, 2026

Uh oh!

SleglJan commented Oct 19, 2026

Uh oh!

Uh oh!

Capmare commented Oct 19, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

SleglJan commented Oct 15, 2026 •

edited

Loading

github-actions Bot commented Oct 15, 2026 •

edited

Loading