Many Android users want to disable SyncOnSkipIdle as a performance
hack, to the point where it's often suggested as something to
paste into Dolphin.ini (if not to use a fork). If adding it as
a setting in the GUI gives us an opportunity to explain what the
setting actually does and stops people from pasting stuff they
don't understand into INI files, I think it can be worth adding
despite how it can make games unstable. It not being in the GUI
doesn't seem to be stopping people from disabling it anyway.
The added setting in the GUI is a three-way setting called
"Synchronize GPU Thread" with the following alternatives:
"Never": SyncGPU = False, SyncOnIdleSkip = False
"On Idle Skipping": SyncGPU = False, SyncOnIdleSkip = True
"Always": SyncGPU = True, SyncOnIdleSkip = True
See PR 8203 for background on the game INI deletion prompt.
It's been almost two years since PR 8203 was merged, so you
would think that people are no longer creating game INIs that
contain a copy of every global setting, right? Unfortunately,
MMJ was forked not too long before that and never backported the
change, so right now there's a not insignificant number of people
online posting game INIs full of this garbage for others to use.
One thing that's been missing from the game INI deletion prompt
is a description of what the problem with having tons of extra
lines in a game INI actually is. This change adds that, in the
the hope that it will make people ignore the warning less often.
This option does in fact not enable and disable logging as a whole.
You can get logs through logcat regardless of this setting.
Also taking the opportunity to remove the reference to
the "dolphin-emu" folder name since we will no longer be
using that folder once scoped storage is applied to Dolphin.
The output of instructions like fabsx and ps_sel is store-safe
if and only if the relevant inputs are. The old code was always
marking the output as store-safe if the output was a single,
and never otherwise.
Also, the old code was treating the output of psq_l/psq_lu as
store-safe, which seems incorrect (if dequantization is disabled).
This improves the speed of verifying Wii WIA/RVZ files.
For me, the verification speed for LZMA2-compressed files
has gone from 11-12 MiB/s to 13-14 MiB/s.
One thing VolumeVerifier does to achieve parallelism is to
compute hashes for one chunk of data while reading the next
chunk of data. In master, when reading data from a Wii
partition, each such chunk is 32 KiB. This is normally fine,
but with WIA and RVZ it leads to rather lopsided read times
(without the compute times being lopsided): The first 32 KiB
of each 2 MiB takes a long time to read, and the remaining
part of the 2 MiB can be read nearly instantly. (The WIA/RVZ
code has to read the entire 2 MiB in order to compute hashes
which appear at the beginning of the 2 MiB, and then caches
the result afterwards.) This leads to us at times not doing
much reading and at other times not doing much computation.
To improve this, this change makes us use 2 MiB chunks
instead of 32 KiB chunks when reading from Wii partitions.
(block = 32 KiB, group = 2 MiB)
This can't actually happen in practice due to how WAD files work,
but it's very easy to add support for thanks to the last commit,
so we might as well add support for it.
The performance gains of doing this aren't too important since you
normally wouldn't run into any disc image that has overlapping blocks
(which by extension means overlapping partitions), but this change also
lets us get rid of things like VolumeVerifier's mutex that used to
exist just for the sake of handling overlapping blocks.
Panic alerts in DiscIO can potentially be very annoying since
large amounts of them can pop up when loading the game list
if you have some particularly weird files in your game list.
This was a much bigger problem back in 5.0 with its
"Tried to decrypt data from a non-Wii volume" panic alert, but
I figured I would take it all the way and remove the remaining
panic alerts that can show up when loading the game list.
I have exempted uses of ASSERT/ASSERT_MSG since they indicate
a bug in Dolphin rather than a malformed file.
If we know at compile time that the PPC carry flag definitely
has a certain value, we can bake that value into the emitted code
and skip having to read from PPCState.
Léo Lam