After fixing the deadlock in #3006, it is now possible for log
messages to flood in faster than UpdateLog can render them.
This causes it to never return, locking up the gui thread and
filling the windows message queue (which triggers the stack
overflow bug in older versions of Wx)
snd_pcm_writei() is meant to block block until all samples are written,
but apparently in some situations it can block for much longer, prehaps
even a infinite time, in the case of virtual machine FifoCI runs in.
Because it grabed a mutex before blocking, it could also block the
Clear() call for an infinite length of time, blocking dolphin's emu
thread.
snd_pcm_writei() also takes 10-15 seconds if you run dolphin under GDB
and can randomly take 5 or so seconds during normal usage.
By moving all the pause code to the ALSA thread, Clear() no-longer
blocks and everyone keeps their sanity.
Texture updates have been moved into TextureCache, while
TMEM updates where moved into bpmem. Code for handling
efb2ram updates was added to TextureCache.
There was a bug for preloaded RGBA8 textures, it only copied
half the texture. The TODO was wrong too.
Instead of blindly using the expected width, clamp it to the stride of the
buffer which dx11 returns. This prevents use from reading invalid memory
at the end of textures.
This doesn't solve the base issue of what to do when a game tries to copy
from outside the efb. On real hardware it returns random noise (biased
to all ones)
An KHR_debug callback could end up waiting for a mutex
on a thread which calls windows system functions.
While this is not expressly forbidden by the standards,
it does forbid directy calling windows system functions
from a KHR_debug callback. Close enough.
Instead of having special case code for efb2tex that ignores hashes,
the only diffence between efb2tex and efb2ram now is that efb2tex
writes zeros to the memory instead of actual texture data.
Though keep in mind, all efb2tex copies will have hashes of zero as
their hash.
Addded a few duplicated depth copy texture formats to the enum
in TextureDecoder.h. These texture formats were already implemented
in TextureCacheBase and the ogl/dx11 texture cache implementations.
The last heuristic wasn't quite smart enough and had a few
false positives in Mario Kart: Double Dash and Metroid prime 2.
Now we only activate if the game is rendering a 16:9
projection to a 4:3 viewport.
Someone suggested on IRC that we should make a database of memory
locations in GameCube games which contain the 'Widescreen' setting
so we can automatically detect if the game is in 4:3 or 16:9 mode.
But that's hardly optimal, when the game actually tells the gpu
what aspect ratio to render in. 10 min and 6 lines of code later,
this is the result. Not only does it detect the correct aspect ratio
it does so on the fly.
I'm a little suprised nobody thought about doing this before.
fcmpo and fcmpu can be matched by the REORDER_CMP pass, as they set CR0
and they can cause interrupts if the fpu is disabled.
So we add an extra check to make sure op a is an integer op too.
The constructor sets up way_from_valid and way_from_plur as fast lookup
tables for implementing the PLRU algrothm. Then the Init function
memsets them to zero, meaning the instruction cache will now always
choose the first way in each set.
This degrades the cache from 128 sets, 8 way to 128 sets, 1 way.
Not only does fixing this bug increase accuracy, but it increases
preformance too, giving a 1% speedup to interpreter.
Instead of opening... and... closing... files... after... every...
file... operation... (which can be slow, especially if a virus scanner
is running), we catch attempts to open the same file twice and
only open one copy of the file.
Dolphin uses threads, but never actually pulled them it. Normally
some library we depend on would pull threads in, but there are
potential builds that forget to pull in threads.
Not deleted, because it's the only option for some other operating
systems such as FreeBSD or any other slightly exotic operating
system someone might try and run dolphin on.
On the first boot of Pokemon Snap it copies a 144KB file to the Wii's
NAND, but it only copies 32 bytes per IPC write call.
This was causing dolphin to open and close the same file over 4000
times. This wouldn't usually be a huge issue, except some operating
systems (namely Windows) allow 3rd party programs (namely antivirus
software) to hook all accesses to the filesystem.
This causes the antivirus software to scan the same file for viruses
4000+ times, which is kind of slow.
This fix reduces the initial boot time of pokemon snap from 3+ min
to just a few seconds. Could also improve other games which write
things to NAND.
Will break a few things, see the next commit for an improved fix.
Scott Mansell