Bug 17671

Summary: OpenGL+EXA causes screen corruption
Product: xorg Reporter: Matthew Turnbull <sparkybluefang>
Component: Driver/radeonhdAssignee: Luc Verhaegen <lverhaegen>
Status: RESOLVED WORKSFORME QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: cedricv, marvin24
Version: unspecified   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Description Flags
Screen corruption while using compiz none

Description Matthew Turnbull 2008-09-19 20:00:23 UTC
Created attachment 19028 [details]
Screen corruption while using compiz

First, I apologize if there already is a bug for this. I looked, but I didn't see anything that caught my eye.

I recently switched to using EXA (XVideo doesn't work under XAA, but that's another issue) and I discovered that OpenGL applications (glxgears, compiz-fusion, stepmania, etc) cause screen corruption. Exiting the OpenGL app and switching away then back to the X VT corrects the corruption.

This doesn't happen under XAA, and I tried using "UnverifiedFeatures" (from reading another topic) but that didn't help.

I'm using git sources, XOrg 7.4/1.5, Mesa 7.2 rc1, 2.6.26 kernel with gentoo patches
Comment 1 Marc Dietrich 2008-09-20 06:43:58 UTC
I'm seeing this on RS690 using openSUSE 11.0/Xserver 1.5/mesa,drm,radeonhd from git. What's your hardware?
Comment 2 Alex Deucher 2008-09-20 09:05:36 UTC
try the following options and see if any of them help:
Option "EXANoComposite" "TRUE"
Option "EXANoUploadToScreen" "TRUE"
Option "EXANoDownloadFromScreen" "TRUE"
Comment 3 Matthew Turnbull 2008-09-20 17:02:33 UTC
I have a T60 with an ATI Radeon Mobility x1400

I tried those options, and different combination of them, with mixed results.

When using Metacity compositing (and glxgears), EXANoUploadToScreen seems to help. I don't seem to get the font corruption any more, however I'm still frequently getting the colored horizontal lines (though not as often). EXANoComposite only seemed to slow it down.

When using Compiz-Fusion, EXANoUploadToScreen and EXANoComposite seem to be the best. Again, I'm not seeing the font corruption, but I'm still getting the horizontal lines.

With Compix-Fusion, using only EXANoUploadToScreen still gave me font corruption.

EXANoDownloadFromScreen does nothing but give me unusable frame rates.

Also, this might not be related, but in GNOME, I have a script that changes my background every 5 minutes. In playing with those options and switching between Metacity and Compiz (between xserver restarts), by background seemed to be changing more sporadically and sometimes a bg change would cause the corruption and sometime it would correct it. But it didn't do so in and pattern I could discern.
Comment 4 Marc Dietrich 2008-09-21 23:36:43 UTC
I don't use composite at all (Option "Composite" "False" in section Extentions). Option "EXANoDownloadFromScreen" cures the glyph rendering here, but the horizontal bars stay. Sometimes the screen flickers. I guess this is related to the chip used (isn't X1400/M54 of the same generation than X1250/RS690?). Btw. this happens since the dri merge some month ago, but I was just to lazy to report :-(

Comment 5 Egbert Eich 2008-10-14 02:11:26 UTC
Matthew, could you please test the latest GIT code? There were some changes to the accel infrastructure which could have an influence on what you are experiencing.
Comment 6 Marc Dietrich 2008-10-14 06:09:30 UTC
I tested v1.2.3 on openSUSE 11.0/Xorg 1.4/Mesa 7.2. Hard to reproduce now, since system crashes when
	- moving the mouse while glxgears is running
	- switching to text console and back from login screen
Comment 7 Marc Dietrich 2008-10-14 06:18:38 UTC
I also tested version 1.2.2 - no crashes here, but corruption still exists.
Comment 8 Matthew Turnbull 2008-10-14 09:21:11 UTC
With git master, the corruption appears to be gone.

However, at some point between now and my previous post, I started experiencing the same problems that Marc described (system freezing when using OpenGL or switching VTs). I'm not precisely sure when this cropped up or if it was caused by an xserver/mesa/drm update or if it was a radeonhd problem.

I fixed it by adding [Option "EXANoComposite" "True"] to my xorf.conf device section.

But I should note that with the latest git, my [Option "EXANoComposite" "True"] solution now causes rendering corruption with scroll bars, but that is much more acceptable than OpenGL corruption.
Comment 9 Marc Dietrich 2008-12-15 02:36:28 UTC
I gave v1.2.4+ a try today. No more screen corruptions visible with EXA, even without "EXANo*" options. Also no crashes using glxgears.
Only drawhack is, that glxgears fps is 320 with EXA and 650 with XAA.

Can you confirm this, Matthew?
Comment 10 Matthew Turnbull 2008-12-15 09:31:12 UTC
I just updated from git master. I am still seeing desktop rendering errors when using EXA+EXANoComposite. Problems include things like scroll bar corruption and discoloration, and sporadic text discoloration (some times rendered with out color).

I'm also still getting lockups when usig EXA+Composit+OpenGL. And as noted in bug 18097, I'm still getting a bunch of warnings in my xorg log:

Comment 11 Raúl 2010-04-22 09:14:04 UTC

Your last comment was some time ago, maybe situation is much better now, hopefully this is even solved. Could you feedback with a recent graphics stack?

Comment 12 Jeremy Huddleston Sequoia 2011-10-16 16:01:21 UTC
Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Comment 13 Matthew Turnbull 2011-10-16 16:39:33 UTC
I haven't noticed any issues with xf86-vide-ati + KMS.

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.