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.