Ppsspp: [1.6.3] [Windows] [Vulkan] Black screen followed by crash on startup (of emulator)

[JacobMrox]

What happens?

PPSSPP Crashes following a black screen for a few (less than 4) seconds without any error or typical "has stopped working" message.

What should happen?

Instead of the black screen and crash the emulator should boot fine as it did in previous versions.

What I tried:

I tried messing around with ppsspp.ini (does 1.6.3 even use that anymore?) and tried changing GPU backend through the ini and much more, I even tried the "most likely not gonna work solutions" suggested to me by other people (aka run as admin, compatibility mode and so on...)

Thoughts:

This issue happened starting with 1.6.3, older builds worked fine, might be graphic related since the GUI doesn't display and crashes afterwards... Debug log doesn't input anything helpful aside from:
46:17:269 EmuThread.cpp:205 I[BOOT]: Done.

Edit: I can confirm 1.5.4 still works, so what changed in 1.6.3 that it doesn't work anymore?
Update: 1.5.4-83 - Works fine, but 1.5.4-86 - Crashes on boot
See this post for complete details about this bug.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

Hardware: intel Core i3
OS: Windows 10
PPSSPP: 1.6.3
Laptop
GPU: AMD Radeon R5 M330

[marosis]

Do you have latest build? https://buildbot.orphis.net/ppsspp/

[JacobMrox]

@marosis Yes, I have tried the latest dev build just now, same problem.

[unknownbrackets]

PPSSPP still uses ppsspp.ini. There have been about 1000 changes between those two versions, however. The biggest change was improvements to multithreading (but these are partially disabled on AMD video cards due to driver bugs.)

Run as admin is almost always not advisable. If nothing else, it can cause it to create files that are read only, making it so you're stuck running as admin in the future.

https://buildbot.orphis.net/ppsspp/index.php?m=fulllist

Can you try to find the first git build with this problem? It also helps to know the last git build that didn't have this problem.

Don't worry, you don't have to test every version to figure this out. The trick is to go by halves. So if you want to find where it broke among 1000 git builds, start with build 500. If it doesn't work, go down by half - otherwise, go up by half. With 10 tries, you can find it among 1000 builds.

For people not experiencing the problem... they're stuck staring at each build one by one, trying to guess the problem. That's like finding a needle in a haystack sometimes. You're the hero that can cut down all the small fry in a few swings of a sword.

-[Unknown]

[JacobMrox]

@unknownbrackets On it...

[JacobMrox]

I followed the halving method, it worked well...

1.5.4-83 - Works fine
1.5.4-86 - Crashes on boot

Seems like the biggest changes in those builds is defaulting to Vulkan, and that was the first thing I suspected, even though my GPU and Driver support Vulkan, it is pretty buggy and always caused crashes in previous builds when switching to it. But why would it default to Vulkan and not read the variables in the ppsspp.ini? is it forced as long as the system supports it? unless it wasn't really doing that..

Or could it be some other change between those builds? there's no other compiled builds between 1.5.4-83 and 86.

Edit: Tested 1.5.4-83 (which works fine) and switched to Vulkan, I get the same exact crash, black screen followed by crash. Please do not force Vulkan as the default option since not a lot of people might be able to use it. I know my hardware should support it but it never worked, even on previous builds, switching to it causes a crash and forcing Vulkan globally is a bad idea (in my opinion).

Edit 2: Used a ppsspp.ini from a friend whose PC does not support Vulkan and is defaulted to DirectX, and 1.6.3 boots fine for me.

Conclusion: My PC supports Vulkan but it doesn't work/never worked. Updated drivers and everything, I guess not everyone can run Vulkan even if it's supported, so PPSSPP defaulting to it causes the crash.

[unknownbrackets]

I wonder how come editing ppsspp.ini wasn't working for you - perhaps editing it in the wrong location?

Perhaps we could default to Direct3D 11 on AMD cards on Windows for now.

-[Unknown]

[JacobMrox]

I'm pretty sure I was editing it in the correct location, replacing it with the one from 1.6.3 who the guy had it on Direct3D 11 was the only thing that worked, are you sure that nothing changed, maybe the variables? because using the older ini files makes it crash (and likewise switching to Vulkan makes it crash too).

And I agree, OpenGL or Direct3D 11 would both do the job, defaulting to Vulkan (imo) was a bad idea, I have a friend too whose PC supports Vulkan but also doesn't work for him.

[AkiraJkr]

Instead of replacing with the .ini from 1.6.3, you're better off just deleting it and starting PPSSPP again...

[JacobMrox]

@AkiraJkr And why would you assume I didn't do that? otherwise how did I trace this bug? I literally went over more than 50 builds and extracted them each in their own folder to test, every build starting with 1.5.4-86 crashes. Plus I extracted 1.6.3 to it's own folder, MULTIPLE TIMES before coming here to report this issue. Maybe you need to read this post first to understand why this problem is happening (and if you prefer it short, it's Vulkan being the default GPU Backend which causes the crash, simply deleting the INI won't fix it since Vulkan is the default GPU Backend for PCs that support it, that's why using an edited INI fixed it).

Facepalm

I suggest the defaulting to Vulkan thing gets changed as it is effecting my friend too, we can't be the only ones either. Thank you! I suppose Vulkan support isn't fully functional for everyone yet, and may not be just AMD specific.

[NikoofDeath]

I'm experiencing this same issue, however, interestingly, it only seems to be affecting the 64 bit version of PPSSPP, and seems to be an issue only with newer AMD GPUs. I had been using the vulkan renderer for a long time, but previously had been doing so with my AMD Radeon HD 7950. However, I recently upgraded to an RX 580, and after doing so, I have started experiencing this issue, but only with the Vulkan and D3D11 renders on the 64 bit exe. All four renderers work fine with the 32 bit version, and OpenGL and D3D9 work on 64 bit. Unfortunately, nothing is output when I try launching ppsspp in debug mode.

I should also note that I tried using older builds I had downloaded (and thus knew had been working with my old GPU), and the behavior remained the same. Additionally, I am using the latest AMD drivers (which I had not used with PPSSPP and my old GPU, so it could be something introduced in one of the latest driver updates).

[unknownbrackets]

Well, if we decide that any broken driver is a reason to make everyone stay in the past, we'll always live in the past.

@hrydgard perhaps we could set a flag in the ini like StartupFailed=True, and then set False after successful startup. That way, we could detect if the driver is crashing during startup and try to round-robin through backends as we do when init fails. It does mean at least one startup failure with broken buggy drivers, though.

A user on Discord apparently found that "disabling their AMD driver" and then re-enabling it fixed it. I guess it needed to be restarted?

-[Unknown]

[hrydgard]

Yeah, been thinking on and off of some kind of startupfailed flag for some time. Though at least last I thought about it, it had interesting interactions with storage permissions on Android... definitely deserves consideration, in any case.

[JacobMrox]

@unknownbrackets Don't get me wrong but it's not really a driver fault when Vulkan is pretty much new. You don't expect people to simply change their phones as a new one comes out? for many valid reason, which is the same case here, it's not about living in the past, it's about stability for everyone.

OpenGL while it may be inferior compared to Vulkan, was pretty much supported on every device, including mobile too, so what change what is not broken? if people want vulkan they can switch to it.

Or like you two said, just make a fail safe check for each to switch to another (best solution).

Edit: I updated my windows to the latest insider build and the driver too, Vulkan now works. I still think a fail safe needs to be implemented as to not constrict the average user and prevent them from using the emulator at all.

[unknownbrackets]

Hm. If there's no storage permission, it simply wouldn't be able to round robin. I agree it's not a good strategy for Android, but in that case we could store a flag in the CACHE directory. That should be available and semi-persistent on all platforms.

Although, I could certainly imagine a sane OS clearing the app's cache whenever it crashes...

I get the argument that Vulkan is new and might crash, but there's a balance here for users who would be happier with the improved features of Vulkan - not just performance, but some rendering will behave more accurately too.

AMD devices are an unfortunate battle ground. On some of them, OpenGL runs poorly too, or crashes.

-[Unknown]

[JacobMrox]

@unknownbrackets Make D3D11 the default for AMD users? or a fail safe in the following order:
Vulkan -> Crash -> OpenGL -> Crash -> D3D11

[TehPlayer14]

Does other Vulkan apps work on your setup?

[NikoofDeath]

@TehPlayer14 Yes, the ones that come to mind are Dolphin, doom 2016, and Serious Sam 2017 Fusion.

Additionally, I very much agree with @unknownbrackets that Vulkan should remain as the default renderer, as besides this issue with newer cards or drivers, it would definitely be much more preferable for AMD cards (given the abysmal state of AMD's OpenGL drivers). Maybe have an external config tool for renderer selection (obviously users can go into the settings files and manually change, but given that the setting uses numbers rather than strings it could be rather confusing)?

[unknownbrackets]

If Vulkan works in other apps, we're probably doing something wrong, or at least unusual. Would anyone with this problem be willing to install Visual Studio 2017 (it's free) and compile and try to trace the crash?

-[Unknown]

[NikoofDeath]

@unknownbrackets ok...

This is really weird.

So using the debug solution presented no issues, the emulator opens as normal. However, when using the release solution, an exception is thrown at line 171 of VulkanContext.cpp
VkResult res = vkCreateInstance(&inst_info, nullptr, &instance_);

That exception?

Exception thrown at 0x00007FFB8CD08735 (GeDoSaTo64.dll) in PPSSPPWindows64.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

This is incredibly bizarre. I have GeDoSaTo installed, but this happens without the program running (I checked to make sure that there wasn't existing injection code as a result of improperly exiting GeDoSaTo). Interestingly PPSSPPWindows64 is whitelisted for GeDoSaTo by default, so I removed it from the whitelist just in case that somehow was causing this issue (it wasn't). Deleting GeDoSaTo64.dll from the GeDoSaTo installation completely fixes the problem (whether I'm debugging, using my own build, or using a precompiled build). Curiously, it seems that Durante implemented the texture scaling features of PPSSPP himself, as described here: http://blog.metaclassofnil.com/?p=306, which could have something to do with the dll being loaded.

Here is the full debug output, in case it can somehow help.

https://pastebin.com/3xi2PnPy

I'm also curious as to whether or not @JacobMrox has GeDoSaTo installed, and if so whether deleting the dll fixes PPSSPP for him as well.

This also doesn't explain why the Vulkan renderer was working fine for me before, as I don't see how a driver update (if you want I could try rolling back just in case that is the issue) or hardware change (from Tahiti GCN to Polaris GCN) could've caused this issue.

[unknownbrackets]

Actually - I think that blog post is related to these PRs: https://github.com/hrydgard/ppsspp/pull/1599 https://github.com/hrydgard/ppsspp/pull/1640 - which is PPSSPP's texture scaling support.

A good idea would be compiling GeDoSaTo in debug mode, and then running Release PPSSPP using debug GeDoSaTo. That might show the crash, which might point to a bug either in PPSSPP or GeDoSaTo.

@PeterTh is there anything you know of that we could be doing that might cause GeDoSaTo to crash on vkCreateInstance? For reference, it's here:
https://github.com/hrydgard/ppsspp/blob/aa927e0681ed76fec3b540218981a2c407a78e47/Common/Vulkan/VulkanContext.cpp#L171

-[Unknown]

[Tabris666]

As AMD user i can confirm this problem is only for amd user,almost every game crash or lags after a set ammount of time,directx9 is the only one that works for amd users at least but you wont be able to use shaders or similar.
It looks like henrik decided the AMD crippling route since older versions work fine on AMD but newer are prone to problems not only that multithreading was removed and core capping for amd are new on latest version
.- detected one of my amd cpu as 1 thread X core,8 cores 8 threads when in the past was working fine and detected 4 thread X core,8 cores 32 threads and my cpu is capable of 32 threads.
.- other amd cpu was detected as 1 thread X core,4 cores 4 threads when that cpu is able of 16 threads.
,. other test pc intel cpu didnt had that problem 2 thread by core,4 cores 8threads in the oldest and the latest they are detected in the same way

[AkiraJkr]

I got reports from a AMD user itself.
-DirectX9, 11 and OpenGL works fine, unknown about Vulkan, but I doubt a Radeon HD 7500 can use it.
-They have never experienced a crash ever in their lives And they have been using PPSSPP since the 1.5 era. Even in the latest dev builds they are fine.

And for other things
-Multithreading was not removed; It was rebuilt. It wasn't working well, causing many crashes and bugs, and was literally unreliable, and that I have to agree. When I played Danball Senki Boost in a laptop with a quad core, it was extremely frustrating to play with the common crashes, and the slightly, unnoticeable performance increase. I have yet to see how it would perform, now that multithreading has been rebuilt, and is permanently on, but in general, a lot of users have received the benefits of it. Please don't spread misinformation.
-You know what is being emulated...right?

[hrydgard]

Please don't accuse me of intentionally crippling things for AMD users. All decisions are made for the overall benefit of users, and in this case there wasn't even a decision made, it seems AMD may have broken something in their drivers for some GPUs.

I can certainly default everyone to D3D9 but most people are better off with Vulkan or D3D11 since D3D9 lacks features like dual source blending. Not sure how to best know which people might have the problem you've been experiencing, maybe we can detect a driver version or particular model...

CPU detection has been fixed now, btw.

[JacobMrox]

Like I said, I am on a Windows 10 Insider Preview now, clean install and all works well. On the public build; no matter how many times I reinstalled my driver even with a clean driver install the issue persisted..
@hrydgard No one is accusing you bro, might just need a false boot check to change the default renderer.

[unknownbrackets]

Latest git should try to switch to Direct3D 11 automatically if there's a crash during startup of the emulator. It will still fail to launch once.

-[Unknown]

[unknownbrackets]

The default backend has been changed to Direct3D 11 / OpenGL in #11621, though it's a shame. Given that and the automatic switching, I'm going to close this. I'm not sure if the GeDoSaTo issue has been resolved, but that's not an issue for this project it seems...

-[Unknown]