Fixes missing objects on Adreno hardware.

[Sonicadvance1]

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 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.

[ds84182]

That reminds me, what about that issue I had with my Ardreno drivers on my
Moto X not being able to bit shift a vec3?
On Oct 28, 2014 11:21 PM, "Ryan Houdek" notifications@github.com wrote:

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 v99 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 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 to when I tell them about the bug.
It will be tracked in our video driver failure spreadsheet along with the

others.

You can merge this Pull Request by running

git pull https://github.com/Sonicadvance1/dolphin fix-qualcomm

Or view, comment on, or merge it at:

#1434
Commit Summary

• Fixes missing objects on Adreno hardware.

File Changes

• M Source/Core/VideoCommon/PixelShaderGen.cpp
  https://github.com/dolphin-emu/dolphin/pull/1434/files#diff-0 (7)

Patch Links:

• https://github.com/dolphin-emu/dolphin/pull/1434.patch
• https://github.com/dolphin-emu/dolphin/pull/1434.diff

—
Reply to this email directly or view it on GitHub
#1434.

[degasus]

really? Are they as bad?

[ds84182]

" ERROR: 0:91: '<<' : wrong operand types no operation '<<' exists that
takes a left-hand operand of type '3-component vector of int' and a right
operand of type 'const int' (or there is no acceptable conversion)"

This could be fixed by having some fallback bitshift each component
individually, wouldn't that output the same code?
On Oct 29, 2014 8:09 AM, "Markus Wick" notifications@github.com wrote:

really? Are they as bad?

—
Reply to this email directly or view it on GitHub
#1434 (comment).

[Sonicadvance1]

The main problem with working around that particular issue is that Qualcomm has the bug fixed in later driver versions and the line that does these vector shifts is quite dense with a couple of shifts on each one.
Qualcomm has another bug involving these lines that I'm currently investigating, so in my working copy I have the lines expanded out to single operations per line. Depending on what I find, I may need to expand these operations anyway. We'll see what happens.