System Environment: ---------------------- Platform: 945gm Arch: i386 OSD: Fedora release 9 (Sulphur) Libdrm: (master)4a0d19ef4f210cea9e60c5acc355df03723ef808 Mesa: (mesa_7_4_branch)e2092bb23c956ba9ab940935f803ef843db81af2 Xserver: (server-1.6-branch)4557b3f6c4273cd83b701beaf7a150c806fed298 Xf86_video_intel: (master)81c652e9a666a7459bcc5217c8a5ec518b6e00da Kernel: (for-airlied)66647dc60d16fae9f6963fd98b6d9baa1a8dac69 Bug Description: --------------------- In both UXA and EXA mode, it will have a disordered output when rotate the screen using 'xrandr --output LVDS --rotate left'. (See the picture in attachment) Reproduce Steps: --------------------- 1. xinit& 2. xrandr --output LVDS --rotate left (right or inverted)
Created attachment 23202 [details] xorg.conf
Created attachment 23203 [details] xorg.0.log
Created attachment 23204 [details] rotate_on_gm945
I think it was caused by tiling. If I add an option Tiling false disabling it, then it works well.
It also existed on G33 and 915gm with tiling on.
I think the fence register setup for tiling at execbuf time is interfering with rendering due to there being two fence registers set up for the front buffer: one by the UMS 2D driver, and another by the kernel when we execute the Render operation to draw the rotated buffer. If we set the tiling bits in i915_render.c instead of relying on the fences, then the problem goes away.
*** Bug 20434 has been marked as a duplicate of this bug. ***
I find it was caused by the commit 0f973f27888e4664b253ab2cf69c67c2eb80ab1b in the for-airlied branch. The commit's detail is as following: commit 0f973f27888e4664b253ab2cf69c67c2eb80ab1b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jan 26 17:10:45 2009 -0800 drm/i915: add fence register management to execbuf Adds code to set up fence registers at execbuf time on pre-965 chips as necessary. Also fixes up a few bugs in the pre-965 tile register support (get_order != ffs). The number of fences available to the kernel defaults to the hw limit minus 3 (for legacy X front/back/depth), but a new parameter allows userspace to override that as needed.
Ok so the duplicate fence setup should be coming from: - 2D driver sets up a fence reg at allocation time - pin ioctl sets up another fence at pin time the second one will set the fence register number etc in the bo so subsequent execbufs shouldn't allocate one; Eric how did you remove the duplicate setup? If I'm correct then the attached patch should work, can you give it a try?
Created attachment 23815 [details] [review] don't set up fence registers if the kernel can do it This patch avoids setting up fence registers at allocation time if execbuf fencing is active, since the pin ioctl should take care of that for us.
Jian, can you give the patch a try?
jbarnes, how does this ensure that the fence stays permanently on the scanned out buffer? it'll just get stolen by other clients execing, right?
It shouldn't, since the scanout buffer is pinned. The fence stealing code shouldn't try to steal those regs & reuse them in that case, but maybe I need to look at the code again.
(In reply to comment #11) > Jian, can you give the patch a try? Hi, Jesse. I tried with your patch and it worked well now, it will display normally when rotate both with UXA and EXA. But I have to mention that after rotate then log into the gnome, it will have a blurred desktop. As #20287.
Fix pushed. Still trying to reproduce #20287. commit 636d252f3b1eac687f7b11952e949c383cb86ed4 Author: Jesse Barnes <jbarnes@nietzche.localdomain> Date: Thu Mar 19 13:25:29 2009 -0700 Don't install fences if the kernel is managing them
It is OK now.
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.