If the inputs are both float singles, and the top half is known to be identical
to the bottom half, we can use packed arithmetic instead of scalar to skip
the movddup.
This is slower on a few rather old CPUs, plus the Atom+Silvermont, so detect
Atom and disable it in that case.
Also avoid PPC_FP on stores if we know that the output came from a float op.
Rather than playing terrible hacks to determine the start of input
frames, just update system input periodically. Specifically, every
60th of a second.
The game can never change these, so there's no reason to make it
dynamic. Just put the constants in the code.
While we're at it, take the time to clean up the code and also
and document several of the hacks we're doing inside to make the code
clearer to understand.
This is the only use for a lot of unused methods and structs, and it's a
poorly written mess that doesn't even compile. Just remove it so we can
clean up the rest of a lot of code.
This takes the giant mess of controller-like devices (dance mat and
steering wheel) down to something more manageable, similar to how
the Donkey Konga bongo controller works.
Based-on-a-patch-by: comex <comexk@gmail.com>
This doesn't seem to be necessary anymore now that FPRF is implemented in the
JIT. Technically, this isn't the same as before, since the JIT doesn't
implement the fcmp exception semantics, but as far as testing has shown, this
doesn't seem necessary.
This should make games that use FPRF a few percent faster (e.g. F-Zero GX)
since fcmpx no longer has to be fallbacked.
Also, this avoids keeping the system awake if a game is not being
played.
Frankly, I don't know what the point of precisely tracking these things
is, but that's how the API works. Feel free to add analogous
functionality on other platforms.
Move the JITed function/basic-block registration logic out of the CPU
subsystem in order to add JIT registration to JITed DSP and
Video/VertexLoader code.
This necessary in order to add /tmp/perf-$pid.map support to other
JITed code as they need to write to the same file.
'perf' is the standard builtin tool for performance analysis on recent
Linux kernel. Its source code is shipped within the kernel repository.
'perf' has basic support for JIT. For each process, it can read a file
named /tmp/perf-$PID.map. This file contains mapping from address
range to function name in the format:
41187e2a 1a EmuCode_804a33fc
with the following entries:
1. beginning of the range (hexadecimal);
2. size of the range (hexadecimal);
3. name of the function.
We supply the PowerPC address of the basic block as function name.
Usage:
DOLPHIN_PERF_DIR=/tmp dolphin-emu &
perf record -F99 -p $(pgrep dolphin-emu) --call-graph dwarf
perf script | stackcollapse-perf.pl | grep EmuCode__ | flamegraph.pl > profile.svg
Issue: perf does not have support for region invalidation. It reads
the file in postprocessing. It probably does not work very well if a
JIT region is reused for another basic block: wrong results should be
expected in this case. Currently, nothing is done to prevent this.
This is a fairly lengthy change that can't be separated out to multiple commits well due to the nature of fastmem being a bit of an intertangled mess.
This makes my life easier for maintaining fastmem on ARMv7 because I now don't have to do any terrible instruction counting and NOP padding. Really
makes my brain stop hurting when working with it.
This enables fastmem for a whole bunch of new instructions, which basically means that all instructions now have fastmem working for them. This also
rewrites the floating point loadstores again because the last implementation was pretty crap when it comes to performance, even if they were the
cleanest implementation from my point of view.
This initially started with me rewriting the fastmem routines to work just like the previous/current implementation of floating loadstores. That was
when I noticed that the performance tanked and decided to rewrite all of it.
This also happens to implement gatherpipe optimizations alongside constant address optimization.
Overall this comment brings a fairly large speedboost when using fastmem.
