Created attachment 71071 [details] Patch that fixes the choppyness. Description =========== In version 2.20.10 and later, I noticed that some graphics operations were not as smooth as they were in 2.20.9. It isn't all that severe, but it was enough to annoy me, and eventually make me track down the source. System environment ================== * chipset: i915 * system arch: 64-bit * xf86-video-intel: 2.20.10 has the issue; above patch fixes it. * xserver: 1.13.0 * mesa: 9.0 * libdrm: 2.4.40 * kernel: 3.5.6 * distribution: Arch linux * Machine: Lenovo X220T * Display connector: HDMI How to reproduce it =================== I use compiz as a stand-alone window manager, and when using the "expo" feature to zoom out and see all desktops, the graphics are noticeably choppy. Other operations (the "scale" plugin, and even sliding to another desktop) are similarly choppy, but the expo feature makes me notice it the most. How to fix(?) it ================ The source is commit 45b351412b. If you revert that commit, things are nice and smooth again. I applied the following patch to the master branch of git (as of 12/6/2012; commit is 0040eb84c9187): --- a/src/sna/kgem.c +++ b/src/sna/kgem.c @@ -1437,7 +1437,7 @@ static void kgem_bo_clear_scanout(struct kgem *kgem, struct kgem_bo *bo) bo->reusable = true; if (kgem->has_llc && - !gem_set_cacheing(kgem->fd, bo->handle, SNOOPED)) + gem_set_cacheing(kgem->fd, bo->handle, SNOOPED)) bo->reusable = false; } And the problem was resolved. I know *nothing* about the driver, and have no idea why this helps, but it does. I used the following configure flags: ./configure --prefix=/usr --enable-dri \ CFLAGS="-march=native -O3 -pipe --param=ssp-buffer-size=4" \ LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" But I note that the same behavior is there with -O2.
Try a more recent kernel. The issue is that you do not have a working set-caching ioctl and you end up polluting the bo cache with uncached buffers, which are comparatively slow and in the worst case cause render corruption. 'sudo perf top' should say that most of your cpu overhead is spent clflushing buffers as they expire, or worse that the clflush occurs just before the pageflip.
Will do. Thanks for the reply. I'll try a kernel from git. The arch linux kernel has been a disaster for my machine for the last month or two: https://bugs.freedesktop.org/show_bug.cgi?id=54089
In principle, there is always going to be jitter due to clflush when we introduce a new scanout. That is unavoidable whether we do the clflush on the CPU or on the GPU. The only thing we can do is to avoid introducing new scanouts too often. At the moment, that is the case. Will be broken by DRI3, ofc.
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.