(Vulkan) SOCOM U.S Navy Seals: Fireteam Bravo 3 and Tactical Strike produce artifact with GPU readbacks enable.

[ghost]

SOCOM US Navy Seals: Fireteam Bravo 3 and Tactical Strike produce artifacts issue if simulate block transfer effects is enable this doesn't happen in v1.12 as far as I remember 🤔

Fireteam Bravo 1 & 2 doesn't exibit this issue in my limited testing.

Also ClearToRAM doesn't help this games anymore using recently
build ppsspp
61e7c3e

Might be good to remove this games in compat.ini? as the issue is back like #8973?

GE Dump.
SOCOM US Navy.zip

Hardware Specification

Android 8.1 Snapdragon 450 Adreno 506

GPU Backend

Vulkan

[unknownbrackets]

Hm, if this is still happening we probably should keep it open. Not sure what the cause is, though.

-[Unknown]

[ghost]

This is also a GPU readbacks issue.

[hrydgard]

Does this happen everywhere in the games or in some specific place?

[ghost]

Does this happen everywhere in the games or in some specific place?

In some specific place only.

[hrydgard]

I believe this has something to do with some strange CLUT trickery it's doing at the end of the frame:

In the UCES01242 dump, this is step 16410:

Rendering to 00044000 5551 while texturing from the very same VRAM address (04044000).

CLUT8 texture, no shifts, 0xFF mask, 32-bit colors in the CLUT.
Using a vertex color 0x303030ff, modulate mode, color doubling.
no depth, color or stencil.
alpha blend enabled: src.a, fixed ffffff (so basically additive)

CLUT shows as a short dual gradient:

We currently reject this draw as reading-from-framebuffer, since we don't have handling for reading 5551 textures as 8-bit CLUT of twice the width. And since we reject it, if a readback has previously happened, it'll just grab whatever old data that ended up there and try to texture from it, as if it was a regular clut texture.

I'm really curious about what the game is trying to accomplish here... seems every other pixel would act very differently since it'll get different values:

ABBBBBGGGGGRRRRR
1111111100000000

The dual gradient means it effectively ignores the top bit from each 8 bits, so we're doing the following lookups:

Every even pixel: CLUT[GGRRRRR] (bottom 2 bits from G)
Every odd pixel: CLUT[BBBBBGG] (top 2 bits from G). (this is the one that matters as we'll see below).

It just doesn't make a whole lot of sense to me, plus it's reading the same pixels it's writing, as I said...

The gradient in the CLUT reaches white after exactly 48 values.

It does it with two rectangles left to right, for the second one it modifies the texture address instead of the texture coordinates.

Maybe I'll just implement this and see what happens...

[hrydgard]

Oh I see, of course it can still work, if the rectangle is sampling nearest, or texcoords are bang-on correct - since the texture it's sampling from is twice the width in texels as the render target, if set up correctly every second texel will simply be skipped. And it's presumably set up so that the bits that get indexed are RRRRRGGG. Those green bits will introduce a little bit of noise/glitchiness though, which probably won't be noticeable.

I'm going to try to implement it so that we run the effect as intended, but I think a compatibility flag to make this more compatible with higher resolutions might be in order...

[hrydgard]

Alright, I prototyped the full thing but got into a bit of a mess with the 2x horizontal texture resolution (5551 -> CLUT8), which our depal code isn't prepared for, especially when offsets are involved which they are. Also, getting the sampling to line up exactly is iffy and only works at 1x.

I think I'm instead going to take a shortcut here, at least for now, which will also make it resolution independent, and have the depal act as if only the top 8 bits are used and produce one depal'd pixel for that. The danger being that there might theoretically be some game that wants the lower 8 bits instead or both, so might have to restrict behind a compat flag. Ugh...