Google has gotten their act together and fixes a few of the signal handling headers.
Change over to a header that works on both r10 32bit and r10 64bit.
32bit has the old "broken" headers as in some didn't even exist.
64bit has the "fixed" headers that one would expect on any regular unix system.
There were some fixes back on March 13th, 2014 for fixing compiling on MIPS64.
Also some fixes on June 25th, 2014 for SPARC64 fixes.
Probably more things, but those are what I care about.
This is the bare minimum required to run a few games on AArch64.
Was able to run starfield and Animal Crossing to the Nintendo logo.
QEmu emulation is literally the slowest thing in the world, it maxes out at around 12mhz on my Core i7-4930MX.
I've tested a few instruction encodings and am expecting most to work as long as one stays away from VFP/SIMD.
This implements mostly instructions to bring up an initial JIT with integer support.
This can be improved to allow ease of use functions in the future, dealing with the raw imms/immr encodings is probably the worst thing ever.
This value was "helpful" for debugging when the stack got corrupted.
Helpful that if gpr[1](Which is the stack pointer with PPC ABI) is zero then the interpreter would spam huge amounts of annoy text saying that we
managed to get in to a "corrupted" state.
This is incremented every instruction on the interpreter, or every block run on the JIT64....Only if debugging is enabled(JIT64 it is a const
variable)
The message is only outputted when interpreter is used and debugging is enabled.
This is no longer required since we don't support x86_32 anymore.
x86_64 implies SSE2 support.
Also this check was a bit messed up and was hitting on Generic builds.
Only show the JIT cores on x86_64(Will have its own issues once we reach that point)
Show AArch64 JIT if running on a AArch64 device(Good luck with that for now. Future proofing though)
This is available in a PR here: https://github.com/taka-no-me/android-cmake/pull/23
The maintainer of the android toolchain cmake file seems to be AWOL for now.
I have tested this file personally and it works, it just isn't merged in yet
We were generating a texture without ever setting the data to a known value.
This happened on the old code as well, just that PP shaders are receiving some love and people are using it and noticing some of its issues.
The framebuffer is no longer rotated the wrong way around in Qualcomm's latest development drivers.
They did something right, only took them over a year.
This catches most instances of configuration failures that can happen in a post processing shader.
Gives a user a helpful error message that lets them know what they have failed to set up correctly
Seems mesa has a quirk where
define THING(x) (#x)
is the same as
define THING(x) (##x)
Didn't realize I messed it up since it just worked since I only tested on Mesa.
This class loads all the common PP shader configuration options and passes those options through to a inherited class that OpenGL or D3D will have.
Makes it so all the common code for PP shaders is in VideoCommon instead of duplicating the code across each backend.
On error mmap returns MAP_FAILED(-1) not null.
FreeBSD was checking the return correctly, Linux was not.
This was noticed by triad attempting to run Dolphin under valgrind and not getting a memory space under the 2GB limit(Because -1 wraps around on
unsigned obviously)
In the cases where we support the binding layout keyword, use it for more than binding UBO location.
This changes it so it is supported for samplers as well.
Instances when this is enabled is if a device supports GL_ARB_shading_language_420pack, or if it supports GLES 3.10.
This isn't technically the correct place to have the downcount variable, but it is similar to what PPSSPP does to gain a bit of extra speed on ARM.
We access this variable quite a bit, with each exit in a block it is subtracted from.
On ARM this required four instructions to load and store the value, while now it only requires two.
This gives an average of 1FPS gain to most games.
Examples:
Crazy Taxi: 54FPS -> 55FPS
Luigi's Mansion: 20FPS -> 21FPS
Wind Waker(Save Screen): 27FPS -> 28FPS
This seems to average a 6mhz to 16mhz CPU core emulation improvement in the few games I've tested.
When I dropped ARM from a generic target, this caused the vertexloader to try using the JIT path.
Instead of !_M_GENERIC, check for _M_X86 instead. Since it is only for the x86 target
The register cache can be filled to the point that when dumping them the FixupBranch goes over the maximum size of 0x80.
Force them to use the "5byte" variant of the jump.
If we were able to determine if the length we had to jump was <0x80 in the future this could be a slight optimization.
This has to be done in bcctrx, bclrx, and twx. It was already done in bcx before.
This fixes issue 7378.
Ryan Houdek