Im running Ubuntu Gutsy (and several other Distros including Gentoo with the latest Xorg) on a Thinkpad X60T with Intel GMA 950 VideoCard. I rotate the Display a'lot because it is a Tablet-PC. With DRI enabled, the rotated Display is about 50 times slower than with DRI disabled (Option DRI false in Video Device Section). It is still somewhat usable but scrolling any documents, websites etc. is very painfull ( 3-4 updates/second). Im not using compiz or any other composite applications since that would not work at all (display is not updated on a rotated display with composite running). I personally don't have a problem with disabling DRI, but since dri is loaded by default anyone who runs into this issue without knowing how to fix it will believe that linux is just terribly slow.
It might be something got abused in dri block handler...is it possible to do any profile on dri case?
zhenyu, do you have any HOWTO on how to do profiling?
I have exactly the same issue with the same model laptop (Thinkpad X60t). I'm not sure if the video device is exactly the same; my lspci output reads in part 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) One other comment: the slowdown occurs whenever DRI is enabled, independent of whether I use EXA or XAA. This is on Gentoo, using xorg-server-1.4.0.90-59-gddcca23 xf86-video-intel-2.3.1-4-g730259e I'll help debug if I can (but I also don't know how to get a profile, without a little more hand-holding).
oh, so this is 915/945 laptop with default exa right? rotation performance would be affected by current exa accel limit, as rotation depends on render acceleration for rotated screen pixmap. Could you use tools like sysprof to generate profile data? sysprof can produce xml profile data, which can be easily sent and review. Another thing to try is removing flush in block handler, which should only be required on 965, removing that for 915 might be good to try and profile. diff --git a/src/i830_driver.c b/src/i830_driver.c index 604665e..62ce187 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -2526,15 +2526,6 @@ I830BlockHandler(int i, pI830->BlockHandler = pScreen->BlockHandler; pScreen->BlockHandler = I830BlockHandler; - /* Emit a flush of the rendering cache, or on the 965 and beyond - * rendering results may not hit the framebuffer until significantly - * later. In the direct rendering case this is already done just - * after the page flipping updates, so there's no need to duplicate - * the effort here. - */ - if (pScrn->vtSema && !pI830->noAccel && !pI830->directRenderingEnabled) - I830EmitFlush(pScrn); - /* * Check for FIFO underruns at block time (which amounts to just * periodically). If this happens, it means our DSPARB or some other
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) It does not matter whether i use EXA or XAA, its exactly the same. I also had this problem when XAA was still default. I'm not familiar with profiling, but with a little introduction i would like to try that. PS: I asked a X61T user about his experiences (running hardy as well) and he does not have this problem. The X61T is the newer version with a Intel GMA X3100. He can use a rotated X fine without disabling DRI, he has to disable composite though (which works fine on my X60T).
(In reply to comment #5) > 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, > 943/940GML Express Integrated Graphics Controller (rev 03) > > It does not matter whether i use EXA or XAA, its exactly the same. > I also had this problem when XAA was still default. > > I'm not familiar with profiling, but with a little introduction i would like to > try that. > > > PS: > I asked a X61T user about his experiences (running hardy as well) and he does > not have this problem. > The X61T is the newer version with a Intel GMA X3100. > He can use a rotated X fine without disabling DRI, he has to disable composite > though (which works fine on my X60T). > sascha heid, any update about the testing? we will need your help to collect some data as we don't have the environment here... thanks.
I have not done any testing, what do you want me to do?
(In reply to comment #7) > I have not done any testing, what do you want me to do? > I mean the profiling thing...as we can't reproduce this, we will need your help to provide us more hints to eventually fix this... thanks.
Created attachment 18146 [details] sysprof afterrotate Is this ok? I was using sysproof after display rotating.
Created attachment 18197 [details] sysprof in landscape mode
Created attachment 18198 [details] sysprof after rotating into portrait-mode
I ran sysprof and while it recorded i simply moved its window around for few seconds. I didnt run a full gnome-desktop, just X + 2 xterms + sysprof. However, all it shows are high numbers for [X] and "in kernel". They are not even that much higher after rotating the screen. Meanwhile im running Gentoo Linux. Gentoo Linux has more recent versions of xorg-server (1.4.2) and the intel-driver (2.3.2). Unfortunately now the rotated display is slow with dri both enabled or disabled. I confirmed dri being disabled with xdriinfo and by recompiling xorg and the intel-driver without dri support. Its still slow. I have profiling support in my kernel and in glibc, is there anything else i should do to get more detailed information from sysprof?
just a quick update: With the latest drivers backported to intrepid the rotated screen is still very slow (3-4 fps). It does no longer matter if DRI is enabled or not. I know 3 people with the same video-card (GMA945) that can confirm the problem and one person with the newer model (GMA X3100) who reports flawless performance since he upgraded to Intrepid and the newer drivers.
Current rotation works smooth on my 915G here with kernel 2.6.28, xf86-video-intel master or 2.5.99.2, mesa master. I think rotation performance is not an issue any more.
Does Master mean cvs? I boot ubuntu jaunty from time to time to try the newest drivers and it was still slow yesterday.
Not ubuntu repos, I mean upstream graphics components at git.freedesktop.org.
Below patch (on xf86-video-intel master or 2.6-branch) maybe fixes this. Can you verify? commit a4b023c17b9c3bd65fb9466ddb8a953f60244402 Author: Keith Packard <keithp@keithp.com> Date: Tue Jan 13 20:01:49 2009 -0800 Assign rotation memory dri_bo to rotation pixmap. As the rotation memory and rotation pixmap are allocated separately (to make rotation at startup work), the allocate dri_bo needs to be set in the pixmap for acceleration to work. This restores the performance in rotated modes. Signed-off-by: Keith Packard <keithp@keithp.com> diff --git a/src/i830_display.c b/src/i830_display.c index 50fbc4d..4fba1fb 100644 --- a/src/i830_display.c +++ b/src/i830_display.c @@ -1601,6 +1601,7 @@ static PixmapPtr i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int width, int height) { ScrnInfoPtr pScrn = crtc->scrn; + I830CrtcPrivatePtr intel_crtc = crtc->driver_private; I830Ptr pI830 = I830PTR(pScrn); int rotate_pitch; PixmapPtr rotate_pixmap; @@ -1621,6 +1622,8 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int width, int height) xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Couldn't allocate shadow pixmap for rotated CRTC\n"); } + if (intel_crtc->rotate_mem && intel_crtc->rotate_mem->bo) + i830_set_pixmap_bo(rotate_pixmap, intel_crtc->rotate_mem->bo); return rotate_pixmap; } _________
I failed to install xorg git on ubuntu jaunty but fortunately there is a very convienient x11.git overlay in gentoo-linux. The versions it installed are: mesa-7.3_rc2 xorg-server-1.5.3-r1 xf86-video-intel-2.6.0 Without the patch the performance is still bad. With the patch applied i get this error trying to make xf86-video-intel: kuh xf86-video-intel-2.6.0 # make make all-recursive make[1]: Entering directory `/xf86-video-intel-2.6.0' Making all in uxa make[2]: Entering directory `/xf86-video-intel-2.6.0/uxa' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/xf86-video-intel-2.6.0/uxa' Making all in src make[2]: Entering directory `/xf86-video-intel-2.6.0/src' make all-recursive make[3]: Entering directory `/xf86-video-intel-2.6.0/src' Making all in xvmc make[4]: Entering directory `/xf86-video-intel-2.6.0/src/xvmc' make all-am make[5]: Entering directory `/xf86-video-intel-2.6.0/src/xvmc' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/xf86-video-intel-2.6.0/src/xvmc' make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/xvmc' Making all in bios_reader make[4]: Entering directory `/xf86-video-intel-2.6.0/src/bios_reader' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/bios_reader' Making all in ch7017 make[4]: Entering directory `/xf86-video-intel-2.6.0/src/ch7017' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/ch7017' Making all in ch7xxx make[4]: Entering directory `/xf86-video-intel-2.6.0/src/ch7xxx' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/ch7xxx' Making all in ivch make[4]: Entering directory `/xf86-video-intel-2.6.0/src/ivch' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/ivch' Making all in sil164 make[4]: Entering directory `/xf86-video-intel-2.6.0/src/sil164' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/sil164' Making all in tfp410 make[4]: Entering directory `/xf86-video-intel-2.6.0/src/tfp410' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/tfp410' Making all in reg_dumper make[4]: Entering directory `/xf86-video-intel-2.6.0/src/reg_dumper' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/xf86-video-intel-2.6.0/src/reg_dumper' make[4]: Entering directory `/xf86-video-intel-2.6.0/src' ../doltcompile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -I../uxa -DI830_XV -DI830_USE_XAA -DI830_USE_EXA -g -O2 -MT i830_display.lo -MD -MP -MF .deps/i830_display.Tpo -c -o i830_display.lo i830_display.c i830_display.c: In function ‘i830_crtc_shadow_allocate’: i830_display.c:1601: error: redefinition of ‘intel_crtc’ i830_display.c:1599: error: previous definition of ‘intel_crtc’ was here i830_display.c: In function ‘i830_crtc_shadow_create’: i830_display.c:1648: error: ‘intel_crtc’ undeclared (first use in this function) i830_display.c:1648: error: (Each undeclared identifier is reported only once i830_display.c:1648: error: for each function it appears in.) i830_display.c:1649: warning: implicit declaration of function ‘i830_set_pixmap_bo’ i830_display.c:1649: warning: nested extern declaration of ‘i830_set_pixmap_bo’ make[4]: *** [i830_display.lo] Error 1 make[4]: Leaving directory `/xf86-video-intel-2.6.0/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/xf86-video-intel-2.6.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/xf86-video-intel-2.6.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/xf86-video-intel-2.6.0' make: *** [all] Error 2
It took me a while until i realized this patch might be included into git and so i compiled xf86-video-intel from git. And guess what, it seemed to be very fast. I have not yet build a full desktop, just moved a big xterm-window around but i did not notice any kind of slowdown.
(In reply to comment #19) > It took me a while until i realized this patch might be included into git and > so i compiled xf86-video-intel from git. > And guess what, it seemed to be very fast. > I have not yet build a full desktop, just moved a big xterm-window around but i > did not notice any kind of slowdown. > what if you runs a 3D app like glxgears , after rotation. is that ( moving xterm-window) still very fast?
Yes, glxgears is running and everything is still very fast. I built a full Desktop meanwhile, performance is great now.
great！ would you please kindly paste the combination of components you use now for our reference? I'll mark this bug as fixed.
mesa 7.3_rc2 xorg-server 1.5.3 xf86-video-intel git from 21.1.09
This bug is still present in Ubuntu Jaunty (driver 2.6.3). I just checked the source and the proposed patch below is indeed there, but performance is crap in portrait mode. (thinkpad x61t, 965GM) This is independent of whether I disable DRI in xorg.conf.
(In reply to comment #24) > This bug is still present in Ubuntu Jaunty (driver 2.6.3). I just checked the > source and the proposed patch below is indeed there, but performance is crap in > portrait mode. (thinkpad x61t, 965GM) This is independent of whether I > disable DRI in xorg.conf. This bug should be closed since the original reporter says it's fine now. For Bob's issue, it should be tracked in another bug, maybe bug#21570.
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.