GS: Fix sub-page addressing of Z formats #9302
Conversation
TellowKrinkle
force-pushed
the
BlockZAddr
branch
from
3138c4a
to
2c15393
Compare
|
I tested it and performance is actually better and the graphic issue is fixed at native resolution, but when upscaling there is now a grid of squares appearing and disappearing. EDIT. Bit more infos: This grid doesn't appear with DX11 and OGL. It appears with DX12 and Vulkan. Final.Fantasy.X_SLUS-20312_20230722112618.mp4 |
|
Tested the performance of the attached GS Dump against master. At Native: The performance actually increased substantially. |
|
Seems to change invalidation/dirty behaviour in HW. That's why you're seeing a performance difference. Also explains the squares - it's because it's no longer uploading the whole depth buffer. Master versus PR:
|
|
Causes an issue on this dump. Likely the same issue as above, but this could just be a HW thing. Final_Fantasy_X_International_SLPS-25088_20221120023912.gs.xz.zip
|
That is indeed an invalidation problem. I had a similar result in my local invalidation changes when the Z addressing was broken. I plugged this code in to my local invalidation changes and (along with a whole bunch of bug fixes I had to make) it now looks like this
One thing I had to be careful of, if the block pointer is page aligned and the rect is 0,0->16,16, it doesn't write to 0,0->16,16! Which was an assumption I was making, so I had to change my invalidation code to calculate the offset if it's depth and the size of the rect is less than 1 page. |
|
I unfortunately don't have much time to test all the previous offsets we did. (The PS2 SDK has a regression I think and I didn't do myself any favours with how I wrote this code) Here is the one we left off at: Target (PS2): Master: PR: |
Not compatible with the real GS's Z addressing, RIP
They aren't just an offset of the base value like the color formats, but instead an xor of the associated color format
TellowKrinkle
force-pushed
the
BlockZAddr
branch
from
2c15393
to
dfef76d
Compare
i'm still having the grid show up flickering in all hardware renderers except DX11. I've got a geforce 3060 |
|
can you show what you mean please @seta-san ? Looks fine to me The transitions seem to have some bugs, but that's my bad. |
|
I’m at work for the next 9 hours |
|
Then, reply after? |
|
That has nothing to do with this PR. but fwiw, it happens on every renderer but DX11 for me, but it's an upscaling problem, it doesn't happen in native. I think using texture offsets sorts it out. |
@refractionpcsx2 How is this not related to this PR? @TellowKrinkle mentions in the OP that this PR fixes #804 but this video shows the bug in #804 still happening. EDIT - Yes what seta-san is pointing out in the videos is not related to the PR but one of the actual bugs being addressed by this PR still shows in those videos. |
|
It looks fine to me? |
|
In the videos from seta-san? The bug described in #804 is clearly still there. |
|
It's very subtle, and likely the result of upscaling. |
|
I think we're talking about two different things. The issue in #804 is not caused by upscaling. I also just looked at my original video of it and the ones from seta-san and it's exactly the same still, not any more subtle. |
|
Since this is said to fix #4309, I'm wondering if the issue from this comment is also fixed by this: Does anyone know the answer without needing to test? It doesn't happen every time so it's a bit of a pain to test. I can do it if needed though. |
|
Those videos clearly weren't recorded on master. The corruption in the logo was fixed in software by this PR, and in hardware by a combination of ref's invalidation PR, and this change (for the decoding). As shown in refraction's screenshot. As for the lines, it's an upscaling issue. You can see the depth buffer gets uploaded in two parts, and you have a gap for the second when upscaling, because 1 pixel in GS space is >1 pixel in HW space:
|
|
Also, I checked master myself - looks fine. Refraction's was NTSC, so here's PAL: |
|
Yeah I was suspecting that seta-san's videos might've not been on master since I saw ref's screenshot was fine but I wasn't 100% sure. I should've just retested myself instead of commenting on this. I'm really sorry. This is what I get for staying up past 2 AM 😅 And yes, I know the issue seta-san is pointing out in his videos is from upscaling. It looks like every other upscaling issue that I've ever seen. :) Sorry that I made you elaborate on this point, I definitely didn't have any doubts on this one. |
|
If I remember/have time, I might dig into it a bit deeper, it's a little strange that we're flushing in the middle like that. Unless it's writing the top half of the buffer, drawing some of the sprites in the bottom half, then writes the bottom half. That's why the line shows up - because the write gets split in two, with the sprite draw inbetween... |
Description of Changes
They aren't just an offset of the base value like the color formats, but instead an xor of the associated color format
For example, PSMZ32 bp=16, what address is the block at (4, 0)? The equivalent for CT32 would be (16+16 = 32). Our old algorithm would do (16+(16^0x18) = 24). But the actual value is (16+16)^0x18 = 56.
Note: This removes an optimization we had, as it's not compatible with the real GS algorithm. RIP. Hopefully it doesn't hurt performance too much, but if it does, I don't think there's much we can do about it.
Fixes #4309
Fixes #804
Rationale behind Changes
More accurate
Suggested Testing Steps