|Summary:||Current git: Xorg display corruption with radeon driver (bisected)|
|Product:||cairo||Reporter:||Andre Tomt <andre>|
|Component:||general||Assignee:||Carl Worth <cworth>|
|Status:||RESOLVED MOVED||QA Contact:||cairo-bugs mailing list <cairo-bugs>|
|Priority:||medium||CC:||a.e.nvdv, auxsvr, bugz, duckx, grawity, hramrach, michel, ppawel, slomo|
|i915 platform:||i915 features:|
display corruption with cairo-1.12 and gnome-terminal-3.4.0
Description Andre Tomt 2011-12-12 14:05:34 UTC
Created attachment 54380 [details] screenshot With cairo from git master display frequently corrupts, especially text labels, when used with the xorg radeon driver. This seems to be related to EXA acceleration, as setting NoAccel in xorg.conf or using intel HD graphics (which is not using EXA) makes things nice again. I am not sure if this is an xorg, driver or cairo bug however. All I know is that a commit in cairo made it a problem (see bisected commit below). Steps to reproduce on Ubuntu 11.10: A graphics card using a XAA using driver seems to be needed. I've seen corruption on Radeon HD4780, HD5450, HD5770 and HD6670. Xorg can be 1.10 or 1.11-git, doesn't seem to matter. Install cairo from git. It is also in xorg-edgers ppa (package repository) for the lazy: add xorg-edgers ppa: apt-add-repository ppa:xorg-edgers/ppa apt-get update && apt-get dist-upgrade (note that this also pulls in mesa and xorg bits) Chromium seems to be able to trigger this easily, so its a good app to test with. install chromium: apt-get install chromium-browser Make bookmark toolbar visible, create a couple bookmarks in it. Now hover mouse a few times over the bookmark in the bar, it corrupts usually within a couple hovers. A redraw of the window, by for example giving window focus clears out the corruption until it happens again. Bisecting shows it starts happing with: af9fbd176b145f042408ef5391eef2a51d7531f8 is the first bad commit commit af9fbd176b145f042408ef5391eef2a51d7531f8 Author: Chris Wilson <email@example.com> Date: Sat Jul 30 17:28:21 2011 +0100 Introduce a new compositor architecture Having spent the last dev cycle looking at how we could specialize the compositors for various backends, we once again look for the commonalities in order to reduce the duplication. In part this is motivated by the idea that spans is a good interface for both the existent GL backend and pixman, and so they deserve a dedicated compositor. xcb/xlib target an identical rendering system and so they should be using the same compositor, and it should be possible to run that same compositor locally against pixman to generate reference tests. Signed-off-by: Chris Wilson <firstname.lastname@example.org> P.S. This brings massive upheaval (read breakage) I've tried delaying in order to fix as many things as possible but now this one patch does far, far, far too much. Apologies in advance for breaking your favourite backend, but trust me in that the end result will be much better. :) :040000 040000 ea61003df8e9343e56abc8f835558e8d9b4dc40b e44eec2adcdab9300dbf1c115455f8fe2f71a2d6 M boilerplate :100644 100644 4b85c8a73bfe348ba5a5934d3f695eebd0fa1703 5879a44433f32f081113fd68007ff450e53436a3 M configure.ac :040000 040000 b36ebdf8cda1f399ee57929ef5fbdb7ec450722f bf046500eae8d7e8eb85a5cb4101dbaa5742baf7 M perf :040000 040000 5e6f20302cdb1243d8954c4d7e4142dacb6d5ceb 0b8bb294a3e871203135d1aed98d5d0b965b8f48 M src :040000 040000 c6ee854e8305b60350d90b662be1e6ff9fc7cacd 76dc42cbfe1e31cc25afd78fd402e912ba4c6844 M test :040000 040000 ed7de86ede3d6dd54ac9a5f423090205d929e114 9efaef2d3f3c6266dce708eebdb48f6b1ad83a8e M util
Comment 1 Andre Tomt 2011-12-12 19:16:18 UTC
In addition to downgrading to 1.10.x, setting Option "EXAPixmaps" "false" in the device section of xorg.conf also seems to work around the issue.
Comment 2 Michel Dänzer 2012-03-23 23:20:55 UTC
> Xorg can be 1.10 or 1.11-git, doesn't seem to matter. (In reply to comment #1) > [...] downgrading to 1.10.x, [...] seems to work around the issue. So, it's not reproducible with xserver 1.10.x after all? Have you tried bisecting xserver?
Comment 3 Juan RP 2012-03-27 06:49:00 UTC
Created attachment 59110 [details] display corruption with cairo-1.12 and gnome-terminal-3.4.0
Comment 4 Juan RP 2012-03-27 06:51:16 UTC
Erm the picture attached shows the symptoms that I'm also suffering with latest software components in Linux: - kernel-3.3 - xf86-video-ati-6.14.3 - xorg-server-1.12 - cairo-1.12 The latest git snapshot of xf86-video-ati doesn't change anything, corruption is still reproducable.
Comment 5 Juan RP 2012-03-27 06:54:11 UTC
Forgot to say that the workaround suggested by Andre Tomt of disabling EXAPixmaps in xorg-server seems to work perfectly.
Comment 7 Juan RP 2012-03-27 12:50:15 UTC
As suggested by Michel Dänzer in bug 47266 I tried the suggestion from Alex Deuscher disabling ColorTiling but this doesn't seem to improve anything. The hardware is a Radeon HD 4770 (RV730 iirc). It didn't work with xf86-video-ati-6.14.3 nor with latest git snapshot from master branch. The only known "workaround" is disabling EXAPixmaps.
Comment 8 Paweł Paprota 2012-04-30 12:05:23 UTC
Just to keep the information flowing, in bug 47266 I have done a similar cairo bisection and reached the same commit as a cause of screen corruption - but I am using NVIDIA hardware on my laptop, xf86-video-nouveau from git, xorg 1.12.1.
Comment 9 GitLab Migration User 2018-08-25 13:28:24 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/21.