[i945] 2.5.1 driver poor performance

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.

Try installing libdrm-intel1. Does it help?

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...

[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.

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

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?

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).

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

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.

And it appears to have not made any difference.

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

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.

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.

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.

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.

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?

[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

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?

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

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...)

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.

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-) ...

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.

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?

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.

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?

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

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.

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.

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.

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

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.

 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.

https://bugs.freedesktop.org/show_bug.cgi?id=16835: "The error message was cleaned up, but fixing the performance regression is out of scope for this release cycle."

...which leaves me in a somewhat foul mood.

Rebooting into 2.6.27 works for me I guess.

http://groups.google.com/group/linux.kernel/browse_thread/thread/d656dfef0d5b46d4

commit a7f014f2de04893f95cfe40fe35f15c8dae4b36e
Author: Eric Anholt <email address hidden>
Date: Tue Nov 25 14:02:05 2008 -0800

    drm/i915: Respect GM965/GM45 bit-17-instead-of-bit-11 option for swizzling.

    This fixes readpixels and buffer corruption when swapped out and in by
    disabling tiling on them.

    Now that we know that the bit 17 mode isn't just a mistake of older chipsets,
    we'll need to work on a clever fix so that we can get the performance of
    tiling on these chipsets, but that will require intrusive changes targeted
    at the next kernel release, not this one.

    Signed-off-by: Eric Anholt <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

Noted a patch above the above one, that disabled gem when pae is enabled due to some interaction. Our -server kernel has pae enabled. This suggests a workaround...

And having installed the -server kernel (2.6.27-4-server), I can confirm that it works around this issue.

Kevin, can you install linux-server (and possibly linux-restricted-modules-2.6-28-4-server if you need them for other hardware), reboot into it, and test?

Also, syockit off #ubuntu+1 seems to have an identical chipset, but without this issue (notably, his xorg.0.log file doesn't show the "(EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel" lines that mine and kevin's does)

(which leaves me in a somewhat less foul mood)

i can't confirm it. With server kernel i have less performance.
generick kernel glxgears ~350fps
server kernel glxgears ~160fps

fishor, attach your /var/log/xorg.0.log, you may not be seeing the same issues.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| fishor, attach your /var/log/xorg.0.log, you may not be seeing the same
| issues.

Hmm... other performance drop was realy coused by other issu, i915 was
loaded but /dev/dri/card0 not existed. I reloaded this module and now it
work with 360fps. But i can't confirm workaround with server kernel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl4RdEACgkQVVCoNUmKuAfPKwCdHJV3ae/vBssycStQEJaZPzVX
r98An13YXC7znW+GPNs1tqUPqMDePJBU
=6BG5
-----END PGP SIGNATURE-----

Hah, right. You're on 64 bit, and therefore don't have pae on the server kernel, and therefore don't have gem disabled due to pae being enabled, and therefore still have the issue.

> Current Operating System: Linux zwerg 2.6.28-4-server #11-Ubuntu SMP Fri Jan 16 22:38:58 UTC 2009 x86_64
> ...
> (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel
> (EE) intel(0): Failed to set tiling on back buffer: rejected by kernel
> (EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel

Today I have tested intel 2.6 drivers and 2.6.28 kernel. I can't report any improvement in 2D compiz performance setup is same as in my previous posts. I've tried kernel with PAE enabled and disabled, system is i386 (32 bit), acceleration UXA and the same error in log:

 (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel
(EE) intel(0): Failed to set tiling on back buffer: rejected by kernel
(EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel

After latest update from 26.01.09 (jaunty amd64) the performance with
glxgearx dropped to 40 fps.
before it was 300 fps with vanilla linux-next kernal and 150 fps with
2.6.28-5-generic.

I just testet UXA acceleration and gat 870 fps with linux-next and 750
fps with 2.6.28-5-generic

2009/1/26 fishor <email address hidden>:
> After latest update from 26.01.09 (jaunty amd64) the performance with
> glxgearx dropped to 40 fps.
> before it was 300 fps with vanilla linux-next kernal and 150 fps with
> 2.6.28-5-generic.
>
> I just testet UXA acceleration and gat 870 fps with linux-next and 750
> fps with 2.6.28-5-generic

Could you, please, provide your xorg.conf which helped you to improve
performance?

Which graphics accelerator do you have? GMA950?

--
Vit Pelcak

> Could you, please, provide your xorg.conf which helped you to improve
> performance?
>
> Which graphics accelerator do you have? GMA950?

Yes this is GMA950 on i945g

Here is my xorg.conf

2009/1/26 fishor <email address hidden>:
>
>> Could you, please, provide your xorg.conf which helped you to improve
>> performance?
>>
>> Which graphics accelerator do you have? GMA950?
>
> Yes this is GMA950 on i945g
>
> Here is my xorg.conf

Thanks.

--
Vit Pelcak

I just wanted to tell you that during boot udev complains about
missing /dev/card0 (or /dev/dri/card0?).

I'm still at ~ 450 fps in glxgears on GMA950, Core Duo and 2 GB RAM.

Regards
Vit Pelcak

Belisarivs schrieb:
> I just wanted to tell you that during boot udev complains about
> missing /dev/card0 (or /dev/dri/card0?).
>
> I'm still at ~ 450 fps in glxgears on GMA950, Core Duo and 2 GB RAM.
>
> Regards
> Vit Pelcak

probobly your i915 module will be loaded from initrd or not loaded at all.
check it with: lsmod | grep i915
or remove it from this list /etc/initramfs-tools/modules

> probobly your i915 module will be loaded from initrd or not loaded at all.
> check it with: lsmod | grep i915

$ lsmod | grep i915
i915 65412 1
drm 96424 2 i915

> or remove it from this list /etc/initramfs-tools/modules

It wasn't there.

--
Vit Pelcak

I also experience this problem. I tried disabling sync to VBlank in compiz, but it's still slow. Also, OpenGL games are painfully slow :( I attach my Xorg.0.log, and my xorg.conf is empty

My FPS:
289 frames in 5.0 seconds = 57.687 FPS
309 frames in 5.0 seconds = 61.761 FPS

My Card:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

My glxinfo:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090114
OpenGL version string: 2.1 Mesa 7.3-rc3
OpenGL shading language version string: 1.10
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
    GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
    GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
    GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite,
    GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow,
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array,
    GL_EXT_copy_texture, GL_EXT_draw_range_elements,
    GL_EXT_framebuff...

Interestingly, I noticed that the performance is OK if I use an external display and disable the internal LCD with "xrandr --output LVDS --off". If I switch the LVDS output back on, performance becomes awful again (regardless of whether an external display is connected).

I've just upgraded to the latest Jaunty and can no longer reproduce this. xserver-xorg-video-intel was not updated, but the kernel was, so perhaps the problem was there?

mdz:

You cannot reproduce your xrandr workaround, or cannot reproduce the performance issues? I just updated everything and I still get poor results.

Hey people.

Read the thread, please. I'm almost certain that your problem was
discussed here.

Run driconf and In "Synchronization with vertical refresh" select to
never synchronize.

FPS should go up. It went for me. But I'm still 50% below performance
of 2.4 driver.

2009/1/30 Jacob Peddicord <email address hidden>:
> mdz:
>
> You cannot reproduce your xrandr workaround, or cannot reproduce the
> performance issues? I just updated everything and I still get poor
> results.
>
> --
> [i945] 2.5.1 driver poor performance
> https://bugs.launchpad.net/bugs/303011
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Vit Pelcak

On Fri, Jan 30, 2009 at 09:59:59PM -0000, Jacob Peddicord wrote:
> mdz:
>
> You cannot reproduce your xrandr workaround, or cannot reproduce the
> performance issues? I just updated everything and I still get poor
> results.

After a suspend/resume cycle, the problem is back, and changing the xrandr
settings has no effect. There's something more subtle going on here.

--
 - mdz

Matt, that's bug 320813 and the workaround is to disable vblank.

I can confirm this bug on all my systems upgrading from Kubutnu intrepid to Kubuntu jaunty.
glxgears fall from 600 fps down to 60 fps.

2009/2/10 Michele Mordenti <email address hidden>:
> I can confirm this bug on all my systems upgrading from Kubutnu intrepid to Kubuntu jaunty.
> glxgears fall from 600 fps down to 60 fps.

Please, read thread and you'll find the answer. Performance shouldn't
drop lower than to 50%.

--
Vit Pelcak

Well, I disabled VBlank and got a boost, but it's still real slow:

4312 frames in 5.0 seconds = 862.341 FPS
4288 frames in 5.0 seconds = 857.482 FPS
4141 frames in 5.0 seconds = 828.042 FPS
4223 frames in 5.0 seconds = 844.442 FPS

Switching desktops with compiz on is unusable most of the time, same thing with OpenGL Games. I have disabled compiz for now until this is fixed. I'm attaching my Xorg.0.log once again

confirmed in jaunty alpha 4.... even though using GEM and DRI2 even worser
tested using wine running warcraft3 ft fps drops to 11 from 20 in intrepid

my chipset:
 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 I
ntegrated Graphics Controller [8086:2a02] (rev 03)

Do you think this bug will be fixed until the next alpha? or beta? and what about the final release?

I am asking because the desktop (I have tested kubuntu 9.04 alpha 4) is not usable with these bad performance, and in the freedesktop bug (https://bugs.freedesktop.org/show_bug.cgi?id=16835) one of the developers said:
"... but fixing the performance regression is out of scope for this release cycle."
(https://bugs.freedesktop.org/show_bug.cgi?id=16835#c2)

Also confirming this on jaunty alpha 4. Compositing (both compiz and KDE) is unusable.

xf86-video-intel 2.6.2 is released, perhaps this fixes our issues?

Here is the changes:
http://lists.freedesktop.org/archives/xorg/2009-February/044003.html

And according to a blog post by Eric Anholt, it looks like we may still see an xf86-video-intel 2.7.0 release by the end of March, pehaps that will make it into Jaunty?

Today my KDE4 session runs smoothly with about 900fps in glxgears.
Then I update the distro (kernel and intel driver) and it falls down to 90fps.
What happen?
In attach the /var/log/apt/term.log of last broken update (italian lang log, sorry)

I apologize for my bad English.

By installing xserver-xorg-video-intel-2.6.2, hardware acceleration is working again.
I get 1019.751 FPS on glxgears.

To install the 2.6.2 version you need to install libdrm-2.4.5 first(prerequisite)
Sources:
[1] http://dri.freedesktop.org/libdrm/
[2] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/?h=2.6

With xserver-xorg-video-intel-2.6.1 I get around 300 FPS, but it is still slow.

Silviu Grijincu:
How can I install the 2.6.2 version? (I guess it is not from the repositories since only 2.6.1 is in there).

I guess, he compiled it from source.

2009/2/26 Ofir Klinger <email address hidden>:
> With xserver-xorg-video-intel-2.6.1 I get around 300 FPS, but it is
> still slow.
>
> Silviu Grijincu:
> How can I install the 2.6.2 version? (I guess it is not from the repositories since only 2.6.1 is in there).
>
> --
> [i945] 2.5.1 driver poor performance
> https://bugs.launchpad.net/bugs/303011
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Vit Pelcak

Does anyone knows when 2.6.2 will come to Jaunty?

Will the driver be updated to 2.6.2 until the final release in April?

"Update to 2.6.3?" Wishlist bug 337301

Could it be related that in Jaunty with kernel 2.6.28 WorldOfGoo is unplayable due to poor performances ? Strangely enough, glxgears is at 250 fps and it looks like Compiz runs smoothly (I didn't try the cube but other effects were just fine)

With kernel 2.6.27 on the same system, worlofgoo works just fine but glxgears is under 200 (and compiz works well, just as with 2.6.28)

As I have an intel graphic card, I wonder if it's related to this bug or not. Is there a tool to measure 3D performances ?

kubuntu 9.04 alpha6
intel 945gm
compiz sucks kwin idem

I updated the driver from the repositories from 2.6.1 to 2.6.3 and got no improvements.

glxgears gives around 200 FPS.

Maybe KDE4 needs better hardware then the one in my laptop (lenovo 3000 N100)? or it is a bug in the driver?

On one of my systems with 4Gb of RAM I use the "-server" kernel and the performance is still slow.
Using the "-generic" kernel all works fine, but I use only a part of memory.

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

Performance is still very slow for me.
In Ioquake3 I get in Intrepid 87 FPS and in Jaunty 11 FPS w/o DRI2. (Resolution 640x480)

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

$ lshw | grep agp
          configuration: driver=agpgart-intel module=intel_agp

xserver-xorg-video-intel:
  Installed: 2:2.6.3-0ubuntu2
  Candidate: 2:2.6.3-0ubuntu2
  Version table:
 *** 2:2.6.3-0ubuntu2 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

linux-generic:
  Installed: 2.6.28.11.11
  Candidate: 2.6.28.11.11
  Version table:
 *** 2.6.28.11.11 0
        500 http://de.archive.ubuntu.com jaunty/restricted Packages
        100 /var/lib/dpkg/status

libdrm2:
  Installed: 2.4.5-0ubuntu2
  Candidate: 2.4.5-0ubuntu2
  Version table:
 *** 2.4.5-0ubuntu2 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

>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...

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

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)

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

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

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?

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

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.

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?

I can confirm this bug too on my Dell M1330.

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..

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

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?

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

Ofir, can you link it here?

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.

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.

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.

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.

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

> 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

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

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?

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

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)