[PR #3224] [MERGED] ir_passes: Fold readlane with ff1 pattern #3317

New issue

Closed

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

kerem commented

2026-02-27 22:03:15 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/3224
Author: @raphaelthegreat
Created: 7/10/2025
Status: ✅ Merged
Merged: 7/10/2025
Merged by: @georgemoralis

Base: main ← Head: readlane-ff1

📝 Commits (1)

cbea56b ir_passes: Fold readlane with ff1 pattern

📊 Changes

3 files changed (+17 additions, -4 deletions)

View changed files

📝 src/shader_recompiler/backend/spirv/emit_spirv_instructions.h (+1 -1)
📝 src/shader_recompiler/backend/spirv/emit_spirv_warp.cpp (+2 -3)
📝 src/shader_recompiler/ir/passes/readlane_elimination_pass.cpp (+14 -0)

📄 Description

I've recently spotted the following shader pattern, used in some waterfall loops, which is essentially a we-have-v_readfirstlane_b32-at-home

/*00000000000c*/ s_mov_b64       s[16:17], exec
...
.LOOP
/*000000000028*/ s_ff1_i32_b64   s18, s[16:17]
/*00000000002c*/ v_readlane_b32  s25, v3, s18

Which on main gets translated to

subgroupBroadcast(uint(gl_InstanceIndex), 3305621016u);

There are 2 issues here. First EmitReadLane assumes the lane id is a constant u32, which is not always the case (the large number here is because that's a pointer stored in the Opaque IR::Value). Second is that s_ff1_i32_b64 is implemented with GetSrc64 instead of thread bits. This instruction should probably be swapped to thread bits but because I don't remember the original usecase, which could have been 64-bit, I won't change it in this PR.

To solve this issue, the readlane elimination pass will detect when readlane has an non immediate lane coming from FindILSB64 and substitute it with ReadFirstLane

_{🔄 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/3224 **Author:** [@raphaelthegreat](https://github.com/raphaelthegreat) **Created:** 7/10/2025 **Status:** ✅ Merged **Merged:** 7/10/2025 **Merged by:** [@georgemoralis](https://github.com/georgemoralis) **Base:** `main` ← **Head:** `readlane-ff1` --- ### 📝 Commits (1) - [`cbea56b`](https://github.com/shadps4-emu/shadPS4/commit/cbea56b63af6229dbeb49fd069e259706e109432) ir_passes: Fold readlane with ff1 pattern ### 📊 Changes **3 files changed** (+17 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/shader_recompiler/backend/spirv/emit_spirv_instructions.h` (+1 -1) 📝 `src/shader_recompiler/backend/spirv/emit_spirv_warp.cpp` (+2 -3) 📝 `src/shader_recompiler/ir/passes/readlane_elimination_pass.cpp` (+14 -0) </details> ### 📄 Description I've recently spotted the following shader pattern, used in some waterfall loops, which is essentially a we-have-v_readfirstlane_b32-at-home ``` /*00000000000c*/ s_mov_b64 s[16:17], exec ... .LOOP /*000000000028*/ s_ff1_i32_b64 s18, s[16:17] /*00000000002c*/ v_readlane_b32 s25, v3, s18 ``` Which on main gets translated to ```glsl subgroupBroadcast(uint(gl_InstanceIndex), 3305621016u); ``` There are 2 issues here. First EmitReadLane assumes the lane id is a constant u32, which is not always the case (the large number here is because that's a pointer stored in the Opaque IR::Value). Second is that s_ff1_i32_b64 is implemented with GetSrc64 instead of thread bits. This instruction should probably be swapped to thread bits but because I don't remember the original usecase, which could have been 64-bit, I won't change it in this PR. To solve this issue, the readlane elimination pass will detect when readlane has an non immediate lane coming from FindILSB64 and substitute it with ReadFirstLane --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>