Repository navigation
Puyo Puyo Tetris 2 (PPSA01530): a 14-word image-descriptor dispatch runs with the fill kernel's program (no shader load before it in its submission) #3709
Description
Follow-up to the request on #425 for an issue with the descriptor and the program address.
Title/state. Puyo Puyo Tetris 2 (PPSA01530) on Windows. With PR #425 applied (my local stack, an older main plus #425 as it was at 09:50 UTC, not Michon's rebase) the title passes #1409 and stops with:
compute shader 0x1417c4300: buffer descriptor uses an unsupported type
The V# at index 0 is 02100b00 c3c00000 010dc1df 91b00fac.
What the dwords are. As Michon noted, dword 3 has type 0x9 in bits 31:28. Read as the first four dwords of a T#: base 0x2100b0000, width 1920, height 1080 (dword 2 packs width-1 and height-1 as 0x1df/0x437, with the low two width bits in dword 1), identity swizzle, 2D. The following user-data words 00000000 00700000 00000000 00000000 also fit the second half of that T#. So this is a complete image descriptor in COMPUTE_USER_DATA_0..7, not a V#.
Where it comes from (traced, not guessed). I dumped the request with APS5_DUMP_SHADERS=1 and traced every PM4 packet and every write to COMPUTE_USER_DATA_* and the program registers. The shader at 0x1417c4300 is a dword-pattern fill kernel (64x1x1, the one MatchDwordPatternFill matches) that takes a V# in s[0:3], the pattern in s[4:7], a count in s8 and a period in s9. All earlier dispatches of it in the log have a proper V# (1e0c0000 00040002 0021c000 00014004, stride 4, type 0).
The failing dispatch sits at the end of one queue-0 submission (493 dwords in my run):
- offset 7:
LOAD_SH_REG_INDEX(0x63) from0x2049fe000, 13 pairs, setsCOMPUTE_PGMto0x200169d00(a 14-user-data image kernel; the same one that runs fine at the start of two other submissions, where its0x63is followed directly by the 14 user-data words and the dispatch); - offsets 78 to 374: four times (user data,
LOAD_SH_REG_INDEXfrom0x1417c04a0, 10 pairs, which setsCOMPUTE_PGMto0x1417c4300, dispatch); - offset 405:
SET_SH_REGwith 14 words (02100b00 ..., then00000003 0004dfac 049fcfe0 00000002), offset 421:DISPATCH_DIRECT, with no program load in between.
So the last dispatch runs with whatever program the fourth fill left in COMPUTE_PGM, while its user data is the layout of the 0x200169d00 kernel. The register-list reads are not the cause: I re-read every 0x63 list at execution time and compared it with the one the driver caches at submission, they are identical.
What I could not establish. On the console the same packet stream would also end with the fill kernel's program loaded if the CP treats COMPUTE_PGM as ordinary shared state. I do not know why the title's stream is correct on hardware: either the title relies on a state behavior I do not model, or the fill dispatches are not meant to execute here. I did not change the driver and have no fix; I am not guessing a behavior for it. Console traces of the COMPUTE_PGM_LO value at that dispatch would settle it.
Notes: how far a run gets in a fixed time depends on how much tracing is on (the tracing slows it), but every run that ran long enough (about 100 s) stopped at this dispatch. The shader-replay tool shows the same error for the dumped request, so a .req is enough to reproduce it offline (I do not attach it: game shader data).
AI-assisted (Claude Code).
Activity
xXPBSXx commentedon Oct 11, 2026
Checking the other possibility, that the recompiler reads this entry from a wrong offset (an image descriptor at a buffer slot): it does not look like that. In the dumped request (
agc_shader_replay --mem) the ten user-data words are the directCOMPUTE_USER_DATA_0..9register values, ands[0:3]is what the fill kernel uses as its V#;ResourceMaterializertakes the buffer from there as the shader asks and the replay reports the same type error offline. The words came from the title's ownSET_SH_REGof 14 words (traced as described above), so the T# is genuinely in those registers at that dispatch; the open question remains why no program load precedes that dispatch.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 11, 2026
Checked against the Teardown finding on #3701 (a copy kernel that selects buffer or image at run time, so only the taken branch's descriptor is valid): this dispatch is not that class. The Puyo kernel (
0x1417c4300, the dword-pattern fill, 69 words in the replay's--asm) has a singlebuffer_storepath ons[0:3]; its only data-dependent branches compare the lane's remainder with 0, 1 and 2 to pick which ofs4..s7is stored, not which descriptor kind is read. So there is no untaken image branch whose descriptor the materializer could be rejecting; the T# really is inCOMPUTE_USER_DATA_0..7at that dispatch, as traced above, and the open question there stays why no program load precedes it. Eager validation of untaken sources (the #3701 case) would therefore not change this dispatch's outcome.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 11, 2026
Status: the descriptor handling this stop depends on is in #425 (open, mergeable, changes requested), not merged, so this stays open on
main; I did not run Puyo Puyo Tetris 2 for this comment.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Test of the idea that this is the resource-control-flow class (B's branch for #3701/#3952): Puyo Puyo Tetris 2 (PPSA01530) on
maina672688 + #4021 + #3799 + #425 (f470ffa) + the head oforigin/fix/recompiler-resource-control-flow, relinked, 90 s withAPS5_DUMP_SHADERS=1: the same stop as before,compute shader ...: buffer descriptor uses an unsupported type(the fill kernel's dump this time at a different host address, as expected after a relink). So that fix does not change this dispatch, which matches the reading above: the kernel has a single buffer path and the T# is really in the user-data registers. The audit for this build lists 0 absent imports (mainhas the Puyo exports by now), so nothing else blocks it before this point. I did not look at the packet order again in this run.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Puyo Puyo Tetris 2 (PPSA01530) on
maine7c70a2 + #425 (f470ffaa2) + #4408 + #3840, relinked, 0 absent imports, 240 s limit: the same stop as in all earlier runs,compute shader ...: buffer descriptor uses an unsupported type(the fill kernel again, new host address after the relink), reached well before the time limit. Nothing new on the cause (the 14-word user-data write without a program load before the dispatch).AI-assisted (Claude Code).
xXPBSXx commentedon Oct 14, 2026
Current state on #5761's head, and a second title with the same words in a buffer slot.
Puyo Puyo Tetris 2 (PPSA01530), still the same dispatch. On #5761's head
25cc5e6d2a776ed6f7ec3c0ec2c21cc59553727da local print in front of the throw inmaterializeTables(not part of any PR) gives[diag-v] RM:590 slot 0 of 1 shader 1417c4300 dwords 02100b00 c3c00000 010dc1df 91b00fac(PPSA01530_rX/run_155458.errline 9,what(): compute shader 0x1417c4300: buffer descriptor uses an unsupported typeat line 11). These are exactly the four words from this issue's description, so the dispatch did not change with the recent merges. #5828 does not cover it:main28b6f1987917e59f3a7bbcad4d0acb8b0f58b519+ #58288176ed51357a903642efb1d1ccda15294d558e67stops at the same place (run_160202.errline 48).Kena: Bridge of Spirits (PPSA01746), the same class. On the same #5761 head the same print gives
[diag-v] RM:590 slot 1 of 2 shader 207b6e0000 dwords 20455600 cae00000 001fc01f 90970fac(PPSA01746_rX/run_173801.errline 117,what(): buffer descriptor uses an unsupported typeat line 120). Word 30x90970fachas bits 31:28 = 9 (the 2D image type), like0x91b00fachere and the Stray words in #5879 (91b00f2e) and #5894 (a1b00fac). I did not check whether Kena's dispatch has the missing program load that this issue traced; the print does not show the stage or the packet order, so I only record the same word pattern.Kena does not always stop there: other runs on the same head ended at
shader buffer exceeds descriptor range limit(ShaderResources.cpp:2908, fragment shader, binding 63; words00000000 00fff000 06f00000 00000000,run_172922.errline 111) or atvkQueueSubmit recorder: Vulkan result -4(run_174542.errline 96,what():text).Tested. Windows 10 (19045), MinGW-w64 GCC 15.2, Release, NVIDIA GeForce RTX 4080 SUPER; head
25cc5e6d2exactly (no merge) with local stderr prints only;ninja -j 8 libsexit 0;run_title.ps1, one game at a time. Puyo: script times 15:54:57 to 15:55:09 (first print run), 120 s requested. Kena: script times 17:37:57 to 17:40:17 (this stop), 240 s requested. Title executables are hardlinks of the_rHrelinked executables; relinker commit and command not recorded in my notes. Not tested: Linux, other GPUs, a picture of any title.AI-assisted (Claude Code).
nikowolf123 commentedon Oct 14, 2026
@xXPBSXx, two notes on your latest comment.
Kena is probably not this issue's case. Its unsupported-type text has no
compute shader 0x...prefix, which every compute capture or materialization error gets (Dispatch.cpp#L274-L282; the same code is in #5761's head). Its range-limit stop is in a fragment shader. So both are draws, and the missing compute program load traced here does not apply to them.For draws, #5631 by @moong15 (head
75083acb3) is a candidate. In Stellar Blade, depth-only draws leave the previous pixel program bound withSPI_SHADER_Z_FORMATnon-zero.mainskips the pixel stage only when Z_FORMAT is 0 (State.cpp#L1404-L1415), so it materializes that program with user data written for another program. #5631 reports an oversized buffer descriptor from that state, which is also what your range-limit stop is about. In its matched runs, 2 of 6 onmainstopped at presentation onbuffer descriptor uses an unsupported type, against 0 of 6 with the PR; the PR notes that link is inferred, not traced to a draw.Your Kena run on
main+ #5679 + #5707 reached this stop (#5693), and both are merged now. So a run of currentmain+ #5631 would show whether Kena is this case. If you apply #5897 by @YossiYad in the same build, the message names the shader address and stage if it still stops. The two merge intomaine34c47921without conflicts.Puyo: what else sits between offsets 78 and 421? Say each fill is one 10-value
SET_SH_REG(12 dwords), a0x63(5) and aDISPATCH_DIRECT(5). Then the four fills take 88 of the 327 dwords from 78 to 405, and about 240 dwords there are packets the description does not list. Two mechanisms thatmainmodels can skip a whole fill group, its0x63included, which would leaveCOMPUTE_PGMat0x200169d00for the dispatch at 421:COND_EXEC(0x22):mainreads the condition word when it reaches the packet and skips the covered dwords if it is 0 (PacketExecution.cpp#L307-L312). If a shader or aRELEASE_MEM/WRITE_DATAearlier in the frame writes that word, the value at that point decides whether the fills run.SET_PREDICATION(PacketExecution.cpp#L135-L141).A program load through a register write is already ruled out:
mainrejectsWRITE_DATA,COPY_DATAandDMA_DATAwith an SH-register destination (Pm4.cpp#L455-L461, #L470-L474, #L484), and your runs reach the dispatch.If your earlier trace still has them, could you post the opcode and header bit 0 of every packet from 78 to 421, and for any
COND_EXECits address, the value read, its dword count and what writes that address before it? A new run can collect this:APS5_CAPTURE_TRACE=1writes each packet's offset and header tocapture-trace.log(packets that aCOND_EXECskips do not appear), andAPS5_TRACE_GPU=1prints eachCOND_EXECdecision with its address and value. If neither mechanism is in that range, the skip explanation is out, and the console trace ofCOMPUTE_PGM_LOyou mentioned is still what would settle it.AI-assisted: written with Claude Code; I checked the compute error prefix in
Dispatch.cpponmaine34c47921,0b97f8b9fand #5761's head, #5631's predicate change againstPixelProgramSkippedand its runs and gist, howmainexecutesCOND_EXECand predicated packets and validates register-destinationWRITE_DATA/COPY_DATA/DMA_DATA, and which logsAPS5_CAPTURE_TRACEandAPS5_TRACE_GPUwrite. I rangit merge-treefor #5631 and #5897 againstmaine34c47921. The dword count is arithmetic from the offsets in your report. I did not run Kena or Puyo Puyo Tetris 2.