[kallsyms]

block2d_copy_with_stride took a width which should really have been an element_count. When stride > 1, this means the copy was only partial leading to apparent corruption. This PR fixes the copy logic, and also updates the corresponding barrier/sync range logic.

Before:

After:

Disclosure: this bug was originally identified + fixed with AI tools, however it was manually reviewed and verified (see above images).

Relates to #19198

[kd-11]

Hardware claim - needs accompanying PS3 hardware tests.
I have an existing test case for this feature somewhere, and from what I remember, it did not function intuitively which heightens my suspicion that the fix may be incorrect.

[kallsyms]

Hardware claim - needs accompanying PS3 hardware tests. I have an existing test case for this feature somewhere, and from what I remember, it did not function intuitively which heightens my suspicion that the fix may be incorrect.

I've got hardware so can test things tomorrow - lmk what you want from me in that regard (and if you've got a framework or something you use to write these quick tests, didn't see anything from a cursory search).

[digant73]

there was another issue on that function fixed in #18519 (negative pitch allowed) after confirmation with HWTEST

[kallsyms]

@kd-11 Here's a small test suite which shows behavior on hardware.

ps3-nv0039-stride-test.zip

The run results within that match the new behavior of strided copy.

[kd-11]

@kd-11 Here's a small test suite which shows behavior on hardware.

ps3-nv0039-stride-test.zip

The run results within that match the new behavior of strided copy.

Thanks. I already have a interleave/deinterleave test written, I'll approve if results match what I expect.

[kd-11]

HWTEST: interleave2d.zip

PS3:

RPCS3 (master):

RPCS3 (PR):

[kd-11]

Matches hw result.