This caused invalidations that only affected the last portion of a JIT block
to fail, breaking Wii64's block linking. It might affect a bunch of other
games too; I haven't tested.
When we cleaned up the code to calculate the shm_position and total_mem
in one step, we sometimes skipped over certain views because they were
Wii-only. When looking at the total memory, we'd look at the last field,
whether or not it was skipped. Since Wii-only fields are the last view,
this meant that the shm_position was 0, since it was skipped, causing us
to map a 0-sized field. Fix this by explicitly returning the total size
from MemoryMap_InitializeViews.
Additionally, the shm_position was being calculated incorrectly because
it was adding up the shm_position *before* the mirror, rather than after
it. Fix this by adopting a scheme similar to what we had before.
The code to calculate the offsets into the SHM file wasn't properly
respecting the skip flags, causing it to calculate offsets beyond
the end of the SHM file.
This code was ported from out_ptr, which was a double-pointer, and
wanted to double-check that the proper arena was actually allocated.
When I ported it to store the pointer directly in the view regardless
of whether out_ptr was non-NULL, I got confused here and instead
caused the code to only free the arena if the first byte was non-zero.
This code originally tried to map the "low space" for the Gamecube's
memory layout, but since has expanded to mapping all of the easily
mappable memory on the system. Change the name to "GrabSHMSegment" to
indicate that we're looking for a shared memory segment we can map into
our process space.
These are effectively unused, since the memmap already maps them in one
place. For 32-bit, they might have some slight advantage, but we already
special-case the regular "high-mem" pointer for 32-bit, so just use the
one we already have...
Before this change I always got this when closing dolphin-emu-nogui:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 10 (X_UnmapWindow)
Resource id in failed request: 0x3400003
Serial number of failed request: 215
Current serial number in output stream: 219
terminate called without an active exception
Aborted
A very subtle difference in how I calculated the timebase value seems
to have broken Karaoke Revolution; this seems to fix it. Also be a bit more
paranoid in conditions for mftb merging.
- Get rid of ArmMemTools.cpp and rename x64MemTools.cpp to MemTools.cpp.
ArmMemTools was almost identical to the POSIX part of x64MemTools, and
the two differences, (a) lack of sigaltstack, which I added to the
latter recently, and (b) use of r10 to determine the fault address
instead of info->si_addr (meaning it only works for specifically
formatted JIT code), I don't think are necessary. (Plus Android, see
below.)
- Rename Core/PowerPC/JitCommon/JitBackpatch.h to Core/MachineContext.h.
It doesn't contain anything JIT-specific anymore, and e.g. locking
will want to use faulting support regardless of whether any JIT is in
use.
- Get rid of different definitions of SContext for different
architectures under __linux__, since this is POSIX. The exception is
of course Android being shitty; I moved the workaround definition from
ArmMemTools.cpp to here.
- Get rid of #ifdefs around EMM::InstallExceptionHandler and just
provide an empty implementation for unsupported systems (i.e.
_M_GENERIC really). Added const bool g_exception_handlers_supported
for future use; currently exception handlers are only used by the JIT,
whose use implies non-M_GENERIC, but locking will change that.
- Remove an unnecessary typedef.
This is pretty much a step backwards in our code. We used to use attributes in our PP shader system a long time ago but we changed it to attributeless
for code simplicity and cleanliness. This reimplements the attribute code path as an optional path to take in the case your system doesn't work with
attributeless rendering. In this case the only shipping drivers that we can know for sure supports attributeless rendering is the Nexus 5's v95 driver
that is included in the Android 5.0 image.
I hadn't planned on implementing a work around to get post processing working in these cases, but due to us force enabling the PP shader system at all
times it sort of went up on the priority list. We can't be having a supported platform black screening at all times can we?
This particular issue was fixed in the v66 (07-08-2014) development drivers from Qualcomm.
To make sure we cover all drivers that may or may not have the issue fixed, make sure to mandate v95 minimum to work around the issue.
The next commit is the actual work around for post processing for this.
Due to changes in how we render to the final framebuffer we no longer encounter this bug.
With the change to post processing being enabled at all times and no longer using glBlitFramebuffer, Qualcomm no longer has the chance to rotate our
framebuffer underneath of us.
This particular bug from our friends over at Qualcomm manifests itself due to our alpha testing code having a conditional if statement in it.
This is a fairly recent breakage this time around, it was introduced in the v95 driver which comes with Android 5.0 on the Nexus 5.
So to break this issue down; In our alpha testing code we have two comparisons that happen and if they are true we will continue rendering, but if
they aren't true we do an early discard and return. This is summed up with a fairly simple if statement.
if (!(condition_1 <logic op> condition_2)) { /* discard and return */ }
This particular issue isn't actually due to the conditions within the if statement, but the negation of the result. This is the particular issue that
causes Qualcomm to fall flat on its face while doing so.
I've got two simple test cases that demonstrate this.
Non-working: http://hastebin.com/evugohixov.avrasm
Working: http://hastebin.com/afimesuwen.avrasm
As one can see, the disassembled output between the two shaders is different even though in reality it should have the same visual result.
I'm currently writing up a simple test program for Qualcomm to enjoy, since they will be asking for one when I tell them about the bug.
It will be tracked in our video driver failure spreadsheet along with the others.
We will now rely on Memory::CopyFromEmu to do bounds checking.
Some games actually load palettes from 0x00000000, despite the
fact no valid palette data should ever be there.
Fixes Issue 7792.
Lioncash