-
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
Pursuit Force graphic issues #11216
Comments
So there are two separate issues here - do they both happen only on Vulkan? Or does the mobile issue happen on OpenGL and Vulkan both, and the other issue happen only on Vulkan? -[Unknown] |
graphic glitches happen only on vulkan(PC and mobile). car run under road test on mobile opengl backend, vulkan backend is not playable for graphic glitches. |
We can avoid this bug(maybe second issue only) using the following fix. StateMappingVulkan.cpp
Probably, the same issue as D3D11. |
Hmm, but if the game specified that flag, it indicates to clamp depth to the [0, 65535] range. Maybe the flag is ignored when drawing beziers or something? -[Unknown] |
@Leopard20 check the features tab in system information - your device may not even support depth clamping. -[Unknown] |
Right. It doesn't! |
unchecked simulate block transfer, the game is running smoother. when use low spline/bezier curves quality, car run under road in some place. medium and high work fine. |
Ah, low quality is not spline/bezier. It's just drawing control mesh(no curve tessellation/evaluation). So it's just specification(not bug). However I fixed it and I will commit later. @unknownbrackets Vulkan depth clamp issue is related to Vulkan driver bug or unsupported feature maybe. |
I have experienced the same graphical issues on my machine on Vulkan. First on Linux (hinted in #10477) and now on Windows too. Vulkan:OpenGL:As of
|
Is v1.6.3-323-g945eab6fe the first build that stopped working? What's the last build that works? Also - which positioning of the yellow is "correct"? Can you try that same exact scene in the software renderer? It might be that we need to clamp depth at the fragment level to be correct (which is unfortunate.) It will help to know if the software renderer has the same glitch. -[Unknown] |
Last good: The front part of the car is missing, maybe that's easier to find? |
I wonder if that error is caused by KhronosGroup/glslang#1418, if it's happening on PC. What does depth look like using the software renderer? In theory, that's the correct depth. -[Unknown] |
Okay, then probably OpenGL is correct. Since it seems like it renders mostly right in the software renderer, can you try making a GE debugger dump? To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity. After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here. I can even try running this on a real PSP to compare (that's still experimental, though.) Then I could see what depth /should/ be for sure. -[Unknown] |
So I have to switch to Software Renderer, click Step Tex in the GE Debugger until the texture appears in the preview window, then Record and then Resume? |
Ah - unfortunately, that didn't capture anything. It's probably fine to make the GE debugger dump using any backend. But something failed if it creates a 2KB file - this is the second time I've seen that now, there must be a bug causing it. But if you click do Record/Resume again, it should work after a couple tries at worst. -[Unknown] |
Backend: Vulkan Again, I waited for the yellow roadblock to appear in the texture preview, Record -> Resume. This time theres actually stuff in the file. |
Hmm, it seems to heavily use minz/maxz and viewport z params. Maybe something isn't dirtying properly, or else there's somewhere we're handling these depth params wrong. Most of the drawing is done with the viewport centered on the first 50% of depth (0 - 16383), and with a maxz of 16383. -[Unknown] |
Do note that this is working fine with earlier builds. |
Right, so that points to depth clamping - #10454. But the question is, why. The PSP definitely clamps depth, but maybe we need to do it in the fragment shader for it to be accurate. I think right now, we're deforming polygons when it clamps, perhaps, which is only okay in flat or mostly-flat cases. -[Unknown] |
How does this look with recent changes now? -[Unknown] |
test latest dev build, vulkan still have graphic issues. use low spline/bezier curves quality, car run under road in some place, but not worse than before. |
Everything is fine for me again. I couldn't test it since the Lost the Vulkan device! error but as of |
I believe this is fixed, closing. Please reopen if not. |
Apparently not, reopening. |
Yeah this is still a thing even on the current git versions and the latest stable version. |
A GE frame dump of an issue currently happening would be helpful. The previous frame dump still seems to work fine. -[Unknown] |
Vertex cache + HW Tessellation make this game faster on my phone R9 Mali-G52 GPU Vertex cache and HW Tessellation is off I also notice some rendering issue the road sometimes is flickering? |
Can no longer reproduce my issue as I mentioned above maybe because of 16bf519? |
https://cdn.discordapp.com/attachments/480103153803460614/551370781482024961/unknown.png seems like it was probably also the guardband issue. But please note that the guardband fixes are NOT currently implemented for:
I think it's a bit early to fly the flag of victory. -[Unknown] |
v1.12.3-232-gb6e7fe1aa still happen (All backends). GE Dump. |
Right, that's #11399. As noted there, clamping against the wrong boundary is still not worked around. -[Unknown] |
For me, OpenGL / Vulan / Direct3D 9 / Direct3D 11 are both broken on 1.13.1 |
@weihuoya what about this now. |
Confirmed - I tried on several versions but it only works on v1.1.3 with OpenGL renderer |
Helps situations like hrydgard#11216, where only one side should be clamped. Keeps depth clamp (i.e. hrydgard#7932) working. See hrydgard#11399.
#16049 will make this work on most devices other than those using Mali GPUs. -[Unknown] |
Still has issue: |
Can you upload your savestate in that area? |
At the beginning of Pursuit Force: Extreme Justice. |
Thanks, I think I fixed the issue in the latest git - if not #16069 should mean less precision issues. -[Unknown] |
Confirm fixed via f8d29fd The performance is so slow... |
@Gamemulatorer Did the performance slow down with the fix, or was it already slow? |
Alright, that's good to know. Yeah the game makes extremely heavy use of tessellation for the road surface, which is not fast in PPSSPP unfortunately. Probably need to take another look at figuring out a way to make hardware tessellation work better and go fast. Using compute shaders instead of the wacky instancing trick we're currently using might help. Maybe some dynamic detail adjustment, too. |
hardware tessellation makes this game a little faster in Vulkan. But in opengl this game is super lag if hardware tessellation is on. |
Note for any Mali users looking at the above and confused why it's still happening for you: this is only fixed on devices that support a hardware feature called "clip distance", which some GPUs (i.e. Mali) don't. -[Unknown] |
What happens?
car run under road in some place, test on android, PC seem doesn't has this issues.
another issue, graphic glitches vulkan backend only. opengl and direct3d work ok.
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
PPSSPP version:
ppsspp-v1.6.3-248-g098a7ffea-windows-amd64.7z
ppsspp-v1.6.3-248-g098a7ffea-android.apk
this game use hundreds of bezier lines. like Acid 2 use hundreds of splines.
The text was updated successfully, but these errors were encountered: