This is time based block profiling unlike the ARMv7 core.
I would like to add cycle counter based block profiling like the ARMv7 core, but it first requires writing a kernel module to enable the counters to userland applications
Using BindToRegister from the register caches causes the register bound to be marked dirty.
Using the regular R() function from the register caches loads the registers without being dirty.
When implementing new instructions make sure to BindToRegister registers that become dirty.
With my previous changes Dolphin would fail to create the user directory if it didn't exist, and would dump all the configuration options in to the cwdir.
This was a bit more complicated to fix in a clean fashion, so I took to moving around code concerning user directories.
Instead of having GetUserPath serve a dual purpose of both getting and setting our user directories, break out to a new SetUserPath function.
GetUserPath will know only get the configured user path.
SetUserPath will set our user paths and setup the internal user path state.
This ending up being a lot cleaner overall, which is nice. Also less mind bending when attempting to read the code.
So now we won't dump all of our configuration in to the cwdir if ~/.dolphin-emu isn't found.
Fixes issue 8371.
This came up from the discussion we were having prior about dumping half of a kilobyte of VFP registers to the stack is insanity.
This was due to me basically copying exactly what I did on ARMv7's paired loadstores, where the impact is less since we only use the bottom 64bits of
the VFP registers.
So I decided to think about how to improve upon this since I got called out on my terrible code.
The solution I have come up with is instead of jumping to the common ASM routine and having that check if it needs to take the fastmem or slowmem
routes, just inline the check in to the JIT block and jump to either a fastmem or slowmem handler.
Fairly simple, and this allows us to only flush the registers that are required when doing so. Should give a reasonable increase in performance for
games that use the slowmem path quite a lot.
We are declaring we require ARB_shader_image_load_store in the shader, this isn't an extension on GLES because it is part of the GLSL ES 3.1 spec.
If we are running as GLES then just not put it in the shaders.
Activity Monitor can start activities by using adb to invoke it.
This will allow us to set the user directory and autostart file from adb.
adb shell am start -n org.dolphinemu.dolphinemu/.gamelist.GameListActivity -e AutoStartFile /sdcard/AC.gcz -e UserDir /sdcard/dolphin-emu2/
This allows more automated testing to be done with Dolphin on Android.
A bit more efficient if we are only pushing two VFP registers.
We can probably be a bit more efficient in the future by mixing paired loadstores in to the other paths as well.
Previously on FPR pushing and popping we would do a single STR/LDR per quad FPR we wanted to push/pop.
In most of our cases when we are pushing and popping VFP registers they will be consecutive registers that will save more efficiently using the NEON
loadstores that can do up to four quad registers.
So this can potentially cutting instructions down to ~1/4th the amount of instructions if the registers are all consecutive.
On the Cortex-A57 this is basically just an icache improvement, but on the Nvidia Denver this may be optimized to be more efficient. Either way it's a
win.
The Load directory wasn't being properly reassigned when the user path changed, which causes a bunch of issues with things loading from the wrong
place when using the -U option in Dolphin.
The UI should decide on where it wants the user directory, not our core system.
This is in anticipation of some upcoming work on Android which will need proper user directory setting.
We were eating /all/ button events except the back button. This would cause issues where Android wouldn't receive button press events for things like
volume rockers. So you couldn't change the audio ingame, even if that button isn't bound to an input.
Now we return to Android if we've handled that button press, so it works fine.
When the core is busy shutting down only uninstall the exception handler if fastmem is actually enabled.
We only install when fastmem is enabled, so only uninstall when it is as well.
Fixes a crash I was getting on ARMv7.
This was a fairly recent update that went unnoticed because it uses a cached variable.
When I previously updated Android cmake I didn't noticed this.
Basically the issue was that Android cmake was no longer setting ${LIBRARY_OUTPUT_PATH_ROOT}
and instead only setting it to ${CMAKE_SOURCE_DIR} if it was passed a variable.
Same PR is open on the android cmake repo here https://github.com/taka-no-me/android-cmake/pull/37
When the fastmem loadstore would fail, we would disassemble a few instructions to determine if lhbrx or lhz*
This was failing since I was checking the REV16 instruction that appears after the LDRH. Fixed it to make sure it was checking the correct instruction
which is SXTH.
Fixes an issue where homebrew wouldn't load with fastmem enabled.
GLES3 spec is worthless and only returns a boolean result for occlusion queries. This is fine for simple cellular games but we need more than a
boolean result.
Thankfully Nvidia exposes GL_NV_occlusion_queries under a OpenGL ES extension, which allows us to get full samples rendered.
The only device this change affects is the Nexus 9, since it is an Nvidia K1 crippled to only support OpenGL ES.
No other OpenGL ES device that I know of supports this extension.
In nearly all direct loadstore cases we can use unscaled loadstores.
Still have a fallback in case we hit a situation that we /can't/ do a unscaled loadstore.
If we are compiling in the CRC32 hash, clang has an issue with casting a s32 to a u64.
Change our lens argument to a unsigned integer to fix the issue.
With the float instructions that only affect the lower 64bits of the destination register, we need to make sure to load the full 128bit register.
This ensures that we aren't saving garbage in to the top 64bits.
JitCommon is becoming a cluster of x86 specific things and things that are common to multiple recompilers.
This overlap is beginning to cause us issues.
Begin by breaking out the common ASM arrays to have their own file and move the x86 specific routines to their own folder.
Ryan Houdek