Launchpad has imported 50 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=61628.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-02-28T19:24:03+00:00 Coacher wrote: Created attachment 75706 lspci -vvv Hello. Since I've upgraded from 2.20.18 version of intel driver page previews in Firefox are rendered improperly (see attached screenshot). Tested versions of intel driver are 2.20.{18,19} and 2.21.{0,2,3}, Firefox's versions are 17.0-19.0. I don't think it is a Firefox issues it is completely gone when downgrading back to 2.20.18. My system is Gentoo amd64, currently with latest Firefox and intel driver. My current kernel version is 3.8 and it is vanilla. I am using SNA acceleration. If there is any additional info that would be helpful I am ready to provide it. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/0 ------------------------------------------------------------------------ On 2013-02-28T19:24:42+00:00 Coacher wrote: Created attachment 75707 glxinfo -l -t Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/1 ------------------------------------------------------------------------ On 2013-02-28T19:27:11+00:00 Coacher wrote: Created attachment 75708 Screenshot with example of corrupted rendering Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/2 ------------------------------------------------------------------------ On 2013-03-03T19:22:06+00:00 Chris Wilson wrote: I still haven't been able to reproduce this one yet. Do you have a foolproof (and remember just how big a fool I am!) recipe? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/3 ------------------------------------------------------------------------ On 2013-03-03T20:18:29+00:00 Coacher wrote: This issue happens occasionally, but I don't have a 100% reproducible way to show it. One of the most sucessfull attempts to reproduce it is: 1. make all `speed dial` buttons (previews on about:newtab) in Firefox filled with something reasonably heavy, not plain-text pages (on my machine it is a couple of youtube pages, web interface to SAGE, couple of redmines, etc.) 2. close all tabs except one and this last one tab should be about:newtab page 3. middle-click all the previews as fast as you can one by one, so the pages begin to load in background 3. now hit Ctrl+W till you close everything including that about:newtab page where you've started. You shouldn't wait until all pages you've opened on step 3 are loaded. 4. now open about:newtab again and with a good chance some of the preview will be corrupted. Sometimes there is no corruption, but some preview is displayed on the wrong position, for example two different sites share the same preview image. Another way to reproduce: 1. make at least one `speed dial` button (preview on about:newtab) in Firefox filled with any kind of preview, just any site you want 2. close all tabs except one and this last one tab should be about:newtab page 3. go to http://www.dreamworksanimation.com/ and add it to bookmarks, then close tab (sorry, bookmarking is the only way I know to make a specific site to show up in previews) 4. open about:newtab again and remove any preview image from it by pressing [X] 5. open bookmarks and drag dreamworksanimation bookmark you've made on step 3 into the freed on step 4 place 6. now visit http://www.dreamworksanimation.com/ so Firefox will generate preview 7. close tab and open again about:newtab. The preview for dreamworksanimation should be corupted Sorry if the descriptions are a bit messy. Also I don't have any other issues with firefox sites rendering, just issues with rendering previews. I wish there was an easier way to reproduce it. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/4 ------------------------------------------------------------------------ On 2013-03-03T21:22:19+00:00 Coacher wrote: I did git bisecting between 2.20.18 and 2.20.19 and the result is this commit: dc643ef753bcfb69685f1eb10828d0c8f830c30e is the first bad commit commit dc643ef753bcfb69685f1eb10828d0c8f830c30e Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Thu Jan 17 12:27:55 2013 +0000 sna: Apply read-only synchronization hints for move-to-cpu Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> :040000 040000 0f53950ba9a9756a39722f12c322c2d629c1a2a4 d5ff0a7307cc718ee94c78ee2fb1c9bf6158ed91 M src As this bug is not 100% reproducible it could slipped out of my sight during some bisect runs, however it is something to start with. What do you think? Could this sommit lead to the rendering problems I have? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/5 ------------------------------------------------------------------------ On 2013-03-03T21:34:14+00:00 Chris Wilson wrote: There was a related bug, fixed with commit 19bd005056a2083de64753681b96716996e4237d Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Fri Feb 22 12:05:04 2013 +0000 sna: Avoid migrating and making the GPU bo busy prior to mmapping it References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1131134 Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> that I thought was already in 2.21.3 and so you had tested it. It is actually in master, so can you try compiling from git and checking if that fixes the issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/6 ------------------------------------------------------------------------ On 2013-03-03T21:36:08+00:00 Chris Wilson wrote: I'll admit to not fully explaining how that prevented the corruption, as the damage should had been migrated and then the kernel should have stalled upon the read... But it did have an effect and prevented a similar issue that bisected to the same commit. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/7 ------------------------------------------------------------------------ On 2013-03-03T22:54:47+00:00 Coacher wrote: (In reply to comment #6) > It is > actually in master, so can you try compiling from git and checking if that > fixes the issue? I've just tested master and the issue is still there. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/8 ------------------------------------------------------------------------ On 2013-03-03T22:59:40+00:00 Coacher wrote: Created attachment 75871 xf86-video-intel-2.21.3-revert-dc643ef753bcfb69685f1eb10828d0c8f830c30e.patch With this patch applied on top of xf86-video-intel-2.21.3 the problem is gone (at least I tried hard to reproduce it, but failed). This patch is simply reverting dc643ef753bcfb69685f1eb10828d0c8f830c30e commit mentioned above. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/9 ------------------------------------------------------------------------ On 2013-03-04T09:47:53+00:00 Chris Wilson wrote: Can you try converting each of those kgem_bo_sync__cpu_full() back to kgem_bo_sync__cpu() individually and see if we can narrow it down to one particular path? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/10 ------------------------------------------------------------------------ On 2013-03-04T11:13:26+00:00 Chris Wilson wrote: Created attachment 75892 Force CPU synchronisation after writes Another test to try. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/11 ------------------------------------------------------------------------ On 2013-03-04T21:42:45+00:00 Coacher wrote: (In reply to comment #11) > Created attachment 75892 [details] [review] > Force CPU synchronisation after writes > > Another test to try. With this patch applied on top of 2.21.3 the problem seems to be fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/21 ------------------------------------------------------------------------ On 2013-03-04T22:03:28+00:00 Coacher wrote: Created attachment 75920 kgem_bo_sync__cpu_full-revert-bad.patch (In reply to comment #10) > Can you try converting each of those kgem_bo_sync__cpu_full() back to > kgem_bo_sync__cpu() individually and see if we can narrow it down to one > particular path? With this patch on top of 2.21.3 I've hit the bug almost immediately. In this case I've left first kgem_bo_sync__cpu_full() as is and converted only second one. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/22 ------------------------------------------------------------------------ On 2013-03-04T22:06:42+00:00 Coacher wrote: Created attachment 75921 kgem_bo_sync__cpu_full-revert-good.patch (In reply to comment #10) > Can you try converting each of those kgem_bo_sync__cpu_full() back to > kgem_bo_sync__cpu() individually and see if we can narrow it down to one > particular path? With this patch on top of 2.21.3 I was unable to reproduce the bug anymore. In this case I've converted first kgem_bo_sync__cpu_full() and left second one as is. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/23 ------------------------------------------------------------------------ On 2013-03-05T11:17:45+00:00 Chris Wilson wrote: I've looked through all callers to see if I can find one that missed the MOVE_WRITE to no avail. I've double checked the kernel to see if there is a loop hole, again to no avail. So I'm a little bit lost to see where the missed synchronisation is coming from, and I haven't yet thought of a good test to force/catch an error. In the meantime, I've applied one minor tweak to xf86-video-intel.git, commit 60ec35b8d25ecfabf1744ea7bc81109d7f2a90e2 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Tue Mar 5 11:14:37 2013 +0000 sna: Be explicit when checking for an idle bo after CPU synchronisation Do you mind giving that a quick test? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/24 ------------------------------------------------------------------------ On 2013-03-05T11:28:30+00:00 Chris Wilson wrote: Also one other test is to try with the drm-intel-next kernel. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/25 ------------------------------------------------------------------------ On 2013-03-06T09:27:29+00:00 Coacher wrote: (In reply to comment #15) > I've looked through all callers to see if I can find one that missed the > MOVE_WRITE to no avail. I've double checked the kernel to see if there is a > loop hole, again to no avail. So I'm a little bit lost to see where the > missed synchronisation is coming from, and I haven't yet thought of a good > test to force/catch an error. > > In the meantime, I've applied one minor tweak to xf86-video-intel.git, > > commit 60ec35b8d25ecfabf1744ea7bc81109d7f2a90e2 > Author: Chris Wilson <ch...@chris-wilson.co.uk> > Date: Tue Mar 5 11:14:37 2013 +0000 > > sna: Be explicit when checking for an idle bo after CPU synchronisation > > Do you mind giving that a quick test? OK, I'll test it later today Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/26 ------------------------------------------------------------------------ On 2013-03-06T09:28:57+00:00 Coacher wrote: (In reply to comment #16) > Also one other test is to try with the drm-intel-next kernel. Could you please give me a quick link to their git repo? Would 3.9-rc1 would be enough? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/27 ------------------------------------------------------------------------ On 2013-03-06T09:30:56+00:00 Chris Wilson wrote: Our upstream is http://cgit.freedesktop.org/~danvet/drm-intel If you are using ubuntu, you can find pre-packaged kernels here http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/28 ------------------------------------------------------------------------ On 2013-03-06T19:04:08+00:00 Chris Wilson wrote: Created attachment 76040 Disable read-read optimisations And one last request, can you please test that this patch as a temporary solution? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/29 ------------------------------------------------------------------------ On 2013-03-06T21:27:45+00:00 Coacher wrote: (In reply to comment #20) > Created attachment 76040 [details] [review] > Disable read-read optimisations > > And one last request, can you please test that this patch as a temporary > solution? This patch also fixes the issue. It was tested on 3.7.10 kernel as well as all previous patches. Now gonna try with drm-intel-next. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/30 ------------------------------------------------------------------------ On 2013-03-06T21:35:19+00:00 Chris Wilson wrote: (In reply to comment #21) > (In reply to comment #20) > > Created attachment 76040 [details] [review] [review] > > Disable read-read optimisations > > > > And one last request, can you please test that this patch as a temporary > > solution? > > This patch also fixes the issue. It was tested on 3.7.10 kernel as well as > all previous patches. Now gonna try with drm-intel-next. Thanks. In the meantime, I'm going to push the temporary workaround - obviously I still hope to find the real bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/31 ------------------------------------------------------------------------ On 2013-03-06T21:56:15+00:00 Coacher wrote: (In reply to comment #16) > Also one other test is to try with the drm-intel-next kernel. Ok, just tried out today's drm-intel-next kernel and was unable to reproduce this bug anymore. This sounds like good news. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/33 ------------------------------------------------------------------------ On 2013-03-06T22:00:55+00:00 Coacher wrote: (In reply to comment #23) > (In reply to comment #16) > > Also one other test is to try with the drm-intel-next kernel. > > Ok, just tried out today's drm-intel-next kernel and was unable to reproduce > this bug anymore. This sounds like good news. Oh, wait, I forgot to rebuild xf86-video-intel without patch. Sorry. Will try vanilla now Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/34 ------------------------------------------------------------------------ On 2013-03-06T22:04:05+00:00 Chris Wilson wrote: /o\ Can you confirm that result with vanilla xf86-video-intel? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/35 ------------------------------------------------------------------------ On 2013-03-06T22:12:26+00:00 Coacher wrote: (In reply to comment #25) > /o\ Can you confirm that result with vanilla xf86-video-intel? Sorry to disappoint you, but the issue is reproducible with vanilla xf86 -video-intel and drm-intel-next. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/36 ------------------------------------------------------------------------ On 2013-03-07T17:46:35+00:00 Coacher wrote: (In reply to comment #22) > Thanks. In the meantime, I'm going to push the temporary workaround - > obviously I still hope to find the real bug. Is there a way I can help? Attach some debug info or test something? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/42 ------------------------------------------------------------------------ On 2013-03-07T20:54:50+00:00 Chris Wilson wrote: (In reply to comment #27) > (In reply to comment #22) > > Thanks. In the meantime, I'm going to push the temporary workaround - > > obviously I still hope to find the real bug. > > Is there a way I can help? Attach some debug info or test something? If you change the define in src/sna/sna_accel.c: diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index ae6d3c1..5edad51 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -57,7 +57,7 @@ #define FORCE_INPLACE 0 #define FORCE_FALLBACK 0 #define FORCE_FLUSH 0 -#define FORCE_FULL_SYNC 1 /* https://bugs.freedesktop.org/show_bug.cgi?id=61628 */ +#define FORCE_FULL_SYNC 0 #define DEFAULT_TILING I915_TILING_X that restores the buggy behaviour. If you can keep running with that patch and with --enable-debug to check if any assertions are triggered and see how things progress. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/43 ------------------------------------------------------------------------ On 2013-03-07T22:09:27+00:00 Coacher wrote: (In reply to comment #28) > If you can keep running with that patch > and with --enable-debug to check if any assertions are triggered and see how > things progress. OK, I've did what you've said, powered on and started to watch Xorg.0.log. The first thing I did was to open Firefox and trigger this issue several times - no output. Then I've tried to simulate some typical workflow i.e. opened programs I use on a daily basis and do some things inside them like checking mail, browsing a couple of webpages - still no output. Then I've decided to close them and return to Firefox and again triggered this issue several times and opened a couple of heavy tabs with flash and suddenly caught this: (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x34) [0x5969b4] (EE) 1: /usr/bin/X (mieqEnqueue+0x263) [0x5776c3] (EE) 2: /usr/bin/X (0x400000+0x4fcd4) [0x44fcd4] (EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f236e1d0000+0x6208) [0x7f236e1d6208] (EE) 4: /usr/bin/X (0x400000+0x7a477) [0x47a477] (EE) 5: /usr/bin/X (0x400000+0xa5527) [0x4a5527] (EE) 6: /lib64/libpthread.so.0 (0x3a9c400000+0x10bf0) [0x3a9c410bf0] (EE) 7: /lib64/libc.so.6 (ioctl+0x7) [0x3a9bce3437] (EE) 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3fd3c040d8] (EE) 9: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f236fd9c000+0x1c1a0) [0x7f236fdb81a0] (EE) 10: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f236fd9c000+0x1d9f7) [0x7f236fdb99f7] (EE) 11: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f236fd9c000+0x4fe3a) [0x7f236fdebe3a] (EE) 12: /usr/bin/X (BlockHandler+0x44) [0x43f224] (EE) 13: /usr/bin/X (WaitForSomething+0x11d) [0x593e7d] (EE) 14: /usr/bin/X (0x400000+0x3ade2) [0x43ade2] (EE) 15: /usr/bin/X (0x400000+0x29b5a) [0x429b5a] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xed) [0x3a9bc2460d] (EE) 17: /usr/bin/X (0x400000+0x29eb1) [0x429eb1] (EE) (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. [ 8739.251] [mi] Increasing EQ size to 512 to prevent dropped events. [ 8739.251] [mi] EQ processing has resumed after 64 dropped events. [ 8739.251] [mi] This may be caused my a misbehaving driver monopolizing the server's resources. After that I've tried to reproduce this trace again opening same tabs and triggering issue again and again, but without any luck. Is this stack trace useful in any way? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/44 ------------------------------------------------------------------------ On 2013-03-07T22:34:37+00:00 Chris Wilson wrote: Hmm, I expect dmesg to contain a GPU hang and /sys/kernel/debug/0/i915_error_state to be populated, mind attaching it? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/45 ------------------------------------------------------------------------ On 2013-03-08T14:12:15+00:00 Coacher wrote: (In reply to comment #30) > Hmm, I expect dmesg to contain a GPU hang and > /sys/kernel/debug/0/i915_error_state to be populated, mind attaching it? Too bad I turned off my machine later after I've caught that stack trace, so I can't give you the dump of i915_error_state, but I was checking both dmesg and xsession-errors and there was nothing unusual and no signs of error output from i915. I'll try to catch it again and if I do I'll attach dmesg and dump of i915_error_state here. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/46 ------------------------------------------------------------------------ On 2013-03-09T19:42:31+00:00 Chris Wilson wrote: *** Bug 61610 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/51 ------------------------------------------------------------------------ On 2013-03-12T16:11:02+00:00 Coacher wrote: (In reply to comment #28) > If you change the define in src/sna/sna_accel.c: > > diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c > index ae6d3c1..5edad51 100644 > --- a/src/sna/sna_accel.c > +++ b/src/sna/sna_accel.c > @@ -57,7 +57,7 @@ > #define FORCE_INPLACE 0 > #define FORCE_FALLBACK 0 > #define FORCE_FLUSH 0 > -#define FORCE_FULL_SYNC 1 /* > https://bugs.freedesktop.org/show_bug.cgi?id=61628 */ > +#define FORCE_FULL_SYNC 0 > > #define DEFAULT_TILING I915_TILING_X > > that restores the buggy behaviour. If you can keep running with that patch > and with --enable-debug to check if any assertions are triggered and see how > things progress. I've been running this way ever since you've asked me, but that stack trace was the only one I was able to trigger, though improper rendering happened a lot. I am positive that when I caught that trace there were no errors in dmesg. Now, 2.21.4 is out and I will continue trying to catch something, though since it happens only in firefox maybe there is issue somewhere else? What versions of firefox, cairo and gtk do you have? Also I've noticed this message in .xsession-errors whenever I move previews in Firefox: (firefox:3574): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed This happens both with FORCE_FULL_SYNC 0 and 1. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/54 ------------------------------------------------------------------------ On 2013-03-12T17:49:01+00:00 Chris Wilson wrote: I've been primarily using iceweasel (based on ff10) with the system cairo as that is many times faster for gfx. But I've also been using the bloated ff from ubuntu and fedora on different systems (and they use the ancient cairo embedded into firefox). There are a lot of differences in cairo between those versions, so it would not surprise me if it was a bug specific to an older cairo. But I've hoped to have seen it by now as well. :| Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/55 ------------------------------------------------------------------------ On 2013-03-12T19:53:02+00:00 Coacher wrote: I've just tested binary Firefox's versions from their site. I've tried latest versions of 16,17,18 and 19 branches and I was able to trigger the issue in all of them. Will play with cairo versions now, my current cairo is 1.10.2 with some distro patches on top. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/56 ------------------------------------------------------------------------ On 2013-03-12T20:15:40+00:00 Chris Wilson wrote: Just note well that all firefox post version-10 use their builtin version of cairo. In order to use system cairo, firefox needs a patch to remove its reliance upon non-upstreamed API. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/57 ------------------------------------------------------------------------ On 2013-03-12T20:26:54+00:00 Coacher wrote: Tested firefox-19.0.2 with all available versions of cairo from repos: 1.10.2, 1.12.8, 1.12.10, 1.12.12. Issue is reproducible with all versions. (In reply to comment #36) > Just note well that all firefox post version-10 use their builtin version of > cairo. In order to use system cairo, firefox needs a patch to remove its > reliance upon non-upstreamed API. Thanks for info, though I am using Gentoo and use Firefox built from sources on my machine and it is distro-patched to link against system- wide cairo so it's fine. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/58 ------------------------------------------------------------------------ On 2013-03-12T20:35:10+00:00 Chris Wilson wrote: Hmmm, that's news to me. Do you have a link to the patches they apply against firefox? Or a simple test is something like: http://ie.microsoft.com/testdrive/Performance/ParticleAcceleration/ which should be CPU bound in Xorg and not firefox. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/59 ------------------------------------------------------------------------ On 2013-03-12T20:37:25+00:00 Coacher wrote: Also I've noticed that "disable read-read optimisations" patch practically does the same as converting kgem_bo_sync__cpu_full back to kgem_bo_sync__cpu (I may be wrong here though it looks this way to me). I will not question this as you are developer and know best, though as tests shown only one particular branch of kgem_bo_sync__cpu_full triggers this issue, see kgem_bo_sync__cpu_full-revert-bad.patch. Maybe you could add some asserts in that branch, I will apply them and give you some more info? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/60 ------------------------------------------------------------------------ On 2013-03-12T20:41:30+00:00 Coacher wrote: (In reply to comment #38) > Hmmm, that's news to me. Do you have a link to the patches they apply > against firefox? http://mirror.yandex.ru/gentoo- distfiles/distfiles/firefox-19.0-patches-0.3.tar.xz > Or a simple test is something like: > http://ie.microsoft.com/testdrive/Performance/ParticleAcceleration/ which > should be CPU bound in Xorg and not firefox. Well, I've visited this link and see some spherical thingy made of particles. What should I check? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/61 ------------------------------------------------------------------------ On 2013-03-12T20:52:15+00:00 Chris Wilson wrote: (In reply to comment #40) > Well, I've visited this link and see some spherical thingy made of > particles. What should I check? Just look at top; For this particular benchmark, it should be ratelimited by the Xorg process not firefox - or better look at sudo perf top, if firefox is hitting pixman functions, it is a bad firefox. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/62 ------------------------------------------------------------------------ On 2013-03-12T20:54:37+00:00 Chris Wilson wrote: Seems like gentoo has the right patch though, it should be fine. Now if only the other distros also used that patch :( Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/63 ------------------------------------------------------------------------ On 2013-03-12T20:58:40+00:00 Coacher wrote: (In reply to comment #42) > Seems like gentoo has the right patch though, it should be fine. Now if only > the other distros also used that patch :( So, should I check top or not? Because I am a bit confused what exactly means "ratelimited by the Xorg process not firefox". I am building perf right now though. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/64 ------------------------------------------------------------------------ On 2013-03-12T21:07:06+00:00 Coacher wrote: (In reply to comment #41) > (In reply to comment #40) > > Well, I've visited this link and see some spherical thingy made of > > particles. What should I check? > > Just look at top; For this particular benchmark, it should be ratelimited by > the Xorg process not firefox - or better look at sudo perf top, if firefox > is hitting pixman functions, it is a bad firefox. When running this demo in firefox `# perf top` says "42% libpixman-1.so.0.29.2" and this line sits on top of the list. Does that mean bad firefox? :( Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/65 ------------------------------------------------------------------------ On 2013-03-12T21:17:21+00:00 Chris Wilson wrote: Only if that pixman time is inside firefox and not Xorg... Have gentoo also disabled server-side gradients in cairo? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/66 ------------------------------------------------------------------------ On 2013-03-12T21:24:29+00:00 Coacher wrote: (In reply to comment #45) > Only if that pixman time is inside firefox and not Xorg... I am not familiar with this tool. How do I check this? > Have gentoo also > disabled server-side gradients in cairo? Yes, part of changelog: 10 Sep 2010; Samuli Suominen <ssuomi...@gentoo.org> +cairo-1.10.0-r2.ebuild, +files/cairo-1.10.0-buggy_gradients.patch: Do not use server-side gradients. It hurts performance, and causes bad rendering on at least nvidia. Bug 336696. And this patch is still applied on top of cairo version I am running now. Though maintainers added option to disable it in the latest version in tree. It enabled by default though, so I tested this version also with disabled gradients. Should I check without it? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/67 ------------------------------------------------------------------------ On 2013-03-12T21:30:05+00:00 Coacher wrote: http://sources.gentoo.org/cgi- bin/viewvc.cgi/gentoo-x86/x11-libs/cairo/files/cairo-1.10.0-buggy_gradients.patch?revision=1.4&view=markup Link to the mentioned gradients patch Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/68 ------------------------------------------------------------------------ On 2013-03-12T21:34:32+00:00 Chris Wilson wrote: Yeah, that gradient patch dramatically hurts performance on Nvidia and Intel systems, whilst having little impact on EXA systems. Kill that patch with fire. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/69 ------------------------------------------------------------------------ On 2013-03-12T21:37:09+00:00 Coacher wrote: (In reply to comment #48) > Yeah, that gradient patch dramatically hurts performance on Nvidia and Intel > systems, whilst having little impact on EXA systems. Kill that patch with > fire. Tested without this patch, but the issue is still presented. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1144558/comments/70 ** Changed in: xserver-xorg-video-intel Status: Unknown => Confirmed ** Changed in: xserver-xorg-video-intel Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1144558 Title: Images corruption in firefox when using "sna" To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1144558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
