Repository navigation
fix(agc): SPI_PS_INPUT_ENA/ADDR start at their reset value - #1178
adriadam10 merged 2 commits into
Conversation
|
Tested with Astro's Playroom (PPSA01325) on Windows 11 (RTX 3060 Laptop, WinLibs GCC 15.2.0 r7), on a local branch that also carries #283, #285, #425, #570, #759, #903 and #1072. Without this change, 5 draws per frame are refused with
No other draw failures appeared, and the frame dumps through the intro look the same as before. |
A context that never wrote SPI_PS_INPUT_ENA or SPI_PS_INPUT_ADDR after CLEAR_STATE reads them as zero, like the hardware, instead of refusing the draw for a missing register (a depth-only draw whose pixel shader takes no inputs). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Checked: build + full ctest green on current main + this PR; the change matches the CLEAR_STATE reset list (0x1b3/0x1b4 = 0), and the existing tests that erase 0x1b3 explicitly still require the rejection for a real pixel program. |
7552ef8 to
ef451ab
Compare
…PRs its draws use Since boykopovar#1178 the SPI_PS_INPUT_ENA/ADDR emplace calls did nothing, so the registered variant had no pixel inputs, and null pixel draws took the last pixel shader's user SGPR count and the bound targets' export mapping. Registration now overwrites those registers, the draw gives the null program no user SGPRs and an empty export mapping, and the at-draw preparation is left for wave32 only. Root cause found by @Raghav314.
…PRs its draws use Since boykopovar#1178 the SPI_PS_INPUT_ENA/ADDR emplace calls did nothing, so the registered variant had no pixel inputs, and null pixel draws took the last pixel shader's user SGPR count and the bound targets' export mapping. Registration now overwrites those registers, the draw gives the null program no user SGPRs and an empty export mapping, and the at-draw preparation is left for wave32 only. Root cause found by @Raghav314.
…PRs its draws use Since boykopovar#1178 the SPI_PS_INPUT_ENA/ADDR emplace calls did nothing, so the registered variant had no pixel inputs, and null pixel draws took the last pixel shader's user SGPR count and the bound targets' export mapping. Registration now overwrites those registers, the draw gives the null program no user SGPRs and an empty export mapping, and the at-draw preparation is left for wave32 only. Root cause found by @Raghav314.
…PRs its draws use Since boykopovar#1178 the SPI_PS_INPUT_ENA/ADDR emplace calls did nothing, so the registered variant had no pixel inputs, and null pixel draws took the last pixel shader's user SGPR count and the bound targets' export mapping. Registration now overwrites those registers, the draw gives the null program no user SGPRs and an empty export mapping, and the at-draw preparation is left for wave32 only. Root cause found by @Raghav314.
…PRs its draws use Since boykopovar#1178 the SPI_PS_INPUT_ENA/ADDR emplace calls did nothing, so the registered variant had no pixel inputs, and null pixel draws took the last pixel shader's user SGPR count and the bound targets' export mapping. Registration now overwrites those registers, the draw gives the null program no user SGPRs and an empty export mapping, and the at-draw preparation is left for wave32 only. Root cause found by @Raghav314.
What
A context that never wrote SPI_PS_INPUT_ENA or SPI_PS_INPUT_ADDR after CLEAR_STATE reads them as zero, like the hardware, instead of refusing the draw for a missing register. GTA V does this for a depth-only draw whose pixel shader takes no inputs.
Tested
Windows 11 Pro, AMD Ryzen 5 7600, NVIDIA GeForce RTX 5080 (driver 32.0.16.1074), 32 GB, MinGW-w64 GCC 15.2.0.
gta-v/testingbranch (Performance mode, the prologue).ctestpasses. Not run here: the relinker's Python tests (my local Python does not find their helper modules) andguest_gameupdate.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code