Removed the DSP LLE on separate thread option.

[skidau]

The DSP thread will be enabled if the game is an AX ucode game and if the host has more than two cores (not including hyperthreading).

[JMC47]

What about situations like Netplay/Movies where you want determinism?

[skidau]

@JMC47 good point. How about I disable the DSP thread if Single core mode is enabled? or GPU determinism?

[JMC47]

@skidau: If not for Rogue Squadron/Rebel Strike, Pac-man World Rally, I can't think of any reasons to use LLE on Thread. I think it may be better to leave this alone for right now, and hope that HLE gets fixed for the remaining titles where it has serious problems.

When LLE is no longer needed for performance, then the option of LLE on thread can just be removed, as it's a hack anyway. That's just my semi-insane thoughts on it.

[skidau]

Yes, DSP HLE is a hack and DSP LLE on thread isn't.

DSP HLE may never be fixed as the problems it has might be stemming from the reason why DSP HLE is fast. It is not a good idea to clutter the UI while waiting for a DSP HLE fix that may never eventuate.

[JMC47]

That is true. I must have been mistaken, because I remember DSP-HLE on thread causing tons of issues before it was removed.

DSP-LLE on thread/off thread still have uses. Maybe move the option to the game properties page or something? That could work if you don't think it belongs on the audio page. I just think there are too many edge cases where having LLE on/off thread could be useful. Let me think it out.

1. Zelda ucode games. Need to have it off; easily fixed by forcing it as an INI setting, though.
2. Netplay/Movies/other situations requiring syncing. They need determinism.
3. Dualcore Processors (You have that covered.)

I can't think of any other reasons though, so, I think with what you said in the previous comments would cover the basic situations.

One other worry: I don't know if there are still cases where LLE on thread has more overhead than LLE without the extra thread, but that used to be the case for quite a while.

[skidau]

This PR will disable LLE on thread if the Zelda ucode is running.

There is an overhead incurred with DSP on thread, but this is offset by the parallelism available in the AX ucode. For example, in Metroid Prime's cinematics, I am getting speeds of 135% on thread vs 125% no thread.

[comex]

The determinism switch is Core::g_want_determinism & Core::UpdateWantDeterminism(). Please note that it can be toggled in the middle of play by enabling or disabling recording.

[RachelBryk]

Unless you can guarantee that always initializing with thread won't cause desyncs for movies or netplay, i think this shouldn't be merged. Even the smallest risk of a desync is a critical problem.

[skidau]

@RachelBryk have changed the code to not initialise with thread if a movie or netplay is running.

[RachelBryk]

What about the case of starting recording in the middle of emulation?

[skidau]

That is taken care of in DSP_Update()

[RachelBryk]

Are you certain it won't happen too late, after it has already caused a desync?

[skidau]

I cannot think of how it could cause a desync as Dolphin works with timeslices, but this needs testing.

[JMC47]

I really don't know how to test this for desyncs. I tried doing some recording on and off and nothing broke, i guess?

[RachelBryk]

There is no reasonable way to test it.

[CrossVR]

This PR causes Zelda games to freeze during boot when Dolphin is running in Debug configuration.

[Toff-kun]

Starting from this PR (build 4488 and up) I noticed a strange performance regression in Silent Hill Shattered Memories NTSC, from VPS 70 to VPS 55 during the intro using HLE and AMD FX-8350.