Bug 40034 - E-350 misprocesses shader
Summary: E-350 misprocesses shader
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-12 01:13 UTC by Lauri Kasanen
Modified: 2012-01-27 02:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the failure (1.05 KB, image/png)
2011-08-12 01:13 UTC, Lauri Kasanen
Details
Proposed patch (418 bytes, patch)
2011-08-16 05:52 UTC, Lauri Kasanen
Details | Splinter Review

Description Lauri Kasanen 2011-08-12 01:13:54 UTC
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.
Comment 1 Lauri Kasanen 2011-08-12 01:14:48 UTC
This test succeeds on both softpipe and llvmpipe.
Comment 2 Lauri Kasanen 2011-08-16 04:21:46 UTC
I have isolated this to the loops. Commenting out all BGNLOOP, ENDLOOP, and BRK instructions lets the card produce white.
Comment 3 Lauri Kasanen 2011-08-16 04:50:15 UTC
Tracking further, the bug only shows when there's more than one break inside a loop.
Comment 4 Lauri Kasanen 2011-08-16 05:04:11 UTC
Scratch that, it appears with only one break too (depends on which break you comment out :P)
Comment 5 Lauri Kasanen 2011-08-16 05:52:55 UTC
Created attachment 50268 [details] [review]
Proposed patch

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.
Comment 6 Lauri Kasanen 2011-11-04 09:27:15 UTC
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))
Comment 7 Michel Dänzer 2011-11-07 09:19:59 UTC
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.
Comment 8 Lauri Kasanen 2011-11-08 05:06:44 UTC
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.
Comment 9 Alex Deucher 2012-01-24 05:58:00 UTC
Is this still an issue with latest git?  This commit looks relevant:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d89c96c75dbb9c003e4643942f2cce8d6cd4995b
Comment 10 Lauri Kasanen 2012-01-24 07:11:39 UTC
I can test on the weekend.
Comment 11 Lauri Kasanen 2012-01-27 02:56:11 UTC
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).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.