Another instance where we needlessly materialized constant zero in a
register. We can just write the carry flag directly.
Before:
0x5280001a mov w26, #0x0 ; =0
0x1a1f035a adc w26, w26, wzr
After:
0x1a9f37fa cset w26, hs
Dual Core is primarily known as one of the first troubleshooting steps when emulation or NetPlay misbehave.
I believe(?) the original intent with having it on by default was likely to support users with weaker machines. However, I believe it would be a lot more reasonable for users to manually enable dual core if they really need the performance boost, rather than it is for them to have come ask us in support channel why their cleanly-installed Dolphin is not emulating their games properly.
Instead, this creates a fragile first impression where a clean install of Dolphin is already set up in a way that leads to inexplicable crashes, subtle timing bugs, and NetPlay desyncs.
Note: This changes only applies to the Desktop application, since mobile devices *do* really need the performance boost.
For thread safety, we shouldn't return any pointers or references that
can be used to mutate the state of the PPCSymbolDB. This should be the
final part of making PPCSymbolDB thread safe unless I've missed
something.
9395238 added locking in some PPCSymbolDB functions that access member
variables, but far from all. To ensure thread safety, this commit adds
the missing locking.
9395238 added a mutex to PPCSymbolDB, and made functions return with an
"empty" result if called while the mutex is locked. This new behavior
has the potential to affect not only less important call sites like the
symbol printing mentioned in a comment, but also the JIT deciding if it
should HLE a function.
A later commit in this pull request decreases the amount of lock
contention, reducing the performance impact of this commit.
Aims to fix https://bugs.dolphin-emu.org/issues/13686.
I'm using a less efficient approach for Jit64 than for JitArm64. In
JitArm64, I'm flushing in the slow access code, but in Jit64, I'm
flushing before the split between the slow access code and the fast
access code, because Jit64 doesn't keep register mappings around for
when it's time to emit the slow access code. But the flushing code is
only emitted when there are memory breakpoints with conditions, so I'd
say that this is a performance loss we can live with.
The next commit will add another piece of code that depends on this
assumption that we've been making. Good opportunity to document it.
In practice, all callers of EmitBackpatchRoutine are locking X30.
When Android sends Dolphin to the background, emulation *must* pause,
otherwise emulation continues running and continues outputting audio to
the user. RetroAchievements mustn't be allowed to override it.
The SetDisc function calls AchievementManager::LoadGame with the game's
volume. Calling AchievementManager::LoadGame again afterwards with
nullptr prevents RetroAchievements from working.
Use ToolTipWidget::SetDescription insead of QWidget::setTooltip to put
the description in the BalloonTip with the title, instead of having the
description be in a separate standard tooltip.
It is useful enough for the Code widget to be enabled the first time
debugging is enabled, but it should not be re-enabled every time the
setting is toggled off and then back on. This also ensures that the
interface is consistent if debugging is enabled without using the
checkbox.
