GS-hw, TC: improve tex in rt.

[iMineLink]

I improved the tex in rt code which logic is now encapsulated in the GSTextureCache::ComputeSurfaceOffset method.
The method considers two surfaces A and B, and computes the offset from B to A in terms of B coordinates.
In the tex in rt case, A is the Source object and B is the Target object.
We want to know the offset from B to A in order to associate to A the correct portion of data from B.

The improved logic is able to fix/improve:

• Burnout 3 black sky (clouds still missing, sky texture not invalidated to GS local memory so black sky reappears if TC is cleared, better solution in GS-hw: fix Burnout games black sky. #4094 )
• Xenosaga 3 last dungeon graphic bug (related to [GSdx HW] Xenosaga III ntsc Error graphics on surfaces in the last dungeon #3155)
• Pause menu in The Getaway
• Indiana Jones and the Emperor's Tomb HW mode
• PAL/NTSC selection menu in Wild Arms 4 HW mode (related to Wild Arms 4 PAL (SLES-54239) - Not showing refresh rate choice screen #2026)
• Beyond Good and Evil main character shadow

The logic can be enabled via .ini file (UserHacks_TextureInsideRt = 1) for non Jak games, or from the GS HW hacks settings GUI.

Due to the nature of GS-hw TC, the logic cannot be always enabled without causing regressions.

The GSTextureCache::ComputeSurfaceOffset method is intended as future proof, potentially useful for detecting overlaps between EE writes and cached Targets, or between cached Targets alone.

Bonus 1:

The order in which Target and Source are searched in the cache is inverted, now:

• The lookup source is executed, the call sees the target drawn in the previous draw as MRU
• The lookup target is executed

Previously, the lookup source call saw the current target as MRU framebuffer, but this was not correct as that framebuffer was not written yet in the current draw.
This fixed in a decent way the misbehaviour of Test Drive Unlimited with tex in rt.

Bonus 2:

Targets are now readback from LRU to MRU (older data is overwritten with newer data).
Did not fix any particular issue, but it is more correct behaviour nevertheless.

Bonus 3:

The GSTextureCache::ComputeSurfaceOffset is reused to detect draws that invalidate partially a framebuffer with increased precision in Jak 2/3/X to fix striped and shimmering textures and wheels rendering in Jak X.
Unfortunately some games do not digest this change really well, so this improved logic is executed only for the games cited previously.
POSTPONED to future PR.

Bonus 4:

Partially dirty targets are now searched for valid data.

[NewMoonHD]

Test Drive Unlimited didn't favor it a lot. Only HW rendering is affected (SW Renderer is safe for now)
gsdx_20201104120707.gs.zip

Update: It's fixed from later build updates.

[tadanokojin]

Hello imine, good work. #563 improved and the sky issue is now fixed for Burnout Revenge. Black is still experiencing sky issues. I fear that it will be hard to debug however given the nature of it using the Burnout engine. I need a rather large dump starting at loading the level and ending when the sky is first visible. Perhaps @refractionpcsx2 can provide me with that so I can get you more details.

That being said, the reflections on the cars are still flickering. On master without tex in rt I was unable to reproduce the flickering. However, on master with tex in rt enabled the flickering is observed and worse. So I suspect there is some tuning in tex in rt for this game that is needed but this is an improvement over master's tex in rt implementation for sure.

gsdx_20201105143203.gs.xz.zip

Additionally, #3694 has seen improvement with this PR. However, it still exhibits some problems. I can get you a dump if this game if you need. This is more straightforward to debug than the Burnout games.

[legend800]

Burnout 3:

Sky is broken on first load:

If you toggle to Software render:

Then back to HW, it's finally correct (until you return to menus):

Burnout Dominator:
Same, except if you switch to Software, sky is black and toggling to HW doesn't fix.

[tadanokojin]

I will try to do some debugging today and provide some information about Burnout/Black.

[iMineLink]

Thanks kojin, I agree the Burnout engine is not easy to debug unfortunately. I saw previously on discord that Burnout Dominator was working though, but now it seems not, maybe due to the recent PR update.

Maybe having also a gsdump for #3694 can be of help.

[tadanokojin]

Yeah I suspect that will be easier and will give you something to look at in the meantime
driving emotion s.zip

You're looking for the draw where depth/color gets downsized. They're going to copy them into a temp buffer and color is going to be right under depth but using the same address, then sampled back later (after EE processing) from a different address.

[iMineLink]

The replay of Driving Emotion S you gave me looks fine here.

Here the first draw call that uses tex in rt:

T:Oth	ID:258	S:Cache	=> TC: Lookup Target(Color) 1280x1024, hit: 2 (0x800, C_32)
T:Oth	ID:258	S:Cache	=> TC: Lookup Source <0,0 => 128,128> (0x1d80, C_32, BW: 2)
T:Oth	ID:258	S:Cache	=> TC: ComputeSurfaceOffset - Cached HIT element (size 1), [B] BW 2, PSM C_32, BP 0x1c80 (END 0x1e7f) + OFF <0,128 => 128,256> ---> [A] BP 0x1d80 (END: 0x1e7f).
T:Oth	ID:258	S:Cache	=> TC: dst Color hit (full): 118 (0x1d80, C_32)
T:Oth	ID:258	S:Cache	=> TC: Remove Src Texture: 119 (0x800)

[tadanokojin]

Alright, it might have been fixed since you added new commits. Let me give it a shot.

[iMineLink]

The new commits were:

1. fixing some bugs in the offset computation itself (Jak was not working anymore lol)
2. doing the tex in rt search in a second round in LookupSource w.r.t. same BP Source-Target check; this fixed test drive unlimited, where the tex in rt was stealing the correct target lookup (same BP); the reason behind this is that the TC supports overlapping targets for the same PSM, which is a very tricky feature to have along with tex in rt.

[tadanokojin]

Looks like there's an issue with it over time:

DES.zip
I start seeing graphical issues as the race continues. Here you can see the artifacting at the top. Not sure if a dump can help you with this one though, because the issue is different in my dump vs what I saw when I dumped it. An issue of debugging cache issues like this I'm sure.

[RedDevilus]

HW mode pics:

SLES-54681 PAL - Burnout dominator on commit 82438e0
Black sky when you change from default settings (even including SW mode)

SW mode pics:

When you restart race the sky looks fixed but the car dissapears:

But then it recovers on both SW and HW:

No idea why it's inconsistent on testing situations. (upscaling / native resolution + Switch between SW and HW mode + starting fresh and restarting races)
You do see a cool lightning halo effect at a certain distance (right side of rails and partially trees on picture:

[tadanokojin]

Okay, testers are obviously confused so let me explain.

The Burnout engine is a special case for this. The game renders the sky to a texture. It then samples that texture back with a different offset. This means that the part of the texture it wants for the sky will be at a different memory address than where it was rendered. This is the problem tex in rt solves.

However, unlike other examples (jak eyes, driving emotion s) where the texture is rendered to every frame, Burnout only renders the texture when the level is loading. Additionally, sw rendering doesn't experience this problem because it's a different cache implementation. So when you load the level in software, it renders the texture to GS memory and then is able to invalidate it correctly and so when it gets sampled back, it is found. If you switch to HW renderer after this, the HW renderer will read the texture out of GS memory as it would any other texture transferred in from the EE. This is why that workaround works.

This has additional complications due to the fact that the HW renderer will not invalidate rt back into GS memory. This is a problem that is outside the scope of this PR but has some side effects when switching from HW to SW when the level is loaded in HW or opening the config for example.

[RedDevilus]

I see, it does seem to have improved the sky, just was surprised the black sky problem was also happening in SW mode (first in HW mode and then switching to SW) but was fine after 2 restarts of the race.

Sorry :o

[CookiePLMonster]

Fixes pause menu in The Getaway not working properly in Hardware mode. Without this PR, pause shows the last frame of Software mode (or nothing), with this PR it properly shows a "screenshot" of the underlying game.

[iMineLink]

I gave up on Driving Emotion S in this PR.
Open to discuss about the Jak 2/3/X only change in TC (crc based code inside TC already exists in the codebase); In any case, it's just a small commit.
I think this might be given a round of tests in Burnout, I don't think this can improved any further without severely interfering with framebuffer cache invalidation.

[ghost]

I don't agrea with the jak only fix, this should be a general fix as it improves burnout, gateway and probably many others.

[iMineLink]

I better specified in the PR description what is the Jak only change: it is a small bonus part of the PR, that uses the same logic of the tex in rt, but applied to framebuffer invalidation.
The PR is mainly about tex in rt instead, which code is now always run.

[ghost]

Ok, thanks for the explaination.

[MrCK1]

Tested the updated code in Burnout 3, works fine on my end with no performance issues that I could see. Only issue I noticed is that closing the GS window and reopening will cause the sky to be black again, but I don't think there's much we can do about that unless I'm mistaken.

Ignore me, I was informed I missed a previous conversation regarding these issues.

[legend800]

Skybox is still not being loaded up correctly on HW on latest commit. It's blue but missing clouds and has bad banding. Sky turns black after toggling to Software and is broken until you start again from menus.

Burnout 3 HW at load:

Burnout 3 SW at load:

Burnout 3 HW at load:

Burnout Takedown SW at load:

[rtj503]

So I tested this added option in Xenosaga 3 with the Zarathustra Dungeon.

It didn't actually have any effect. There are two areas where it's most prominent. One area is this one right before the crystallized section. The other is just beyond this part where you can step on switches on the floor to make transparent panels move.

For comparison, here's how it's all supposed to look in Software Mode.

[RedDevilus]

Ref made this for easily seeing if the function gets triggered if anyone is interested, enable HW hacks and tex in rt and check the program log/ console:

pcsx2-avx2-texrtlog.zip

[rtj503]

I downloaded that. That launcher just made the game really slow. I didn't notice any text in the Program Log that said Tex in RT had been activated. So maybe it's not activating.

[iMineLink]

Regarding xenosaga 3, I have a gs dump from the "crystallized section" that works correctly now on master. Can you try forcing the tex in rt option active from the hw hacks section? Maybe the CRC of your game version is not registered for auto enabling the tex in rt logic.

[rtj503]

Maybe that's the issue. I have a save from the Zarathustra Dungeon that I used on my AMD laptop and my Desktop that has an RTX 3060 graphics card. The graphical problem still occurs on both. I enabled the option in the HW hacks section, and I looked to see if it was enabled in the ini file. (I'm not a computer programmer, although I'd like to contribute with code, I don't have the knowledge, so don't ask anything too advanced, lol).

Here's what the program log said, I assume this was the relevant section:

Patches: No CRC found, using 00000000 instead.
(SYSTEM.CNF) Detected PS2 Disc = cdrom0:\SLUS_214.17;1
(SYSTEM.CNF) Software version = 1.00
(SYSTEM.CNF) Disc region type = NTSC
ELF (cdrom0:\SLUS_214.17;1) Game CRC = 0x2088950A, EntryPoint = 0x00120008
(SYSTEM.CNF) Detected PS2 Disc = cdrom0:\SLUS_214.17;1
(SYSTEM.CNF) Software version = 1.00
(SYSTEM.CNF) Disc region type = NTSC

So first it mentions not having a CRC code to apply a patch, but then it says midway through that it has a CRC code.

[refractionpcsx2]

hmm that CRC is in there... can you try it on #5433 ?

[rtj503]

hmm that CRC is in there... can you try it on #5433 ?
Is that a build, or would that require compilation? Just looks like a problem page to me.
I ran it all on the 1.7.2282 AVX2 64bit build. I tried compiling PCSX2 from source in Visual Studio once...didn't work. Not certain what happened. Did accomplish it in Linux once though a while back. Maybe don't have it depend on the CRC code?

[refractionpcsx2]

if you go to the checks at the bottom of #5433, then click on the "details" next to one of the windows builds, then go to "summary", there are builds in there.

[rtj503]

I did that, I downloaded the AVX 64bit build. Same glitch still popping up. Perfectly willing to do more testing for you guys after some more work was done on it.
For reference, I posted some testing I did for Xenosaga 3 on the forums with pretty thorough documentation. https://forums.pcsx2.net/Thread-Xenosaga-Episode-III-Also-Sprach-Zarathustra-SLUS-21389-U--28443
I'm user tgg22. I tested on both my AMD laptop with integrated graphics, and my HP Omen Desktop with an AMD CPU and Nvidia GPU. Testing is admittedly for older builds, but those specs are representative of the options I typically like to pick. In case that helps.

[refractionpcsx2]

@rtj503 can you provide a GSDump of Xenosaga, please? might make testing easier.

[rtj503]

What's a GSDump and how do I do that? Sorry for asking the beginner questions. I'm perfectly fine helping out, but I need guidance doing since I don't know anything about the software other than what's on PCSX2 website. I couldn't find that in the PCSX2 documentation. I do have a memory card file. I've found Memory Cards work well finally in the newer builds.

[refractionpcsx2]

Here's an explanation how to make one https://forums.pcsx2.net/Thread-How-to-create-a-proper-GS-dump

[rtj503]

Here's an explanation how to make one https://forums.pcsx2.net/Thread-How-to-create-a-proper-GS-dump

Okay, I followed the directions, and posted the GS Dump in the forums. Link here: https://forums.pcsx2.net/Thread-GSdx?pid=624888#pid624888
Glad to help!