search

hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.19k stars 2.17k forks source link

Vulkan only crash on Final Fantasy Tactics WoTL #10418

Closed chaosenvoys closed 6 years ago

chaosenvoys commented 6 years ago

Crashes at character palacement screen at every start of the battle, only happened when using vulkan Device: lg v20 Processor: snapdragon 820 Gpu: adreno 530 Ppsspp v.1.5.4.

nergdron commented 6 years ago

it's not crashing at the battle start for me, but I do get an error message shortly after starting battles saying texture memory is exhausted, and then it breaks in weird ways. so it feels like there's some leak on texture allocations in the Vulkan codebase, and FFT's use of many small textures really brings this behaviour out.

chaosenvoys commented 6 years ago

Yeah, it seems so, if i save a savestate in battle after entering using openGL, and load the in battle savestate when using vulkan, everything runs really nice.. I'm running th v1.5.4 gold official though, and MHP3RD HD really runs at a stable 30fps on vulkan.. Really hoping to play wotl vulkan only too..

zminhquanz commented 6 years ago

@chaosenvoys Hello , I tested on my Galaxy S7 , on latest firmware and using Vulkan API 1.0.3.1 , version 48.765.3686 driver , it doesn't crash , have you update firmware on LG V20 https://vulkan.gpuinfo.org/displayreport.php?id=1202

hrydgard commented 6 years ago

@chaosenvoys Do you have texture upscaling set to off? If not, does it make a difference if you do?

When the game does palette animation, tons of new textures are being allocated very quickly, which seems likely to trigger bugs in vulkan drivers maybe, or simply runs out of memory or some other resource limit - especially likely if you have texture upscaling enabled.

@unknownbrackets this can be seen very clearly in the vulkan allocator visualizer (the allocator doesn't behave too strangely except sometimes leaving empty blocks behind for longer than expected). There's good reason for keeping around textures with the same address but different palettes, but vulkan is so fast at uploading textures that I'm not sure those reasons are no longer valid.

chaosenvoys commented 6 years ago

@hrydgard yes, the texture upscaling is set to off.. this is what happened when we enter battle https://www.dropbox.com/s/4pcbc38icht1m3p/mobizen_20180218_221239.mp4?dl=0

hrydgard commented 6 years ago

@chaosenvoys since you're using PPSSPP Gold (thanks!) I guess you are using version 1.5.4?

Can you also install the latest build from https://buildbot.orphis.net/ppsspp/ (will install side by side with Gold) and see if it's fixed in that? (Be careful not to use save states in that if you want to keep playing using Gold).

chaosenvoys commented 6 years ago

@hrydgard yes, I'm using the 1.5.4 version from the play store. Just installed the latest from buildbot https://github.com/hrydgard/ppsspp/commit/864eb5dcadcd3285d3f734492b3e61c5cce673f4, but the issue is still there, and it still crashes at the exact time when entering battle.. no problem when using the open gl though

zminhquanz commented 6 years ago

@chaosenvoys Which driver of adreno you using , and vulkan api version ?

chaosenvoys commented 6 years ago

@zminhquanz Vulkan Api version 1.0.20 Driver version 37.864.1478 Have you tried entering the random battles? First few story battle went on without any problems, the only problem is when entering battle from world map, like random battles

unknownbrackets commented 6 years ago

I'll check - but there are some games that, annoyingly, flip back and forth between palettes when drawing tiles so I'm not confident that'd perform well.

-[Unknown]

hrydgard commented 6 years ago

Maybe we should keep track of textures with the same address but different CLUTs as a "set" instead of having separate texture cache entries and if there are too many in one such set stop caching them. Dunno how efficient we could get that though.. just thinking.

unknownbrackets commented 6 years ago

If you enable "retain changed textures" it stops with the cyclic allocation. I think this indicates that the textures are simply changing (which I believe is true in this game - a PS1 port), and not something about CLUTs?

Wouldn't caching less textures and uploading more only mean more allocation cycles?

-[Unknown]

hrydgard commented 6 years ago

Perhaps, I didn't actually investigate in detail yet, just noticed that in the case I was testing it happened when fading to blue, which I suspected was a CLUT fade. I was thinking that since fading CLUTs would make the IDs different each frame it would keep them around in the texture cache until they expire which would cause them to stick around longer and be deleted later than if they were deleted the next frame when we recognize that another texture is the same but has a different CLUT and there are too many already. Maybe.

unknownbrackets commented 6 years ago

Here's a change that more aggressively reuses memory:

https://github.com/hrydgard/ppsspp/compare/master...unknownbrackets:vulkan-memory?expand=1

I'm not sure if the trade-off will always be good, but it doesn't seem to hugely impact NVIDIA performance wise.

But maybe I misunderstood: at character placement screen means while using character placement, or after completing character placement? I assumed the former based on wording.

If we're talking about the spike in allocation after pressing start, we'd still have to allocate if we want to draw with the right palette, but maybe we could decimate the other variants more aggressively in that case.

It spikes up to 155 MB of usage, and allocates 4-5 MB per frame. So that means about 30 frames. If I make it kill all textures with clut after 5 frames of unuse (this requires more frequent decimation), it only goes to 20 MB. Not sure if that might have negative effects.

-[Unknown]

hrydgard commented 6 years ago

Not sure if we're talking about the same memory flood, here's what I'm seeing when the very first battle of the game starts, this should be over 360 megabytes with 32MB pages...:

memory_overload

By the way, I'm not sure we need having multiple slab sizes at all. We could just start and stay at 32MB, seems like a reasonable compromise really, or what do you think?

unknownbrackets commented 6 years ago

Well, I think they could be bigger, the reason was to allow for lower allocation when not as much was used (especially in case of multiple allocators.) I think we're only visualizing the main allocator?

But I do think we could start the texture allocator larger.

Ah, you're looking at a different mission - the very first one on a new game looks to be about 6 MB per frame, capping somewhere above 311 MB. Killing after 10 reduces it to 70 MB...

-[Unknown]

hrydgard commented 6 years ago

Yeah, this is just the main texture memory allocator, since it's the most heavily used one. Could of course also visualize others (the one for thin3d, what else? the rest are linear) but doesn't seem as interesting.

[edit: removed suggestion you already proposed above, to decimate faster when we're allocating fast]

hrydgard commented 6 years ago

@chaosenvoys try build 565, it has unknown's partial fix above.

chaosenvoys commented 6 years ago

@hrydgard It still crashes when entering battles with build 565, but this time i can see the character placement screen a little bit before it crashes

hrydgard commented 6 years ago

Hm, surprising, then it's probably not only about running out of memory... but could very well be some driver bug.

chaosenvoys commented 6 years ago

I'll try on more recent devices like the note 8, will report again after testing.

unknownbrackets commented 6 years ago

Oh, so it crashes before you're even able to use the character placement screen? Hm.

-[Unknown]

chaosenvoys commented 6 years ago

@hrydgard @unknownbrackets the very first battle doesn't crash when using vulkan, because the screen isn't going from world map to the character placement screen.. i played the first battle using vulkan and it doesn't crash.. i think the problem lies on when transitioning from world map to character placement screen..

Haven't had the time to try on my note 8 though

zminhquanz commented 6 years ago

Oh , it's older than on my Galaxy S7 using Vulkan API 1.0.3.1

zminhquanz commented 6 years ago

screenshot_20180219-101357 screenshot_20180219-101429 screenshot_20180219-101421 I think it about driver

zminhquanz commented 6 years ago

I play on 1.5.4 official and it wasn't crashed after i finished first battle in game , now i finish second battle and it wasn't crashed

chaosenvoys commented 6 years ago

@zminhquanz on the mandalia plain battle it didn't crash at character placement screen? The battle with monsters not the humans.. i think it was the third battle, transitions from world map to character placement screen..

chaosenvoys commented 6 years ago

@hrydgard @zminhquanz @unknownbrackets Just tested on my note 8, and it doesn't crash.. a little stutter on transitioning from world map to character placement screen, but no crash.. maybe it's a driver problem after all

zminhquanz commented 6 years ago

@chaosenvoys Yes , i tested on next to the battle , have chocobo and monster , it doesn't crash