Bug 78922 - [ivb gt1] Display corruption
Summary: [ivb gt1] Display corruption
Status: NEEDINFO
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-19 19:19 UTC by Andrew Marshall
Modified: 2014-12-21 15:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Screenshot showing display corruption (902.05 KB, image/png)
2014-05-19 19:19 UTC, Andrew Marshall
no flags Details
dmesg output (58.09 KB, text/plain)
2014-05-19 19:20 UTC, Andrew Marshall
no flags Details
glxinfo output (35.80 KB, text/plain)
2014-05-19 19:22 UTC, Andrew Marshall
no flags Details
xorg log (29.26 KB, text/plain)
2014-05-19 19:23 UTC, Andrew Marshall
no flags Details
glxgears rendering artifacts (985.88 KB, image/png)
2014-05-19 20:45 UTC, Andrew Marshall
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Marshall 2014-05-19 19:19:25 UTC
Created attachment 99351 [details]
Screenshot showing display corruption

Fresh install of Ubuntu 14.04 has display corruption (see attachment). Tried distribution-provided drivers and those provided by intel installer v 1.0.5.

Windows 7 installation on same system exhibits no problems.

Reversion to software rasterization exhibits no problems, but not a satisfactory workaround.

Driver version 2.99.910
Comment 1 Andrew Marshall 2014-05-19 19:20:45 UTC
Created attachment 99352 [details]
dmesg output
Comment 2 Andrew Marshall 2014-05-19 19:22:35 UTC
Created attachment 99353 [details]
glxinfo output

LIBGL_DEBUG=verbose glxinfo outputs the following : 

libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:0152, driver i965
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
libGL: Can't open configuration file /home/andrew/.drirc: No such file or directory.
libGL: Can't open configuration file /home/andrew/.drirc: No such file or directory.
libGL: Can't open configuration file /home/andrew/.drirc: No such file or directory.
Comment 3 Andrew Marshall 2014-05-19 19:23:10 UTC
Created attachment 99354 [details]
xorg log
Comment 4 Chris Wilson 2014-05-19 19:42:49 UTC
First please update mesa to eliminate one known IVB display corruption bug.
Comment 5 Andrew Marshall 2014-05-19 20:44:23 UTC
Mesa updated to 10.3.0-devel from oibaf's PPA. No change. glxgears shows severe rendering artefacts. (see attachment)
Comment 6 Andrew Marshall 2014-05-19 20:45:39 UTC
Created attachment 99357 [details]
glxgears rendering artifacts
Comment 7 Chris Wilson 2014-05-19 20:53:59 UTC
How about going the other way, and looking for a version of packages that used to work? Then find which package seems to cause the regression. The choice is kernel / ddx / mesa. So far we know that mesa has a few issues, but they may be unrelated.
Comment 8 Andrew Marshall 2014-05-20 09:56:27 UTC
Added the following to xorg.conf

Option "AccelMethod" "uxa"

This has removed the speckling artifacts. I am still having issues with glxgears not rendering correctly, but this is definitely an improvement.
Comment 9 Chris Wilson 2014-05-20 10:03:04 UTC
Sadly, that still doesn't rule out a root cause in mesa.
Comment 10 Andrew Marshall 2014-05-20 20:15:15 UTC
I've tried the latest Mesa Release Candidate (10.2 rc3) and 9.2.5 - no change. As I said, changing the acceleration mode fixes the speckling artifacts but OpenGL applications have severe vertical tearing artifacts when rendering in hardware.

Unsure where to go from here - I haven't seen anyone else report the problem so is this likely a hardware issue? Windows drivers exhibit no problems but I'm not sure if that means anything.

Cheers,
Andrew.
Comment 11 Chris Wilson 2014-05-20 20:21:29 UTC
The speckle looks to be a blend failure. It looks to be in the compositor as the pattern seems to have some of the overdrawn content, which is why I suspect that mesa is involved. At first I thought the speckle would be a cache invalidate issue, but it doesn't actually seem to be wide enough for a cacheline issue - so it may be a bad EU, sampler or killpixel instruction.

When you tried 9.2.6, what changed? Presumably the glxgears returned to normal?
Comment 12 Andrew Marshall 2014-05-21 21:50:13 UTC
9.2.5 still rendered with artifacts. I tried with 9.0.3 and it renders fine. Would it be helpful if I find the exact version where it breaks?

Cheers,
Andrew.
Comment 13 Andrew Marshall 2014-05-21 22:26:14 UTC
Ok, it definitely broke between 9.0.3 and 9.1, and seen as that's when OpenGL 3 support was introduced I suspect that's probably important.

Let me know if there's anything else I can do.

Cheers,
Andrew.
Comment 14 Chris Wilson 2014-05-22 06:37:07 UTC
I've lost track. Are you referring to the speckle or the glxgears corruption that disappears with 9.0?
Comment 15 Andrew Marshall 2014-05-23 13:52:43 UTC
Ok it looks like the two issues are distinct.

 - Speckling disappears by changing the kernel module's acceleration method to UXA, but is unaffected by any of the Mesa version changes

 - GL rendering artifacts clear up on reverting to Mesa 9.0.3 ( and reappear after 9.1 ) but are unaffected by the kernel module's acceleration method.
Comment 16 Chris Wilson 2014-12-21 15:18:18 UTC
Time to do a new round of testing: kernel for any w/a, ddx and mesa for any fixes.


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.