Ghost of Yōtei (PPSA26344): unsupported scalar source operand code 235 at program counter 856 #1920

Activity

1. Dextroid17 commented on Oct 9, 2026

   

   Dextroid17

   on Oct 9, 2026

   ContributorAuthor

   More actions

   Correction and cross-reference after digging further: this case is not new — it is already documented, in the technical-debt entry that #1190 adds (not yet on main, which is why searching the tracker for the message found nothing, and gh search prs does not index diffs):

   src_shared_base, src_shared_limit, src_private_base and src_private_limit (scalar source codes 235 to 238) are not modelled: decoding throws unsupported scalar source operand code with the code and the program counter, so a shader that reads one does not compile. Operand 235 (src_shared_base) was reported on #1182 from PPSA26344 …

   So codes 235–238 are a known unmodelled set, and PPSA26344 is the title that keeps surfacing them — this is the second report of the same operand, after #1182. If the maintainers would rather this knowledge live only in #1190's debt entry, close this and I will not reopen it; I am leaving it because nothing in the issue tracker points at the gap.

   What this report adds to that entry is the surrounding context:

   • with feat(agc): implement image and sampler tables indexed at runtime offsets #757 + fix(agc): defer shaders that cannot be prepared at registration to their first use #1836 the title runs for ~13 minutes and compiles 841 shaders before dying here, so 235–238 are a mid-run blocker, not a start-up one (the earlier two walls were start-up ones);
   • in the same window 105 shaders were deferred by fix(agc): defer shaders that cannot be prepared at registration to their first use #1836, so this abort is the one that still escapes the deferral path;
   • the stack that reaches it (main + feat(agc): implement image and sampler tables indexed at runtime offsets #757 + fix(agc): defer shaders that cannot be prepared at registration to their first use #1836) is the only one that does — on main alone the title dies two walls earlier.

   The open question for whoever implements it: what the base operands should evaluate to when a shader actually reads one. The debt entry says the flat aperture routing does not read the base, so shapes that build an aperture address without reading it can be modelled; shapes that read it cannot yet.

   Written with AI assistance.
2. Dextroid17 commented on Oct 9, 2026

   

   Dextroid17

   on Oct 9, 2026

   ContributorAuthor

   More actions

   Fixed by #1940: the four codes now decode to their own operand kinds and names, and a read of one refuses with a message that names the source (the value stays unmodelled, so a shader that reads one is left unprepared rather than given a plausible address).

   Measured on the title: with #757 + #1836 + #1940, PPSA26344 no longer aborts at this call — it runs about 24 minutes (897 shaders, 106 deferrals) and its next wall is a different one, filed as a separate issue because it is a decode-side miss in another decoder.

   Note for the fix: readScalarCode's default answered 0, so decoding alone would have produced a silently wrong aperture base on the code path that uses scalar codes rather than decoded operands; #1940 adds explicit refusal cases there too.

   Written with AI assistance.
3. adriadam10 commented on Oct 10, 2026

   

   adriadam10

   on Oct 10, 2026

   Collaborator

   More actions

   #1940 decodes scalar sources 235..238 and refuses a read with the source named, covered by aperture_sources; the value of the apertures is still not modelled and the title was not run here.
4. oneandonlydean commented on Oct 11, 2026

   

   oneandonlydean

   on Oct 11, 2026

   Collaborator

   More actions

   Closing: #1940 decodes scalar sources 235 to 238, and with it the reporter's run gets past this stop. A shader that reads one of the aperture bases is still refused with the source named (TechnicalDebt); reopen if the title stops on that.
5. oneandonlydean

   closed this as completedon Oct 11, 2026