Monster Hunter Freedom Unite broken on Mali GPUs with Vulkan

[PepeJulio]

Would you say that, right now, Vulkan backend is more likely to present bugs on Mali GPUs than Adreno GPUs?

[hrydgard]

I haven't seen anything to indicate that.

[PepeJulio]

This is MHFU on a Mali T-860MP2:

https://m.imgur.com/riHlwRa

And this is MHFU on Adreno 530:

http://i.imgur.com/Xnd0Jmu.jpg

[hrydgard]

Well, that's clearly a case where something goes wrong on Mali. Could be either a bug in PPSSPP or in the Vulkan driver.

[TehPlayer14]

I would assume game specific issue

[tilkinsc]

It isn't the game thats the problem. The rip looks fine under one architecture.

[hrydgard]

This particular problem should be fixed in the last few builds, it really doesn't like out of range viewport depth values.

[PepeJulio]

Sorry if this starts to get annoying, but everything is exacly the same.

[hrydgard]

Tried it on an S8 with Mali, it worked. Strange.

[PepeJulio]

What are the settings you used on S8?

[PepeJulio]

In any case, here is actual footage of the issue:

https://www.youtube.com/watch?v=cYtolz1Srhc

[TehPlayer14]

So its device or setting specific issue so I was pretty close

What phone Pepe is it that you are using?

I will try on my device too which is running Mali

[PepeJulio]

Sony Xperia XA

[TehPlayer14]

I've checked Xperia Xa and ultra they seem the same I happen to have ultra will give more info after the test

[TehPlayer14]

I've checked it yep it appears that Vulkan appears to be broken on that game on Xpiera's XA's

Can confirm the game suffers from the issue Pepe mentioned

All settings default expect back end to Vulka
Android 7.0
Xperia XA Ultra

@hrydgard hrydgard

Perhaps this Mali of Xperia XA is missing some of the instructions? could you take screenshot of gpu features on S8? Thanks!

Also as you hinted its PPSSPP Bug or driver bug itself

[hrydgard]

It's really hard to tell whether PPSSPP is accidentally mis-using Vulkan somehow, or whether the GPU driver is buggy. PPSSPP's Vulkan code still fails a few tests when running with the Vulkan validation layers on PC, I aim to clear that up in the near future, which may help.

[tilkinsc]

Does software rendering work? Maybe that would eliminate some probable faults. It isn't a work-around, but we do know then if it is the CPU instructions (inevitably telling vulkan to set things up wrong due to instructions) or the GPU (being buggy with given information).

[PepeJulio]

Where was that option again? Cant seem to find it.

[hrydgard]

Since it's usually a really bad idea to use SW rendering on Android, I removed it. You can manually enable it anyway by setting SoftwareRendering = True under [Graphics] in PSP/SYSTEM/ppsspp.ini on your device.

But I'm pretty sure this is an issue with the Vulkan code so doing so is unlikely to be of any use.

[PepeJulio]

Look at this:

http://m.imgur.com/elL7tjX

That was software rendering with Vulkan, meaning that our problem is the CPU giving wrong instructions.

[tilkinsc]

That was actually software rendering, without vulkan. This definitely means that the graphics card's drivers or a bug is present. I feel that an environment check from vulkan (check and see if anything is set that matters) compared with a working environment would be a good first step to debugging this error. This way we can know if there is any mysterious things enabled via OEM choice. If you think about it, opengl and directX is so developed that everything is absolute and covered (perhaps eventually modified), but since vulkan is (relatively) new, standards might not be developed that well, or followed precisely.

[PepeJulio]

@hrydgard
Hello, Henrik. Since we're having some vulkan changes around, I figured it'd be good to try again something regarding this issue.

@Hydroque proposed testing a bit with software rendering in trying to pinpoint a sollution, so I just checked again and this is MHFU on Vulkan backend with software rendering right now:

https://imgur.com/gallery/calPw

As you can see, nothing draws, which is different from last time.

Now, this is MHFU on OpenGL with software rendering right now:

https://imgur.com/gallery/b4pjC

Hardware is exactly the same. I'm no good guessing what this means, so I'd like any of you to interpret it.

I'd also like to know how to take logs so I can upload them to you. That's probably the best way fix this issue.

Regards,
Pepe

[tilkinsc]

I was bringing up a point to validate the environment because lack of full standards. Everything needed should be set. This is a good set to prevent a mysterious error. We also had some z fighting issues that could be related.

[unknownbrackets]

There's a bug in Vulkan right now causing software rendering to be black.

When using software rendering, the backend code does only one operation: copy the result of the software render to the screen. That means it uses a small subset of the features of your Vulkan driver, and also a small subset of the Vulkan code in PPSSPP.

So, regardless of the result of software rendering, this could still be a bug in PPSSPP's Vulkan backend code in hardware mode. It's hard to tell.

-[Unknown]

[tilkinsc]

Your software mode is ambiguous

[unknownbrackets]

Software rendering draws everything - really, everything - in software.

The benefit is it's not restricted by silly rules like "you can't just access the depth buffer like that" or "that's not how alpha blending ought to work" that OpenGL and Vulkan and Direct3D drivers impose. It's total freedom.

We have workarounds for almost all of the differences between the PSP's rules and modern driver's rules. But they're complex and not all perfect. Testing in software rendering is a good way to figure out if the bug is caused by a rule we're not dodging properly, or maybe it's not even a bug in our rendering code at all.

About the bug: very strange. Have you tried toggling software skinning (this applies "skinning", a model technique, on software where it typically ends up faster), and vertex caching?

I wonder if we're somehow ending up with the wrong kind of depth buffer...

-[Unknown]

[PepeJulio]

Yes, I've tried with those two options on and off. Everything is still like in the attached video above.

[tilkinsc]

I wonder if the depth buffer is inverted, upside down, etc >.>

[hrydgard]

Just worked around a depth-buffer related Mali bug, it might be completely unrelated though, but might be worth giving it another try with the latest build. Works for me though on S8, as usual.

[PepeJulio]

Sadly, it keeps failing.

[PepeJulio]

Hey, surprise! It's working now!!

[hrydgard]

Cool! I guess older Mali drivers also had problems with reverse Z, which was worked around by #10086 .

[tilkinsc]

Hey I was right!

[hrydgard]

Congrats :)