Created attachment 50154 [details]
Screenshot of the failure
If you pull from my e350bug branch ( http://cgit.freedesktop.org/~cand/mesa/log/?h=e350bug ) and execute "pp_jimenezmlaa=8 glxgears", you should see a fully white window. What actually happens on the E-350 is attached.
The gist is "a long shader; output = white;", which should always create white, since the shader has no kilp/discard. While this would rarely happen in practise (the glsl compiler would eliminate dead code), this is a clear bug, and I believe this is causing me other grief.
While the branch is based on ~4 weeks old master, the bug is present when merged with today's master.
The kernel I'm on is 3.0.1.
This test succeeds on both softpipe and llvmpipe.
I have isolated this to the loops. Commenting out all BGNLOOP, ENDLOOP, and BRK instructions lets the card produce white.
Tracking further, the bug only shows when there's more than one break inside a loop.
Scratch that, it appears with only one break too (depends on which break you comment out :P)
Created attachment 50268 [details] [review]
The attached patch fixes this bug. It also lets MLAA work, showing that there are no other showstoppers for it on r600g / e-350.
Note I'm not at all sure this is the right approach, but hey, it works.
This bug doesn't seem to affect r700 - at least my HD4350 works perfectly with all effects on current master (7.12-devel (git-f800a29))
Please send the patch to the mesa-dev mailing list for review, preferably with git send-email or at least generated by git format-patch.
I can't; the same function is used for everything from r600 on - I have no idea whether it would break other hw. As mentioned in the comment above, the bug is not there on a r700 dedicated card on master, which casts further doubt on the patch.
It may simply be an issue in Evergreen loop handling elsewhere, but I really do not understand the hw well enough to say that with any certainty.
Is this still an issue with latest git? This commit looks relevant:
I can test on the weekend.
Yes, that commit fixes it. Doubly sure, since I had to apply it on top of master from Dec 19 (the last version that builds without xcb).