Emulator

*Emulator hanging forever WHEN launch

Tested 5.0-349 and not seeing this, using Geforce GTX 970 (368.81), Windows 10 x64.

seapancake, tested on 349 - still hangs

Windows says: "dolphin doesn't unswer: wait for respond or close the programm?"

What other processes are you running? Which version Nvidia driver are you using?

Do you see anything in Event Viewer? (Start -> type 'Event Viewer' then click System)

1. no foreground processes
2. 368.81 driver, Windows 10 Pro Anniversary update
3. nothing interesting in system and application tabs except of "application hang" event when I force closed Dolphin

Can't think of anything that it might be, I'd suggest bi-secting the issue. You can use this tool to make it a bit easier: https://github.com/Helios747/DolphinBisectTool

I had done some research:
build 5.0-72 - no hanging
build 5.0-76 - hanging exist

same problem for few other users here https://github.com/dolphin-emu/dolphin/pull/3510#issuecomment-230109827

Good fine, this narrows it down to https://github.com/dolphin-emu/dolphin/pull/3510 possibly having an infinite. I'm locked out of the forums due to bad password attempts, would suggest contacting akyryz to get him to put debugging information here. and badkarma12 so we can compare your exact setups.

Also worth contacting JMC47 (IRC or forums) to see if he replicate it.

JosJuice,
you are right about criteria.
Render to main window OFF + Borderless full screen OFF = hangs
Render to main window ON + Borderless full screen OFF = doesn't hang
Render to main window OFF + Borderless full screen ON = hangs
Render to main window ON + Borderless full screen ON = doesn't hang

The problem here is that Dolphin violates the DXGI: Best Practices, which states that you should never lock the UI thread on the GPU thread. The reason for that is because DXGI (which runs on the GPU thread) will also send messages to the UI thread. This means there is a lot of potential for rare race conditions that deadlock the emulator.

This race condition has been known since exclusive fullscreen was first implemented, however it seems PR 3510 has exposed it due to changes in the initialization order. Here's what's happening:

1. The GPU thread is initialized and DXGI sends some messages to the UI thread for initialization.
2. The UI thread triggers a switch to fullscreen as the "Use Fullscreen" option is enabled.
3. The GPU thread switches to exclusive fullscreen and DXGI sends some message to the UI thread to change its style.
4. The UI thread calls UpdateGUI() which is called numerous times and includes a LockAndPause() which locks on the GPU thread.
5. Both threads are now deadlocked with the GUI thread waiting on the UI thread to handle the message and the UI thread waiting on the GPU thread to pause.

There are two ways to solve this as documented in the DXGI Best Practices:

Hard way: "To avoid this, never block the message pump."

This requires we make any interaction with the GPU thread asynchronous, which is difficult given the numerous usages of LockAndPause(). Though never blocking the UI thread is generally good practice.

Easy way: "If a block is unavoidable, then all DXGI interaction should occur on the same thread as the message pump."

This would either involve moving the Render Window to the GPU thread (which means render-to-main is no longer possible) or making sure that after initialization of the backend all DXGI calls are done by the UI thread. I'll make an attempt at implementing the latter option.