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 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.
Fixes all the current issues I've been experiencing.
Scaled back the register cache idea for now so I can actually work on some real instructions.
Tested this work with unit tests so I know it works.
Unit tests are pretty great things.
Ryan Houdek