[PR #2786] [MERGED] resource_tracking_pass: Add heuristic to detect incorrectly tracked buffer sharp. #2978

New issue

Closed

opened 2026-02-27 22:01:59 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 22:01:59 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/2786
Author: @squidbus
Created: 4/14/2025
Status: ✅ Merged
Merged: 4/15/2025
Merged by: @squidbus

Base: main ← Head: sharp-track

📝 Commits (1)

21531f1 resource_tracking_pass: Add heuristic to detect incorrectly tracked buffer sharp.

📊 Changes

1 file changed (+31 additions, -4 deletions)

View changed files

📝 src/shader_recompiler/ir/passes/resource_tracking_pass.cpp (+31 -4)

📄 Description

Currently sharp tracking does a breadth-first search which always visits right-hand arguments first. In some cases, this may follow phis down paths that cannot be reached by an actual shader, leading to the incorrect sharp source.

For example, take the following excerpt of control flow:

/*000000000000*/ s_mov_b32       vcc_hi, 0x42f
...
/*000000000038*/ s_cbranch_scc0  .L176_0
/*00000000003c*/ s_load_dwordx4  s[12:15], s[10:11], 0x8
/*000000000040*/ s_load_dwordx8  s[0:7], s[8:9], 0x10
...
/*000000000074*/ s_cbranch_scc0  .L8480_0
/*000000000078*/ v_mov_b32       v3, 0x3f400000
/*000000000080*/ s_load_dwordx4  s[12:15], s[10:11], 0x18
/*000000000084*/ s_load_dwordx8  s[0:7], s[8:9], 0x30
...
/*0000000000ac*/ s_branch        .L8448_0
.L176_0:
...
.L8448_0:
...
/*00000000211c*/ s_endpgm
.L8480_0:
...
/*00000000212c*/ s_endpgm

Depending on the first branch, this shader will either unconditionally go to a terminating branch at the end of the shader, or continue on with the rest of the code. After control flow and SSA, this results in phis under L176_0 choosing between user data at the beginning of the shader and values loaded inside the unconditionally branching block, despite it being unreachable. This is fine for actual shader execution since the phis will resolve based on the block that execution came from, but since sharp tracking does not consider reach-ability, it may track to the incorrect source inside the branching block.

This PR attempts to help deal with this problem by adding a heuristic for buffers to detect invalid sharp tracking paths. If the tracking reaches a sharp that points to a buffer with an invalid type value (must be 0), it assumes that the sharp must have been tracked wrong. The tracking is re-run with it excluded, and the process repeats until either a valid looking source is found or all paths are exhausted.

The proper solution would be full reach-ability testing in sharp tracking, but in lieu of that (I admittedly don't have a strong enough grasp on the control flow stuff to implement this myself), this heuristic can help some games running into the issue.

Fixes a crash going in-game in CUSA16404.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/shadps4-emu/shadPS4/pull/2786 **Author:** [@squidbus](https://github.com/squidbus) **Created:** 4/14/2025 **Status:** ✅ Merged **Merged:** 4/15/2025 **Merged by:** [@squidbus](https://github.com/squidbus) **Base:** `main` ← **Head:** `sharp-track` --- ### 📝 Commits (1) - [`21531f1`](https://github.com/shadps4-emu/shadPS4/commit/21531f171acf203ab43e3ea32a14f57b3e662bc8) resource_tracking_pass: Add heuristic to detect incorrectly tracked buffer sharp. ### 📊 Changes **1 file changed** (+31 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/shader_recompiler/ir/passes/resource_tracking_pass.cpp` (+31 -4) </details> ### 📄 Description Currently sharp tracking does a breadth-first search which always visits right-hand arguments first. In some cases, this may follow phis down paths that cannot be reached by an actual shader, leading to the incorrect sharp source. For example, take the following excerpt of control flow: ``` /*000000000000*/ s_mov_b32 vcc_hi, 0x42f ... /*000000000038*/ s_cbranch_scc0 .L176_0 /*00000000003c*/ s_load_dwordx4 s[12:15], s[10:11], 0x8 /*000000000040*/ s_load_dwordx8 s[0:7], s[8:9], 0x10 ... /*000000000074*/ s_cbranch_scc0 .L8480_0 /*000000000078*/ v_mov_b32 v3, 0x3f400000 /*000000000080*/ s_load_dwordx4 s[12:15], s[10:11], 0x18 /*000000000084*/ s_load_dwordx8 s[0:7], s[8:9], 0x30 ... /*0000000000ac*/ s_branch .L8448_0 .L176_0: ... .L8448_0: ... /*00000000211c*/ s_endpgm .L8480_0: ... /*00000000212c*/ s_endpgm ``` Depending on the first branch, this shader will either unconditionally go to a terminating branch at the end of the shader, or continue on with the rest of the code. After control flow and SSA, this results in phis under `L176_0` choosing between user data at the beginning of the shader and values loaded inside the unconditionally branching block, despite it being unreachable. This is fine for actual shader execution since the phis will resolve based on the block that execution came from, but since sharp tracking does not consider reach-ability, it may track to the incorrect source inside the branching block. This PR attempts to help deal with this problem by adding a heuristic for buffers to detect invalid sharp tracking paths. If the tracking reaches a sharp that points to a buffer with an invalid type value (must be 0), it assumes that the sharp must have been tracked wrong. The tracking is re-run with it excluded, and the process repeats until either a valid looking source is found or all paths are exhausted. The proper solution would be full reach-ability testing in sharp tracking, but in lieu of that (I admittedly don't have a strong enough grasp on the control flow stuff to implement this myself), this heuristic can help some games running into the issue. Fixes a crash going in-game in CUSA16404. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>