[i945] 2.5.1 driver poor performance

[K. Lange]

Binary package hint: xserver-xorg-video-intel

The new 2.5.1 release of the Intel driver gives horrible performance.

Screenshot with fps marker, under compiz: http://oasis-games.com/~klange/wtf_intel251.png

As seen in the screenshot, the standard cube view in Compiz runs at a headache-inducing 2 frames per second. With 2.4, the framerate was easily ten times faster.

Jaunty, newest updates as of 11/27/2008, 10:00 EST.
Package version: 2.5.1-1ubuntu1
What I expected to happen: A frame rate of at least 10fps.
What happened instead: Poor framerates in Compiz, glxgears, and my own OpenGL applications.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
     Subsystem: Acer Incorporated [ALI] Device [1025:0090]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
     Subsystem: Acer Incorporated [ALI] Device [1025:0090]

[Eric Anholt (eric-anholt)]

That error message should probably only include the error string if ret != 0. I'm guessing that ret == 0 for you and you've got the same 945 setup we've got, where the cpu's interleaving makes swappable tiled objects (basically) impossible. To allow tiling on those systems we'll have to either play some tricks with the memory allocation and pin them, or get a lot more integrated into the paging system.

[K. Lange (k-lange)]

Binary package hint: xserver-xorg-video-intel

The new 2.5.1 release of the Intel driver is horribly slow.

Screenshot with fps marker, under compiz: http://oasis-games.com/~klange/wtf_intel251.png

As seen in the screenshot, the standard cube view in Compiz runs at a headache-inducing 2 frames per second. With 2.4, the framerate was easily ten times faster.

Jaunty, newest updates as of 11/27/2008, 10:00 EST.
Package version: 2.5.1-1ubuntu1
What I expected to happen: A frame rate of at least 10fps.
What happened instead: Slowness. Lots and lots of slowness.

[Timo Aaltonen (tjaalton)]

Try installing libdrm-intel1. Does it help?

[K. Lange (k-lange)]

Had to do that just to get the driver working in the first place, so no, it doesn't help.
Forgot that I was also going to report the unmarked dependency...

[Bryce Harrington (bryce)]

[This is an automated message]

Hi oasisgames,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[K. Lange (k-lange)]

All of my Xorg customizations should improve performance (and they do, but not enough).

[Trip Ericson (rovfan)]

I don't use compositing on the desktop but I'm having the same lousy performance after upgrading to the Jaunty alpha. My system has Intel's 965 graphics.

I attempted to run Sauerbraten which normally gets about 45 fps and got less than 1 fps. I also attempted to run Google Earth which threw an error about running OpenGL in software but, while slow as all hell, at least didn't lock up when I attempted to open my image overlays and shows all the letters and numbers it's supposed to. (See the other bug report I have active)

Do you want copies from my computer of the information that Kevin Lange gave you?

[Albert Damen (albrt)]

Can you please check the file permissions of /dev/dri/card* ?
libdrm in jaunty uses udev to create the device node, and I found /dev/dri/card0 now gets mode 660 (crw-rw----), instead of 666. If you get mode 660, please try to change the mode to 666 with sudo chmod 666 /dev/dri/card* and test performance again. For me, that gives a huge performance difference in sauerbraten.
(Kevin's xorg.conf sets dri mode to 666, but I am not sure if that still works now the device node is created via udev).

[Trip Ericson (rovfan)]

That corrected it. My performance is now about 18 fps, still lower than I used to get, but it's now playable.

Google Earth now no longer complains, but I accidentally left an image overlay on it while in software mode and now it freezes a few seconds after the program starts, as indicated in my bug report here when image overlays are used.

https://bugs.launchpad.net/ubuntu/+source/googleearth-package/+bug/165117

[K. Lange (k-lange)]

Seems someone screwed something up in X, as there's an options that's supposed to be able to set this for me:
Section "DRI"
 Mode 0666
EndSection
Yet still:
crw-rw---- 1 root video 226, 0 2008-12-04 19:46 /dev/dri/card0

Thanks for the tip, I'll see if it helps.

[K. Lange (k-lange)]

And it appears to have not made any difference.

[Albert Damen (albrt)]

Thanks for testing. As this didn't help for Kevin, I have filed the permissions issue as bug 306014.

[Jeffrey Baker (jwbaker)]

This isn't just a compositing/compiz problem or a 3D problem. I get horrible performance with just plain old xterms under metacity. Whatever is in 2.5.1 (-ubuntu5) driver is a huge step backwards from Intrepid. Tested on a GM965 at 1400x1050.

[Bryce Harrington (bryce)]

Let's focus this bug just on the compiz performance issue. Please file non-compiz performance issues separately, else this bug is likely to turn into a "me-too" storm. ;-)

In recent days a new xserver 1.6 has been uploaded, which contains code designed to improve -intel performance. Please re-test the compiz cube view and report the framerate seen. Also please attach a fresh Xorg.0.log from running with the 1.6 server.

[K. Lange (k-lange)]

No, because I run Compiz from Git, and therefore can't file bug reports on it. I simply used it as an example of poor performance.

[Jacob Peddicord (jpeddicord)]

I can confirm that Compiz (along with everything else 3D) still runs very slowly, with glxgears running at around 200FPS (or about 300FPS with card0 permissions set properly). This is after applying the latest updates.

Attached my X log, though I was unable to find anything out of the ordinary in it.

[Eric Anholt (eric-anholt)]

The error message was cleaned up, but fixing the performance regression is out of scope for this release cycle.

[Oleksij Rempel (olerem)]

If im Correct this is a bug for both kernel and intel driver.
With ubuntu kernel i get 130 fps on glxgears
With vanilla 2.6.28-rc9 i get 380fps

this i have with ubuntu kernel too:
mtrr: no MTRR for d0000000,10000000 found

now i will try to bisect intel driver. Or some body doing this?

[Eric Anholt (eric-anholt)]

*** Bug 19199 has been marked as a duplicate of this bug. ***

[Bryce Harrington (bryce)]

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

[Oleksij Rempel (olerem)]

Bryce Harrington schrieb:
> [This is an automatic notice.]
>
> We'd like to forward your bug upstream, however upstream requires
> that you first test it against their newer driver code.
>
> To save you the effort of building the driver from source, we've built
> packages for the driver and its new dependencies.
>
> So you have a couple options:
>
> 1. Download and test .debs for intrepid, from:
> https://edge.launchpad.net/~intel-gfx-testing/+archive
>

@Bryce
why xserver-xorg-video-intel 2.5.1 for intrepid is better whan same
version for jaunty?

[K. Lange (k-lange)]

I will test the newest updates, which I'm installing now. I'll report back later today.

[K. Lange (k-lange)]

Problem persists in newest updates; in fact, it seems to be even worse. Further, we still don't GEM support in our DRM drivers. I'd also like to report that earlier I had tested the drivers and X server from Xorg-edgers, which did have this problem at all (though it did have another big issue with pipe underruns, but that had an easy fix...)

[K. Lange (k-lange)]

Missing a few things in my last comment:
don't *have* GEM support...
... which did*n't* have this problem at all...

Don't know how that happened. I guess I type these in a hurry.

[M-komarovsky (m-komarovsky)]

Created an attachment (id=21440)
1GB setup / 2GB setup diff

[Belisarivs (v-pelcak)]

I experience this bug, too.

# lspci -vvnn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
        Subsystem: Hewlett-Packard Company Device [103c:30d5]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information <?>
        Kernel driver in use: agpgart-intel
        Kernel modules: intel-agp

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
        Subsystem: Hewlett-Packard Company Device [103c:30d5]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f0400000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 3000 [size=8]
        Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at f0480000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) ...

[Belisarivs (v-pelcak)]

Upgrading from edgers repository helped a bit.

Now I have hw acceleration on.

$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20080716 x86/MMX/SSE2

But performance is still quite a low (half compared to opensuse 11.1).

With exa, glxgears had ~300 fps, with uxa ~500fps. In openSUSE ~1000fps.

xorg.conf in attachment.

[mrvanes (mrvanes)]

I'm not sure if this is the same problem as I has but I recently stumbled on a dead-slow compiz after getting DRI2/UXA to work on my jaunty install using a intel 965 and xorg-edgers ppa.

I nailed to problem down to the compiz-wrapper (/usr/bin/compiz) not using -indirect-rendering when UXA/DRI2 is active and that is due to this test:

if [ $($GLXINFO 2>/dev/null | grep GLX_EXT_texture_from_pixmap -c) -gt 2 ]

With EXA/DRI this results in 2 occurrences of "GLX_EXT_texture_from pixmap" and so -indirect-rendering is used (correct, or at least VERY fast). With UXA/DRI2 this test finds 3 occurrences and thus disables -indirect-rendering. Without -indirect-rendering compiz is dead-slow on my intel 965 (with UXA) so either something is wrong with the driver (and the wrapper is correct) or the wrapper test is wrong (for UXA/DRI2) and should be changed to cover DRI2/UXA and -indirect-rendering correctly.

If this totally unrelated, I'm sorry... should I file a different bug concerning dead-slow compiz using DRI2?

[Peter Clifton (pcjc2)]

mrvanes: I shouldn't be commenting on this, since its not in its own bug, but with the DRI2 drivers, I believe you'll find there is a problem with syncing to VBlank. Try turning off sync to vblank in the compiz settings. For me, this made a difference of 1frame every 3 seconds -> complety usable.

[Milan Oravec (moravec-ukf)]

I'm also suffering under this issues. My hw is i945GM in sony vaio sz1xp, distribution is ubuntu interpid with Jaunty xorg-edgers ppa packages. I always compile my own kernel which exactly suits my hw, and have tux on ice support.

When I'm on 2.6.28 kernel, I'm able to enable GEM via UXA option in xorg.conf. Performance is very low compared to standard libs and drivers coming with stock Intepid (300 FPS to ~1200FPS in glxgears) and beryl is very unresponsive. Intel xorg driver is compiled against latest ppa source package too, and is 2.5.99.1 version. X server is stock Interpid version 1.5.3. With latest package update (yesterday) from xorg-edgers ppa is it even worse only ~50 FPS.

Today I'm switched back to 2.6.27 kernel, with no package change. Glxgears performance is same about 50FPS but beryl runs perfectly smooth. Glxinfo says:

Failed to initialize GEM. Falling back to classic.
...
OpenGL renderer string: Mesa DRI Intel(R) 945GM 20080716 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.3-rc1
...

which is OK on 2.6.27 kernel. With 2.6.28 is there GEM version of DRI exposed.

Is there anybody who haven't this issues?

[Andrew King (anders-king-00)]

Same here. X is almost unusable in the current configuration. Mouse pointer does not keep up with movements.
Dell Vostro 1400
Intel X3100 GM965
...
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20080716 x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.3-devel
OpenGL shading language version string: 1.10
...
glxgears gets <20FPS

I can give lspci/Xorg.O.log/xorg.conf if required.

Regards,
Andrew

[Belisarivs (v-pelcak)]

Guys, try "glxinfo | grep render". Most probably you have sw rendering.

For no obvious reason, I couldn't get hw acceleration working. That is
reason of performance drop.

I didn't try compiz with it, gut in glxgears I experienced drom from
~1000 fps to ~300 fps.

However, upgrading by edgers repository brought hw acceleration back,
glxgears improved to ~450 fps and Compiz runs pretty smoothly to me.
Although some minor glitches are visible as performance is still below
that I had in Intrepid.

So, try to upgrade packages with edgers repository. It should help.
But don't expect too much.

[Milan Oravec (moravec-ukf)]

I'm sure I've HW acceleration on all the tests:

Failed to initialize GEM. Falling back to classic.
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) 945GM 20080716 x86/MMX/SSE2

and

root@migo-vaio:~/# glxgears
Failed to initialize GEM. Falling back to classic.
293 frames in 5.0 seconds = 58.540 FPS
299 frames in 5.0 seconds = 59.647 FPS
298 frames in 5.0 seconds = 59.444 FPS

it is list form 2.6.27 kernel therefore is GEM disabled.

With update to mesa 7.3 and other dependent packages from edgers repository I'm down to ~50 FPS in glxgears (from ~300).

Under 2.6.28 is GEM enabled and HW accel. is ON but 3D performance is same low and compiz is useles. For example, connecting to remote desktop (terminal server client) uses 50% CPU time nonstop.

With 2.6.27 kernel is GEM disabled, 3D performance is horrible (according glxgears), but desktop performance is OK, as used to be before my experiments with edgers repository and GEM.

[Jeffrey Baker (jwbaker)]

On Wed, Jan 14, 2009 at 12:53 AM, Milan Oravec <email address hidden> wrote:
> I'm sure I've HW acceleration on all the tests:
>
> Failed to initialize GEM. Falling back to classic.
> direct rendering: Yes
> OpenGL renderer string: Mesa DRI Intel(R) 945GM 20080716 x86/MMX/SSE2
>
> and
>
> root@migo-vaio:~/# glxgears
> Failed to initialize GEM. Falling back to classic.
> 293 frames in 5.0 seconds = 58.540 FPS
> 299 frames in 5.0 seconds = 59.647 FPS
> 298 frames in 5.0 seconds = 59.444 FPS

It looks like you have vblank sync enabled.

[Milan Oravec (moravec-ukf)]

Thank's Jeffrey. Yes, you are right. Glxgers performance was limited due vsync settings. In 2.6.27 kernel with disabled vsync and unchanged conf. form my previous posts is now glxgers performance:

root@migo-vaio:/etc# glxgears
Failed to initialize GEM. Falling back to classic.
3280 frames in 5.0 seconds = 655.962 FPS
3652 frames in 5.0 seconds = 730.313 FPS
3638 frames in 5.0 seconds = 727.565 FPS

[Directrix1 (directrix1)]

In the file: /lib/udev/rules.d/50-udev-default.rules change the line that reads like:
KERNEL=="card[0-9]*", NAME="dri/%k"
to this:
KERNEL=="card[0-9]*", MODE="0666", NAME="dri/%k"

That got DRI at least partially "working" but it is still dog slow (but not as slow at least). I'm using Jaunty with Intel i943 graphics.

[Ivan Stetsenko (stetzen)]

 Directrix1 wrote 11 hours ago: (permalink)

In the file: /lib/udev/rules.d/50-udev-default.rules change the line that reads like:
KERNEL=="card[0-9]*", NAME="dri/%k"
to this:
KERNEL=="card[0-9]*", MODE="0666", NAME="dri/%k"

That got DRI at least partially "working" but it is still dog slow (but not as slow at least). I'm using Jaunty with Intel i943 graphics.

If MODE="0666" is enabled, I'm getting about 700 fps at glxgears and GEM is marked as working in glxinfo, but bug #96991 appears (3d apps become broken). If this option is not enabled, I'm getting about 70 fps, but #96991 is gone and there is no GEM in glxinfo.

[Ivan Stetsenko (stetzen)]

>Could it be that this problem is related to systems were the graphic chip is connected through AGP?

I think, it may be. with

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
configuration: driver=agpgart-intel module=intel_agp

I'm having relatively low performance as well compared to other Intel GM965 users, and UXA decreases my 3D performance, when it is shown to increase it. Well. we definitely need a little bit more statistic info about it...

[nowardev (nowardev)]

mah i don't think so ,

i used an -server kernel and it was nice then...

so i think it's a problem with the new driver or something like that

[Eric Anholt (eric-anholt)]

*** Bug 19873 has been marked as a duplicate of this bug. ***

[Carey Underwood (cwillu)]

I went from smoothly dragging transparent windows around the screen a week ago (but only when running the -server kernel, -generic got 1fps) to one-frame-per-second as of right now (under the -server kernel or the -generic kernel).

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

[Matthias Blaicher (blaicher)]

@ Cerey: Maybe your problem is related to bug 340578. For me it helped
to disable v-sync in compiz.

[Belisarivs (v-pelcak)]

I found this article. Maybe that explains it.

For me numbers fit as they say. Drom from ~1000 fps to 440 fps in glxgears.

http://qa-rockstar.livejournal.com/7869.html

[Achim (ach1m)]

No I don't think so.

Jaunty has no KMS and DRI2 will not be enabled by default.

Haven't you seen my comment with the results of ioquake3?

[Carey Underwood (cwillu)]

@Matthias: that bug is unrelated, different hardware. Also, UXA just hardlocks the machine.

[Carey Underwood (cwillu)]

I lied, it's actually just X that locks up with a corrupted display. chvt'ing, restoring vbestate and posting the display brings back a terminal session.

[Freedesktop-sievertsen (freedesktop-sievertsen)]

Created an attachment (id=24152)
Xorg.0.log with Option "ModeDebug" "true"

[Gergely Csépány (cheoppy)]

I was wondering if there is an option to disable GEM support on 2.6.28 kernels? This way the intel driver would fall back to the traditional mode and would be usable on dual channel systems until the tiling problem is fixed.

[Freedesktop-sievertsen (freedesktop-sievertsen)]

Do you need any additional information to fix the bug?

[Ivan Sagalaev (isagalaev)]

Confirming poor performance comparing to Intrepid with xserver-xorg-video-intel 2.6.3. Should I gather any statistics from my machine (and how?) or the case is clear and everyone just waiting a fix?

[lispy (janietz)]

I can confirm this bug too on my Dell M1330.

[anarsoul (anarsoul)]

Created an attachment (id=24416)
i915-gem-disable.patch

With this patch applied on 2.6.29 you'll be able to disable gem with module parameter. Just load i915.ko with gem_enable=0.

This patch is only a workaround and is not intended to be clean.

[anarsoul (anarsoul)]

Created an attachment (id=24417)
i915-gem-disable.patch

Fixed wrong path in patch.

[taiebot65 (taiebot65)]

I would like to confirm this bug too and would like to say that i had to disable all the compositing manager in both UXA/EXA... because after few hours when i'm using them switching between applications makes my computer becoming really slow because there is a lots of writing on my hard drive..

[Wesley Velroij (velroy1)]

2 years ago I was recommending for everyone to use intel vga, but now it seems vga are horrible :( hope this will improve.

[Ofir Klinger (klinger-ofir)]

Upstream has submitted a patch which disables gem in the kernel 2.6.29.

Will this patch solve the performance issues, or at least 'solve' them for the final release?
Is this patch needed to be applied manually, or it will be bundled in ubuntu's official deb?

[Fdo (fdo)]

(In reply to comment #15)
> Created an attachment (id=24417) [details]
> i915-gem-disable.patch

Thanks for this patch. While a proper fix would obviously be preferred this should at least let me start using a newer kernel than the .27 one I'm stuck on just now.

[Gergely Csépány (cheoppy)]

(In reply to comment #14)
> Created an attachment (id=24416) [details]
> i915-gem-disable.patch
>
> With this patch applied on 2.6.29 you'll be able to disable gem with module
> parameter. Just load i915.ko with gem_enable=0.
>
> This patch is only a workaround and is not intended to be clean.
>

Thank you for providing this patch. May it be applied to 2.6.28 too? (Comparing the .28 and .29 sources, I found the same pieces of code and I intend to use the ubuntu kernel source, which is based on .28 for jaunty.)
I'll try it when I have some time to compile the kernel(s), presumably early next week, and I'll report the results.

[Carey Underwood (cwillu)]

> Upstream has submitted a patch which disables gem in the kernel 2.6.29.

Ofir, can you link it here?

[K. Lange (k-lange)]

It seems I've let this report run wild: The issue in this bug is EXA being "damn slow" on some Intel graphics chipsets. While the issue has yet to be fixed, the things being discussed here have nothing to do with it.

I'm removing myself from the mailing list for the report because it no longer affects me: I've been using UXA for months with great results.

[Eric Anholt (eric-anholt)]

Half of the required fix:

http://<email address hidden>/msg39203.html

This will give you tiling on A17-affected machines at the expense of glReadPixels. Next up will be fixing Mesa to recover glReadPixels. Additionally, testing has revealed that DRI2 tiling on 915-class machines may result in 2D corruption when creating DRI2 buffers due to bo reuse. We're looking into that as well.

[Carey Underwood (cwillu)]

This is not a duplicate of bug #252094:

This is referring specifically to a performance regression in jaunty, on chipsets that worked fine under intrepid.

[Gregory Oschwald (osch0001)]

Carey, using UXA does not fix your problem? These issues are known regressions in EXA, which is why I marked it as a dupe of #252094.

[Fdo (fdo)]

(changing title back to original: I presume that wasn't intended Eric)

[Carey Underwood (cwillu)]

As far as jaunty is concerned, is it not established that UXA isn't a fix?

The existence of a similar workaround doesn't imply that the bug is the same, and the bug in question states specifically that bugs with the generic symptoms but known particular causes should be in their own bug reports.

In particular, the EXA regression on 945 is due to an oversight in GEM, as noted in an above comment (which in turn isn't linked on the bug that this was dup'd against.

[Carey Underwood (cwillu)]

(... not noted on the other bug because the other bug is generic issues, and the oversight is particular to the 945)

[Ivan Sagalaev (isagalaev)]

> As far as jaunty is concerned, is it not established that UXA isn't a fix?

I have a hard time understanding this particular double negation :-). But I just tested setting

Option "AccelMethod" "UXA"

in my xorg.conf and it looks like it fixed the speed issue. There are other small issues though that weren't here without the option:

- menus open with non-antialiased fonts and then are quickly redrawn with antialiasing
- gksudo prompt seem to not shadow the background

[Carey Underwood (cwillu)]

UXA will not be enabled by default in jaunty, and so enabling it by hand is a workaround, not a fix.

[Ivan Sagalaev (isagalaev)]

This is unfortunate... Seems like a serious regression from Intrepid.

Can you suggest any link to read some introduction about what are EXA and UXA and why the latter is not possible for Jaunty?

[Carey Underwood (cwillu)]

The various intel bugs currently on launchpad have extensive commentary on the problems and the rationales. Unfortunately, many of the bugs recently marked as duplicate contained that commentary, and so won't show up in the search results by default.

Hence, my underwhelming response for with people marking bugs as duplicate without making sure the new bug contains all the information of the old. :p

[Bryce Harrington (bryce)]

I agree with Kevin this bug has wandered from the original issue.

I'm closing this bug for the following reasons:

 * It has the same upstream bug link as our bug #349992, so at heart is a dupe of that. Bug 349992 is further along, shorter, and already assigned and targeted, so it's the better report to focus on.
 * Most comments in this report are due to vblank settings, which is an unrelated issue now solved in Jaunty
 * The original reporter is satisfied with the workaround of using UXA, and has unsubscribed
 * For general "performance sucks" complaints, we already have bug 252094
 * This bug has a poorly selected title, and will accumulate more incorrect 'me-too's (even if we fix it)

[anarsoul (anarsoul)]

(In reply to comment #18)
> Half of the required fix:
>
> http://<email address hidden>/msg39203.html
>
> This will give you tiling on A17-affected machines at the expense of
> glReadPixels. Next up will be fixing Mesa to recover glReadPixels.
> Additionally, testing has revealed that DRI2 tiling on 915-class machines may
> result in 2D corruption when creating DRI2 buffers due to bo reuse. We're
> looking into that as well.

Any news about mesa patch? It's quite annoying to have no _complete_ workaround for this issue for half of an year.

[Fdo (fdo)]

We have a patch in Mandriva that seems to work as an automatic workaround.
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=log

Obviously a proper fix is better :)

[anarsoul (anarsoul)]

(In reply to comment #21)
> We have a patch in Mandriva that seems to work as an automatic workaround.
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=log
>
> Obviously a proper fix is better :)
>

Thanks! Why not to include this patch into the mainline kernel? Non-gem 3D is better than no 3D at all. Please submit it to the dri-devel maillist

[Eric Anholt (eric-anholt)]

commit 280b713b5b0fd84cf2469098aee88acbb5de859c
Author: Eric Anholt <email address hidden>
Date: Thu Mar 12 16:56:27 2009 -0700

    drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.

queued to linus

[Fdo (fdo)]

Eric, you mentioned in c18 that this patch is only half of the required fix.... any news on the other half?

[Gergely Csépány (cheoppy)]

It's already in 2.6.30-rc2, works like a charm, thank you very much for this fix!