The decoder maps SOPK opcodes 0x17 to 0x1a to SWaitcnt, but no test encoded them and tools/progress.py only counted S_WAITCNT_VSCNT. The test runs the four waits with a null and a live register field and checks that SCC and the register are left unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v_add_co_u32, v_sub_co_u32 and v_subrev_co_u32 (VOP3 0x30f, 0x310, 0x319)
decode to VAddI32, VSubI32 and VSubrevI32 and had no execution test.
tools/progress.py listed the first and the last as variants of those
opcodes but not v_sub_co_u32, which it reported as missing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VOP2 0x2b, 0x2c and 0x2d decode to the opcodes of v_mac_f32, v_madmk_f32
and v_madak_f32 and differ only by the encoding, which keeps them fused.
The progress map derives names from the opcode enum, so it listed the three
fused forms as missing.
The new test decodes the six encodings and checks that the translation
rounds the product separately for 0x1f-0x21, keeps 0x2b-0x2d fused, and
reads the accumulator and the literal from the right operand.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MIMG opcode 0x33 samples with explicit derivatives, an LOD clamp and a
texel offset. The three address flags already exist; only the opcode was
missing from the decoder table.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SCbranchCdbg decodes SOPP 0x17-0x1a and STtracedata decodes 0x16 and 0x28,
so S_CBRANCH_CDBGSYS, S_CBRANCH_CDBGUSER, S_CBRANCH_CDBGSYS_OR_USER,
S_CBRANCH_CDBGSYS_AND_USER and S_TTRACEDATA_IMM were reported as missing
although the decoder handles them and existing tests cover them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
libSceAjm.native routes 13 exports through a static AjmStub helper that
calls NotImplemented_nid_no_patch, so the progress map counted them as
implemented. Calls to such helpers in the same file now count as stubs.
The compare report also lists functions that went back to stubs in its
header.
Co-Authored-By: Claude <noreply@anthropic.com>
progress.py stores the names of implemented and pending items, can
measure another source tree with --root and prints a Markdown diff of
two runs with --compare. The Progress report workflow compares every
pull request with its base, and Progress comment posts the result as a
single comment, updated on every push and removed when progress no
longer changes. Commenting runs as a separate workflow_run so pull
requests from forks never run with write permissions.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
tools/progress.py counts implemented prx functions and RDNA instructions
recognized by the shader recompiler, and renders treemaps, badges and an
index page. The Progress workflow deploys them to GitHub Pages on every
push to main, so nothing generated is committed to the repository.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adrià Franch
Nahuel Genchi
Dean
DotDebian
SamG-Coder
boykopovar