This is the same extension that we all know and love but under a different name with some different requirements.
In regular OpenGL fashion, you can't just move a desktop OpenGL extension to OpenGL ES without ratifying a new extension, which is why this falls
under a EXT extension, which in turn causes it to have suffixes attached to their function names.
This is the first step in our way towards conquering all mobile GPUs that don't support desktop OpenGL, hopefully we also can add support for
buffer_storage to OpenGL ES as well so we can make full use of this extension.
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.
This wasn't too much of a concern since we normally don't care about this feature set, but it is nice when testing on new devices and they don't
support the higher feature sets but want to run under software renderer.
The Mesa softpipe and PowerVR 5xx drivers don't support higher GL versions, but they shouldn't exit out just because they couldn't get a GL3 function
pointer that isn't even going to be used at that point.
This was interesting implementing.
Our generic QueryPerformanceCounter function on ARMv7 was so slow that profiling a block was impossible.
I waited about five minutes and I couldn't even get a single frame to output.
This instead uses ARMv7's PMU to get cycle counts, which are a relatively minor performance drop in my testing.
One disadvantage of this method is that the kernel can lock us out of using these co-processor registers, but it seems to work on my Jetson board.
Another disadvantage is that we aren't having block times in "real" time but cycles instead, not too big of a deal.
This also removes instruction run counts from profiling because that's just annoying and we don't expose an interface for even getting those results
from our UI.
This implements a new system for fastmem backpatching on ARMv7 that is less of a mindfsck to deal with.
This also implements stfs under the default loadstore path as well, not sure why it was by itself in the first place.
I'll be moving the rest of the loadstore methods over to this new way in a few days.
These are causing issues in games. In particular you get pink on the screen in Animal Crossing.
Disable until fully investigated.
This also disables fastmem on floating point loadstore instructions which are horribly broken and won't actually backpatch when an invalid read/write
is encountered.
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?
I was mistaken and only changed one line previously which didn't enable them by default.
This changes the default configuration to enable EFB copies and EFB to texture.
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.
I must have had a dirty cmake configuration which didn't encounter this issue.
Make sure we are using LLVM_DEFINITIONS to know where we are linking to libraries at.
Link against libLLVM-${VERSION}, the other one was linking us against static libraries...
We weren't dropping a newline character from the string, we were cutting off the last character of the hardware name.
This fixes my TK1 being called 'lagun' when it's name is 'laguna'
This will work for all of our platforms, x86, ARMv7, and AArch64.
Main issue with this is that LLVM's cmake files aren't correctly finding the LLVM install.
Not sure if this is Ubuntu's issue or not, it may just work on other operating systems.
We could potentially improve this, you can pass in a specific CPU in to the LLVM disassembler. This would probably affect latency times that are
reported by LLVM's disassembly? This needs to be further investigated later.
GCC has optimized this using the exact same code since 4.7 or 4.8.
Android building falls back to the __linux__ route.
No need to keep these around anymore since we aren't building on an old GCC version.
This extends the register cache's BindToRegister function with a doLoad argument just like x86's.
The speedup is minor for these implemented integer instructions.
We weren't setting the backbuffer dimensions on this platform when the window is created.
This required a resize event to first be fired in order to see anything.
So instead do like GLX + X11 platforms do and query the dimensions and set the backbuffer to them.
Should fix issue 7666.
This code was an absolute mess. It had allocated an arbitrarily large string buffer to hold instructions that were disassembled.
Strip out all of the nasty raw C string manipulation and replaces it with ostringstream usage.
Fixes an issue where if you didn't have a JIT recompiler running then Dolphin would instantly crash if you tried comparing PPC to x86 code.
Changed the disassembly of the host side code from being inline to the function to instead being in a class, this will be required when I add support
for ARMv7 and AArch64 to this window.
This also fixes an issue where it would show the ARMv7 JIT recompiler on AArch64, also the issue of showing the now non-existant ARM JITIL.
Also fixes an issue where it would show the x86 JIT recompilers on a non ARM platform.
This was a subtle bug I introduced since I removed a LDR in one of the ComputeCarry functions.
Basically since I wasn't loading the XER value prior to operations when I did a BIC tmp, tmp, 1 it would clear the first bit in our temp register but
retain the rest of the "random" data from that temp register. This would then save in to xer_ca, which the Interpreter will use later without any
masking to generate the XER value. Our XER generation helper functions don't do any masking since they were only expecting a single bit worth of data
in xer_ca with the rest being zero.
So now we only have one bit of data being stored in xer_ca from the ARMv7 JIT recompiler, and also a slight optimization in the ComputeCarry function
that is used on the immediate path. There wasn't any reason to load xer_ca since it only contains one bit of data now.
Ryan Houdek