-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken rendering in Need for Speed: Pro Street #16175
Comments
It needs a GE dump. |
Here it is (at least I hope it is what you asked for):
Note that it was Huawei P30 Pro, not Huawei P20 |
Ideally this kind (which can be played back afterward on various difference devices): It sounds like the Vulkan issue is Mali only with geometry shaders, but I'd like to try it on NVIDIA PC with geometry. -[Unknown] |
Doesn't look too bad on PC for the little I tested, there are just some weird shadows sometimes: |
I tried to use remote debugger but I didn't manage to connect the device remotely. |
Bisected to 362391b, removing that Only tested on PC tho, idk how to compile PPSSPP for Android. |
Confiriming this fixes the colors also on Android. To compile the project on Android:
|
Well, that probably means some depth buffer is being matched when it shouldn't, but it's not really a fix exactly. It's just making it ignore ALL depth buffers in that part of the code. -[Unknown] |
Yeah, what Unknown says. I'll investigate this soon-ish. |
I confirm that your PR fixes colors on NFS Pro Street on Huawei P30 Pro on both GLES and Vulkan. Great job. |
Okay, I guess I'll disable the geometry too, I was hoping maybe it was actually a shared cause. -[Unknown] |
On the phone NFS works perfectly now. In VR on Oculus Quest 2 there is following issue: On another VR headset (Pico Neo 3 Link) it works great. What can I provide to you to help resolving this issue? |
The geometry shader was disabled in #16183 for older Mali. What GPU is this with? I suppose the flickering could be geometry in front of the camera (incorrectly) not being culled since vertex range culling is disabled on VR. Not sure what else would be causing flickering like that only in VR. Even the red looks different. -[Unknown] |
I tested with vertex range culling enabled and it made no difference. Here are the device details: |
@unknownbrackets blinking started with this PR: #16150 I tested all commits of the PR on Oculus Quest 2: I found out that this fixes the blinking and keep correct colors:
Shall I create a PR for it or do you see something wrong with that? |
I think it's important to understand why it's only happening on this particular device, or perhaps its particular settings. The PSP has a region of address space dedicated to video memory - 0x04000000 - 0x047FFFFF. It only has 2 MB of video memory, and the same data is simply represented 4 times over. However, two of the mirrors (starting at 0x04200000 and 0x04600000) have a swizzled representation of memory. Basically, some of the bits of the address are rotated or xored compared to the other two mirrors (0x04000000 and 0x04400000.) This siwzzling matches how depth bytes are actually written to VRAM. Anyway, previously we were creating framebuffers with whatever VRAM address the game specified. Then we'd try to match access to these framebuffers using those original addresses. Basically, we didn't take into account mirrors. Then we started trying to take into account mirrors to better handle things like depth texturing. However, it was inconsistent: in some places we did, and in most places we didn't. It kinda worked, but it was buggy. After that, we found that on actual hardware, you can't even render to a particular VRAM mirror anyway (which makes sense.) It always renders directly to VRAM, so what mirror you specify when drawing doesn't matter. So we cleaned up all the mess and made it so we ignore the mirror entirely when accounting for framebuffer addresses. This exposed a bug - a bug that already existed actually - where we were counting some memory as depth buffers when no depth was written there. Before, by luck, this game had specified a mirror so it "worked out" because of our inconsistent checks. But now that we checked properly, we tried to access that depth instead of the actual color data that should be there. #16183 fixed that bug, making is so we aren't counting those bytes as depth data when they don't contain any depth data. Even without the VRAM mirror cleanup, this is a good fix and may have fixed other games as well. In your video, it seems like #16183 is not applied, maybe. Except, it does look a bit different. And if changing those lines helps, again it seems like it must be matching the depth buffer data incorrectly. If that fix even were correct, why doesn't it help on other devices? It doesn't make sense. This isn't a device-specific operation. So the question should be: what's happening differently on this device? Unfortunately it's hard for me to tell just from a video. -[Unknown] |
Thank you for very detailed answer @unknownbrackets. I fully understand that it is impossible to fix the issue without exactly knowing what's happening there. I will check if there are any OpenGL errors and write it here if I find any. |
Just to update you, there are no GL errors when the screen blinks. |
Reported by Lubos on Discord.
Huawei P20:
OpenGL:
Vulkan:
The text was updated successfully, but these errors were encountered: