EXA is balls-achingly slow

True, to some extent. I didn't think it was too slow with the Thinkpad X60 I had for awhile (i945GM or so), apart from scrolling in firefox.

It's https://bugs.freedesktop.org/show_bug.cgi?id=13389

Adding the line bellow to Section "Device" currently works better (like describe in the freedesktop bug) :
        Option "AccelMethod" "XAA"

Unfortunately, to make EXA performance better it needs the new memory manager upstream is working on (TTM). It's too intrusive for hardy, so we'll probably switch back to XAA after alpha3.

Timo, can you give a reference (or IRC log snippets) for this info about the TTM requirement?

The upstream bug report mentioned on comment #2, and this from #xorg-devel:

01:51 < tjaalton> is there hope seeing it fixed in the next few months?
01:51 < tjaalton> since switching back to XAA is tempting
02:18 < airlied> tjaalton: probably .. hopefully it'll be fixed for Fedoora 9..
09:23 < tjaalton> airlied: ok, that doesn't help ubuntu 8.04 though :/
09:43 < tjaalton> and patching the driver to use XAA again seems to be the only option now
09:48 < airlied> tjaalton: I'd go with that option really..
09:48 < airlied> EXA by default == bad idea on 965
09:48 < airlied> other option is to turn of EXA compositing .. but that'll make rotation
                 really slow
09:48 < tjaalton> bad idea on any intel it seems..
09:48 < tjaalton> at least 945 is just as slow

so unless I've misunderstood, to make it work better we need the batchbuffer stuff which in turn requires TTM.

Switch back to XAA is bad because:
1) Ubuntu users will be deprived of textured video and power saving (by the way of fb compression) for a year¹
2) XAA is basically deprecated and its bugs are fixed as second priority. Do you want to release LTS with driver abandoned by upstream?

¹ textured video was disabled on intel driver shipped in 7.10. EXA will be disabled in 8.04. This way Ubuntu users will get those features no sooner than 8.10.

Bumping up importance. I agree reverting back to XAA on 965, and we should explore alternate solutions if there's any out there.

You could try this option in the Device section.

Option "MigrationHeuristic" "greedy"

I have this problem on a video card with the following id:

00:02.0 0300: 8086:27a2 (rev 03)
00:02.1 0380: 8086:27a6 (rev 03)

which should be i945 according to the following line in Xorg log:

(--) Chipset 945GM found

I confirm that using XAA I have no XV video, just a blue window, under compiz.

The TTM bits are in -mm kernel right now and should be merged for 2.6.25, it would be much better if this can be backported, instead of releasing a LTS with XAA. I am actually thinking of building a mm kernel to see how the performance increases.

here's what I made:

Option "AccelMethod" "exa"
Option "MigrationHeuristic" "greedy"
Option "ExaNoComposite" "true"

In hardy with these options in xorg.conf with an intel i945 card, I get a system that is about as fast as with xaa. So why should exa be disabled?

I've also added this:
INTEL_BATCH="1"
in /etc/environment

Even scrolling in firefox works great!
That's wonderful!! :))
Try it out! Maybe we can still have exa+intel in hardy!

PS: now that exa works for me I'd like to try textured video, which is disabled by ubuntu in hardy...
Giovanni Masucci

btw: compiz works great too :-)
I'm happy now!

err...sorry. I have
Option "ExaNoComposite" "false"
in xorg.conf, not true.
My mistake, forgive me.

Lukas's solution works great for me (scroll is OK, compiz is OK) : in the Device section, add

Option "MigrationHeuristic" "greedy"

Giovanni, ld2ndR: does xv video work for you?

xv works for me, with video overlay and textured video (textured video is disabled in hardy for now, so I've tested it with debian sid driver).
Video overlay is efficient and fast as with xaa.
Textured video works (perfect compiz integration) but tends to be slow on my system.

Adding the options "AccelMethod" "exa", "MigrationHeuristic" "greedy", and
"ExaNoComposite" "false" to the device section of xorg.conf allows compiz to
work for me without the boarder glitches in compiz and video works. This is
a first for me with my x3100 graphics card.

May I ask what these three options do?
Also I did not add INTEL_BATCH="1" to /etc/environment. What does this do
and sholud I?

@Elias
In my system the INTEL_BATCH="1" option give me a great performance boost on glxgears.
Try to run in a terminal glxgears and then:
INTEL_BATCH=1 glxgears
and compare the results.

With glxgears originally 524.789 FPS. After adding INTEL_BATCH="1" and
rebooting 900.732 FPS. You are right this seems to be a definite performance
boost.

This might be off the wall, however on one of my systems I got a BIG performance boost by setting:

System, Preferences, Apperance, Visual Effects, to None.

As installed none of the choices were checked, None, Normal, or Extra. Pretty sluggish.

I tried all three choices and for me, None gave the best performance.

Cheers, Jerry

jerry:

"None" doesn't apply here. No effects simply means running your desktop without any 3D acceleration at all, at which point neither XAA nor EXA is required. All drawing is done by the CPU in this mode.

On my i945, the fix works and setting INTEL_BATCH makes everything faster.

Vincenzo Ciancia a écrit :
> Giovanni, ld2ndR: does xv video work for you?

I don't know how to test if xv video works or not. Can you give me a
command please ?

ld2ndR: install mplayer and run

mplayer -vo xv FILENAME

where FILENAME is any movie which is supported by ubuntu codecs (if you want to have more codecs, you have to look for unofficial packages, e.g. medibuntu).

To test if your file is working _without_ xv accelerated video, just do

mplayer -vo x11 FILENAME (if your system is fast enough, this should also work during 3d effects, while with xv you'll see a blue window when rotating cube, zooming etc.)

Vincenzo

mplayer runs perfectly elephant dreams movie with xv. It also works great with x11, but uses 2 or 3 times more CPU.
(I only use Option "MigrationHeuristic" "greedy")

I've also seen what you said about 3D effects ;).

I can also confirm that on my Samsung !45 with Intel X3100 graphics adding INTEL_BATCH="1" to /etc/environment and putting the following into my xorg.conf:
        Option "AccelMethod" "EXA"
        Option "ExaNoComposite" "false"
        Option "MigrationHeuristic" "greedy"

solved my problems with X!

Scrolling firefox is fast as in gutsy, compiz works, no window shadow corruption and videos work as well.

Maybe this should be considered instead of just reverting to XAA.

+1 to the EXA workaround confirmation party

Can confirm bug and workaround with further details.

On current Hardy with chipset and video card:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

With xorg (1:7.3+10ubuntu4) and intel driver (2:2.2.0.90-2ubuntu2):

2D acceleration, especially text scrolling is fast, even with compiz enabled.

Xv video playback works fine, but when compiz enabled it is slow and drops a lot of frames.

When having a virtual display (even below or equal to 2048x2048) with multiple display devices (regardless of clone or extended mode), a system hang doesn't occur anymore when running 3D apps.

System still hangs when running 3D apps, if one of the displays is smaller than the virtual display.

After a longer period of testing of the workaround, I experienced
that the system still occasionally hangs when running 3D apps, even having just one screen.

Also Xv playback is still unusable, when compiz enabled. Although slow text scrolling is completely resolved.

I have to fall back to XAA. (Xv and compiz won't work together this where either, but is at least stable until now.)

Hmm, here's a first draft at a couple patches (one against xserver, one against -intel) to allow forcing greedy mode on i965 with exa:

Here's an alternate form of the intel patch, which is a tad cleaner, but basically does the same thing.

Sorry, the test in the xserver patch was incorrect, leading to FTBS; I think the patch needs to look more like this.

Can confirm this bug and workaround on hardy with GM965.

Also to note, that with the workaround (EXA with MigrationHeuristic greedy and the INTEL_BATCH env. variable set), Xv video in mplayer works properly during 3D effects (No blue screen, instead proper video), including on the cube while turning.

We're uploading a tested fix for this issue which switches greedy mode on for i965. .dsc's and such are at:

http://people.ubuntu.com/~bryce/Uploads/

-intel 2ubuntu5 turns greedy mode on for i965 when using EXA.
-intel 2ubuntu6 switches us back to XAA for all chipsets except i965.

Also, attached is a proposed alternative patch to use greedy for all chipsets when using EXA; in which the 2ubuntu6 patch (and optionally 2ubuntu5, although line numbers might need tweaked) would be reverted. I don't have a solid feel for whether EXA+greedy on all intel chipsets is safer or better than XAA-on-all-except-EXA-for-i965, but these patches should allow us to go either way. All else being equal, it would be nice to ship EXA on by default for everything since we'd be more consistent with upstream.

I've been running greedy EXA on my i915 for months, and it works flawlessly.

I can confirm this issue on i915. The line " Option "MigrationHeuristic" "greedy" " fixes it for me and compiz seems to be faster than under Gutsy but that might be subjective and/or related to the INTEL_BATCH thing.
Maybe EXA and greedy could be enabled on all supported Intel hardware for Hardy 5 with confirming question for all releated Intel bugs. If it doesn't fix them or makes new problems XAA could be still the fallback option.

unggnu, thanks for the feedback about that; Ng also said he thought greedy improved things on 855 as well, and I've noticed numerous bugs against 945, etc. that sound suspiciously similar to the 965 issues. If we can confirm greedy addresses issues on more chipsets, then I think forcing greedy for all intel chips would probably be worth doing.

ungnu, could you test with and without the INTEL_BATCH option and see if you can definitively show whether the performance effects are true? (Scrolling firefox on a large web page seems to be a good way to detect performance differences; I wish we had an automated test we could run to do this.)

I am not sure if there is a difference with scrolling but at least with glxgears INTEL_BATCH has an impact. I have read somewhere that INTEL_BATCH have no influence on higher 3D games but I don't know a good 3D benchmark from repository.

I am using current Hardy and in both cases Compiz was active. The resolution on my external display was 1680x1050 and the LFP was disabled.
VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Hardy with INTEL_BATCH:
4153 frames in 5.0 seconds = 830.491 FPS
4225 frames in 5.0 seconds = 844.903 FPS
4223 frames in 5.0 seconds = 844.403 FPS

Hardy without INTEL_BATCH:
3466 frames in 5.0 seconds = 693.124 FPS
3478 frames in 5.0 seconds = 695.567 FPS
3491 frames in 5.0 seconds = 698.163 FPS

current Gutsy without Compiz and INTEL_BATCH:
3679 frames in 5.0 seconds = 735.717 FPS
3673 frames in 5.0 seconds = 734.414 FPS
3613 frames in 5.0 seconds = 722.541 FPS

Intel 945GM

Hardy A4 with INTEL_BATCH and greedy enabled
mabovo@macbook:~$ glxgears
8074 frames in 5.0 seconds = 1614.641 FPS
8371 frames in 5.0 seconds = 1674.095 FPS
8358 frames in 5.0 seconds = 1671.499 FPS
8208 frames in 5.0 seconds = 1641.480 FPS
8341 frames in 5.0 seconds = 1668.159 FPS
8352 frames in 5.0 seconds = 1670.263 FPS

xserver-xorg-video-intel (2:2.2.0.90-2ubuntu6) hardy; urgency=low

  * Add 06_xaa_as_default_except_i965.patch to switch us back to XAA by
    default for intel chipsets for performance reasons, except for i965
    which does not work as well with XAA (Xv video doesn't display
    properly.) This patch essentially just reverts upstream's 'Default to
    EXA' patch, and adds a special case i965 to allow it to use EXA.

 -- Bryce Harrington <email address hidden> Tue, 19 Feb 2008 14:27:18 -0800

xserver-xorg-video-intel (2:2.2.0.90-2ubuntu5) hardy; urgency=low

  * Add 05_intel_exa_force_greedy.patch to force use of greedy mode on
    i965 hardware. (closes LP: #177492, #148247, #152206)

 -- Bryce Harrington <email address hidden> Tue, 19 Feb 2008 13:48:02 -0800

** Changed in: xserver-xorg-video-intel (Ubuntu)
       Status: Fix Committed => Fix Released

Bryce: I don0't understand what's happening. We all said EXA is fine and faster than XAA, with the mentioned workarounds. OTOH, XAA in hardy does not play videos (on my i945, PCI id 8086:27a2). I am currently happy with EXA, greedy and INTEL_BATCH why did you revert to XAA?

Vincenzo, in the original discussion (comments 4, 6 from Timo), the plan all along had been to switch back to XAA after alpha3 for stability and performance. However, 965 is *really* broken with XAA so we planned to stay with EXA for that. It was even more broken with EXA, but the greedy patch you guys identified solved that. Thus the patches we uploaded.

The reports about EXA being fine and faster than XAA for <965 were rather anecdotal, so I guess they didn't capture our attention as well as the 965 issues. However, it's true there's a *lot* of these anecdotes especially now that I look. In any case, I had a hunch we might want to adjust the fix, so I did the change in two pieces - specifically so we could revert one or the other as needed.

Anyway, since we've been running EXA a while, and since upstream is encouraging dropping XAA anyway, I guess it does little harm for us to leave EXA on, so we'll go ahead and drop that patch 06 at this time.

I am also interested in seeing more detailed testing of use of the greedy flag for EXA on <965. It'd be fairly trivial to extend the greedy patch to cover all chipsets, but I don't know if doing so could cause regressions for a lot of folk.

unggnu and mabovo, it is interesting that INTEL_BATCH improves glxgears framerates, but like you say, glxgears is really more of a toy example than a real benchmark. What's needed is to test it with a real world workload - a 3D game would be suitable for this. I did some looking around online for better data on INTEL_BATCH, but what I've seen only appears to give glxgears data, which is not very compelling.

Anyway, if you can more thoroughly investigate the performance situation with some real world 3D apps and demonstrate that the performance with INTEL_BATCH is better than without, then please file a new bug to request switching that on.

The problem is that the usual 3D games have no constant route so a test isn't that accurate but at least with planetpenguin-racer without doing anything it seems that I got four frames more with INTEL_BATCH at the start. Around ~19 instead of ~15 with my native resolution of 1366x768 and compiz enabled. But this might be random. I guess the best option is to ask the developers of the Intel driver which effect it might have.
I am not sure if EXA is faster but at least it seems to work with Greedy and is upstream approved. But of course stability is more important and the problem is that Hardy Alpha 5 would have XAA enabled I guess so it is not so easy to get much feedback.

Hi

unggnu wrote:
> The problem is that the usual 3D games have no constant route so a test isn't that accurate

quake games have, for the longest time, provided benchmarking (as do
many other games).

I've not tested openarena (GPL'd quake3), but it's in our archives and
almost certainly provides the same benchmark options. This would be a
convenient test that anyone can run and will give us a complex,
real-world metric.

Cheers,
--
Chris Jones
   <email address hidden>
    www.canonical.com

On current Hardy (running on a Thinkpad R61i):

$ lspci|head -n3
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

$ uname -r
2.6.24-8-generic

$ apt-cache show xserver-xorg-video-intel|grep Version
Version: 2:2.2.0.90-2ubuntu6

$ grep -A2 -B6 2048 /etc/X11/xorg.conf
Section "Screen"
        Identifier "Default Screen"
        Monitor "Configured Monitor"
        DefaultDepth 24
        SubSection "Display"
                Depth 24
                Virtual 2048 2048
        EndSubSection
EndSection

1. default EXA accel.,no further setting:
Xv without compiz: fine
3D app: kernel hang
compiz: works, but some effects are broken (e.g. border shadows)
Xv with compiz: _slow_, unusable

2. XAA accel.,no further setting:
Xv without compiz: fine
3D app:
compiz: works, seems faster, no broken effects
Xv with compiz: doesn't work ( X11 error: BadAlloc (insufficient resources for operation) )

3. default EXA accel.,INTEL_BATCH="1":
Xv without compiz: fine
3D app: works
compiz: works, but some effects are broken (e.g. border shadows)
Xv with compiz: _slow_, unusable

4. XAA accel.,INTEL_BATCH="1":
Xv without compiz: fine
3D app: kernel hang
compiz: works, seems faster, no broken effects
Xv with compiz: doesn't work ( X11 error: BadAlloc (insufficient resources for operation) )

I haven't experienced any effects of the INTEL_BATCH option. Although with EXA there are broken effects with Compiz.
Is there no way to get the Xv playback working with compiz?

How to reproduce the kernel hang with the 3D app:
Attach a second monitor, and set your screensaver to "Queens".
Now lock you system. The screensaver should start on both screens. It seems slow and laggy, but works until you don't move you mouse or press any key.
In this moment, when the password dialog should pop-up to unlock your screen, the displayed screen freezes and the system does not respond to any event.

This crash doesn't happen if I have only one display attached or I just start the screensaver preview. In this cases it is also faster and doesn't lag.

I guess I shall open a new bugreport for the latter.

Czigola, weird, it seems like you are experiencing essentially the opposite of other 965 users. I wonder if your PM965 card is architecturally distinct from the others, for which XAA does not work but EXA does. I think we should handle your issue as a unique new bug - can you please open a new bug for PM965 with EXA and greedy, with your comment #49? Also please attach your /var/log/Xorg.0.log (which may have useful warnings or other info), and the output of lspci -vvnn (which will show your exact VGA subsystem pci id's, which we may need to quirk your card). Please also reference this bug id#.

done, https://bugs.launchpad.net/ubuntu/+bug/193958

As I said, EXA works as good as XAA for me.

More testing revealed, that under the given circumstances and also with EXA, the kernel hangs, but "only" 80% of the time.

$ sudo lspci -vvnn
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
        Subsystem: Lenovo Unknown device [17aa:20b3]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Unknown device [17aa:20b5]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at f8100000 (64-bit, non-prefetchable) [size=1M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 1800 [size=8]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
                Bridge: PM- B3+

00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)
        Subsystem: Lenovo Unknown device [17aa:20b5]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at f8200000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: [d0] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
                Bridge: PM- B3+

I attach Xorg's log, running with EXA.

I thought it was enabled on all intel chipsets now, guess I mis-understood. Anyway, enabling greedy on "00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" makes kde 4 3d acceleration work as good as XAA, enabling backing store and INTEL_BATCH makes it even better.

+1 here on a 945GM intel graphic card: stock xorg.conf on alpha4 was making compiz very choppy. Adding the 3 suggested flags in xorg.conf (Option "AccelMethod" "EXA", Option "ExaNoComposite" "false", Option "MigrationHeuristic" "greedy"), plus setting INTEL_BATCH=1 makes everything smooth again, and XV is still working fine.

I have intel 965
What exactly are the things I should put in xorg.conf to test out to make it faster?
I see in this thread different names and stuff, but I'm not sure exactly where, or exact phrasing when inputting it into xorg.conf.

If someone can copy/paste these settings they have in xorg.conf, I'd much appreciate it.

The updated xserver-xorg-video-intel is out on the update servers.
"Version 2:2.2.0.90-2ubuntu7:

  * Drop the xaa-patch, as it turns out that not only i965 has issues
    with Xv & compiz.
  * Bump the build-dep on xserver-xorg-dev to match the current version
    that is needed in order to default to greedy EXA."

will try to revert back to the default hardy xorg.conf and upgrade.

sorry for the flood.

Well, obviously, I didn't read clearly into the intentions of Timo and Bryce.
With the last xserver-xorg-video-intel (2:2.2.0.90-2ubuntu7), and the stock hardy xorg.conf, my compiz is choppy again.

I reverted to (Option "AccelMethod" "EXA", Option "ExaNoComposite" "false", Option "MigrationHeuristic" "greedy"), and all is back to normal.

I thought from the changelog that you were going to include these default flags for the intel chipsets. ?. (I'm with a 945GM)

I have ASUS Z99Le (based on i965)

I've set the xorg.conf to follow settings:

Section "Device"
 Identifier "Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller"
 Driver "intel"
 BusID "PCI:0:2:0"
 Option "AccelMethod" "exa"
 Option "MigrationHeuristic" "greedy"
 Option "ExaNoComposite" "false"
EndSection

But with this settings system doesn't start at all.

@Francois Rigaut
I guess the developers have enabled EXA again but haven't activated greedy for all Intel cards.

@Ratz
I guess that the BusID is wrong for your hardware. Afaik only the MigrationHeuristic should be added.

My intel G31* card works best with MigrationHeuristic="greedy". It's stable (i've tested openarena in various resolutions and hibernation), it has acceptable performence (scrolling in ff works absolutely smoothly) and Xv works.

With default MigrationHeuristic i've got serious performence problems. If I use XAA, Xv doesn't work.

*00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)

Reopening it since the XAA patch was removed but greedy doesn't seem to be the default migration heuristic for all non i965 chipsets.
Btw. switching to Greedy might also fix Bug #188178.

I haven't noticed any new hangs on MacBook-2nd I945GM since the latest driver release xserver-xorg-video-intel.
I'm testing 3D resources with PlanetPenguinRacer and it does great.
When the game starts looks like Compiz still interferes on it. At the end of the game the driver redraw desktop area with bottom panel in the wrong position of the working space but with recovers fast refreshing display to its correct position.
Running GoogleEarth the renderatization process is not so smooth as could be like with open driver in a better video card for instance ATI :)

Removing INTEL BATCH from /etc/environment have observed no significant differences when playing 3D games (OpenArena/PenguinRacer).
The video behavior symptoms of starting/ending games still remain, i.e. small flickerings at the bottom of screen and gnome-panel in wrong local display at the game over.

MigrationHeuristic="greedy" works for my intel laptop but not for my ATI desktop.

INTEL_BATCH=1 seems to have a significant effect even with higher 3D application. OpenArena DRI benchmark was 1/3 faster with this option.
I have created a wish list report for enabling this option under Bug #195843.
It would be great if many user, especially the Hardy ones, could recheck it.

Is there a reason why greedy isn't enabled for all Intel cards with the new driver release? I think that it is very important that many people test this configuration before release and XAA doesn't seem to be an option anymore.

I have to admit that with INTEL_BATCH=1 enabled makes video card improve 1/3 in performance as showed the results in #195843.
I didn't realized that until benchmark comparison because my video card runs pretty well 3D games.

Here is a proposed -2ubuntu8 package and deb which expands "greedy" to all intel chipsets:

  http://people.ubuntu.com/~bryce/Uploads/

I'm a bit worried that this might cause regressions. However, due to the number of people reporting it works, and the relatively small number of reports of issues, it might be okay.

Inclusion or not of INTEL_BATCH=1 will be followed in bug #195843. I checked with upstream and they advise against using it by default.

It looks like patch doesn't force greedy heurestics in 2.2.1 (no info in Xorg.0.log). I've glanced at code and probably neither EXA_MIGRATION_GREEDY nor I830_USE_EXA is defined. Or maybe, I've just screwed up compilation for amd64 ;-)

With Hardy alpha5 :
On my laptop (i915GM) it seems that MigrationHeuristic="greedy" is not enabled by default.

i changed xorg.conf to put the lines
Option "MigrationHeuristic" "greedy"
Option "ExaNoComposite" "false"

and the results (glxgears fps) were the same as before : no performance increase.

i also have the same performance with xaa instead of exa

(i got a +33% boost in performance with the INTEL_BATCH thing)

Xserver-xorg-video-intel 2:2.2.1-1ubuntu3 doesn't seem to activate greedy for me.
VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

This bug was fixed in the package xserver-xorg-video-intel - 2:2.2.1-1ubuntu3

---------------
xserver-xorg-video-intel (2:2.2.1-1ubuntu3) hardy; urgency=low

  * Add 07_intel_exa_force_all_greedy.patch, to expand the fix from
    05_intel_exa_force_greedy.patch to cover all Intel chipsets, not just
    965. (LP: #177492)
  * Drop 05_intel_exa_force_greedy.patch, since 07 is a superset of it.
  * Add 08_945gm_quirk.diff, to add quirk for another laptop model with a
    tv out detection bug. (LP: #152416)

 -- Bryce Harrington <email address hidden> Fri, 29 Feb 2008 15:52:16 -0800

I just upgraded to this version. Then I regenerated my xorg.conf with dpkg, and reboot. So I don't have any option.
Hopelessly scrolling using firefox is slow.

Like the proposed patch the updated driver still doesn't activate Greedy for my i915 graphic card without the xorg.conf line.

xserver-xorg-video-intel:
  Installed: 2:2.2.1-1ubuntu3
  Candidate: 2:2.2.1-1ubuntu3

VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

This bug was fixed in the package xserver-xorg-video-intel - 2:2.2.1-1ubuntu4

---------------
xserver-xorg-video-intel (2:2.2.1-1ubuntu4) hardy; urgency=low

  * Revert the greedy change, use the old patch again since the new one
    doesn't work right. (LP: #177492)
  * Add patches to enable hardware overlay for i965, and disable textured
    video by default. It can be enabled again by setting
    'Option "TexturedVideo" "true"'. (LP: #152206)

 -- Timo Aaltonen <email address hidden> Tue, 11 Mar 2008 21:42:43 +0200

allright, I'm lost.
I just upgraded to xserver-xorg-video-intel - 2:2.2.1-1ubuntu4 (latest updates), did a sudo dpkg-reconfigure -phigh xserver-xorg, rebooted for good measure, and still the same issue with super slow compiz/firefox scrolling.
I'm with a 945 on a thinkpad T60 (relevant section of lspci attached).

I understood that this patch was also addressing this chipset, and adding greedy (and turning off ExaNoComposite), but it is apparently not the case.

Right, sorry that I forgot the other chips. Now the package only works for i965 just as before, the new one doesn't work yet.

I'll re-look at the patch after beta. It's probably a silly typo or inverted logic or something.

I'm dropping the priority down to High since the issues on non-965 chips aren't nearly as severe as they were on 965.

Not sure it's related, but I noticed that Firefox had suddenly slowed down. I checked xorg.conf and found that the 'greedy' heuristic and the other settings had somehow moved from the Device section to the Monitor section. This may have been caused by using one of the screen resolution GUIs however. Using the 965 chipset.

On 965 this bug seems resolved for me. Accel method is EXA and MigrationHeuristic is greedy by default. Scolling is smooth.
(The only remainin problem is, that xv is not working if compiz is enabled, see bug #201596)

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Using

        Option "AccelMethod" "EXA"
        Option "ExaNoComposite" "false"
        Option "MigrationHeuristic" "greedy"

has fixed current Hardy for me. No longer is it balls-achingly slow. Firefox now scrolls extremely fast and smoothly.

Confirmed as well...much better performance. Toshiba Satellite A105-S4134.

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Same chipset as Zakalwe . Of note, running glxgears and moving the window gives bug similar too https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/116793 . I realize this is ongoing issue, but thought I would mention it for my chipset.

I've been having these problems too.

The following configuration has improved my performance:

        Option "AccelMethod" "EXA"
        Option "ExaNoComposite" "false"
        Option "MigrationHeuristic" "greedy"

I also tried the XAA method would made scrolling faster but I could not get video playback.

My video card is:
(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GM
(--) intel(0): Chipset: "945GM"

I have a Toshiba Satellite A105-4014

Alright guys, here is a new cut of the greedy-for-all patch, this time done as a slight modification of the greedy-for-965 patch. Please install and test. It should bring the performance benefits that 965 users are reporting to everyone that has EXA enabled, without need for xorg.conf configuration settings.

http://people.ubuntu.com/~bryce/Uploads/xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb
http://people.ubuntu.com/~bryce/Uploads/xserver-xorg-video-intel-dbg_2.2.1-1ubuntu6_i386.deb

* installed xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb
* reconfigured xorg.conf (dpkg-reconfigure -phigh xserver-xorg)
* rebooted for good measure
It works (compiz nice and smooth, firefox scrolling fast).
Thanks.

whoops. forgot to mention. As said in a previous post, I have a 945 (my lspci is attached somewhere above).

It works for me too. I just install the package, comment the greedy option, restart gdm and all works great. Thanks !

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb works for me as well.

mplayer with xv works but I get the blue screen when I move the window or rotate the cube.
mplayer with x11 works, and keeps working when a move the window or rotate the cube (I can see it even from "behind" the cube)...
¿why do I need xv?

Alfonso: x11 does a software scaling of the video, xv does it in hardware. Try an high resolution movie under heavy system load. If it works with x11, you can definitely use it and forget about xv, if it's not smooth, probably xv will be smooth instead.

xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb works nicely with 915 after sudo dpkg-reconfigure -phigh xserver-xorg, INTEL_BATCH="1", and reboot.

but I did not test xv.

$ lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller [8086:2582] (rev 04)

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/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Toshiba Satellite A105-S4134

All is fine on my end so far. BTW, no /etc/environment mod on my end...I can't tell much of a difference.

I installed the package and then did dpkg-reconfigure of xserver-xorg. Noticed immediate improvement. No INTEL_BATCH necessary.
I'm running a 2nd gen Apple MacBook with intel 945 graphics:
 $ lspci | grep -i graphics
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/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Removed INTEL_BATCH="1" from /etc/environment and finally had a chance to test XVideo extension video output in VLC on 915 and all seems well and fine here with xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb

$ lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller [8086:2582] (rev 04)

Hi,
I am testing the patched xserver-xorg-video-intel_2.2.1-1ubuntu6_i386.deb and it works well keeping the INTEL_BATCH="1" in /etc/environment.
If I try to disable it, I get corrupted video memory and eventually after some time a total crash of the system.

I am using a Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Perhaps this should be filed in another bug report: xrandr now reports a maximum resolution of the widest-dimension squared, rather than the proper one of 2048x2048 (on the 945).

i.e. If my normal resolution is: 1440x900, as it is, then xrandr reports 1440x1440 as the maximum resolution. This is a regression from earlier versions of the driver.

I have similar problem as Alfonso Eusebio wrote on 2008-03-19
Now when I movie video player (VLC) or anything related to compiz, the video player screen goes blue.

This happened a couple days ago.
What is this xv vs x11? Where are these options to change? I don't see it in xorg.conf I have intel 965 x3000

Ok I found the option in VLC media player output section. preferences->video->output modules->make sure advanced setting is enabled.
Using X11 instead of the XV(blue screen), X11 is actually working better than before. I can put video at full screen with no slowdown (same videos as tested before, and these were just crappy youtube videos).
Tested with large movies and other video files and it works near perfect! So something changed over the past few days that reverted video to XV, and changing back to X11 made videos work better than before? Before if I went fullscreen or enlarged video size the video would go all choppy with a couple frames per second. Nice to see this is fixed!

I do confirm the INTEL_BATCH="1" works well; boosting me from 900->1200fps. Good work!
However the:
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Do NOT work when I add them to the bottom of my xorg.conf.
I am on an intel 945GM with the i810 driver.

Strangly, with the mplayer xv/x11 thing, I have less CPU usage and my A-V is closer to 0 (going at -0.002-0.002) when I have some compiz effect going like the desktop wall thing in the center of your screen up. The -xv option uses a lot less cpu, as it should but I still dont like it.

8.04 Beta.

Hi Bryce,
good work, I can confirm that 1ubuntu6 recompiled for amd64 works fine (smooth scrolling in firefox, hibernation works and XV as well; all with clean xorg.conf, of course). Please, don't hasitate to release. Afterall, it's still beta.

Thanks everyone for verifying it. We were holding off until after -beta was out, so it can be uploaded at any time now, and should be up within the week.

This bug was fixed in the package xserver-xorg-video-intel - 2:2.2.1-1ubuntu6

---------------
xserver-xorg-video-intel (2:2.2.1-1ubuntu6) hardy; urgency=low

  [ Bryce Harrington ]
  * debian/patches/05_intel_exa_force_greedy.patch: Another shot at the
    greedy patch. This time by slightly modifying the working patch by
    moving its logic outside the i965 if loop, so it'll apply to all
    hardware. (LP: #177492)

  [ Timo Aaltonen ]
  * Don't conflict with 915resolution, since it breaks upgrades where
    people are still using i810 with widescreen resolutions.
    (LP: #206167)

 -- Timo Aaltonen <email address hidden> Tue, 25 Mar 2008 11:25:42 +0200

I dist-upgraded today and I saw this changelog but, after a reboot, I don't see any improvement. Seems that it doesn't work for me.

@Lionel Dricot
What exactly does not work good for you?
Video playback (framerates/fullscreen)? compiz slow?
What are your video card/computer specs?
What is your video driver? Post your xorg.conf
Have you also done the INTEL_BATCH="1" in /etc/environment ?

I didn't add INTEL_BATCH="1" in /etc/environment. I will try with it. But will it be automatically added for people upgrading from gutsy ?

I don't know. I hope so. As well with all the other stuff mentioned on this page. I don't want to format/install ubuntu again and have to type in all that stuff everytime.
If the environment thing does not work (reboot first), please answer my other questions.

Indeed, adding the INTEL_BATCH="1" was enough to solve most of my problem. Performances are not perfect but I'm more or less at the Gutsy level.

mm, the solution is not perfect because now, without using Compiz, I have strange screen corruption in Xmoto (the game)

INTEL_BATCH="1" will not be added by default for reasons on Bug #195843

I believe the current setup is by default AccelMethod set to EXA with MigrationHeuristic greedy for all intel chipsets.

Then again I could be reading this wrong or there are problems actually implementing the patch because i needed to add to the configured video device section of my xorg.conf the three options from above "AccelMethod""exa", "MigrationHeuristic""greedy", and "ExaNoComposite""false" in order to enable compiz.

Here is my video xorg.conf which has compiz working great. I also have INTEL_BATCH="1"
Section "device" #
 Identifier "device1"
 Boardname "Intel 965"
 Busid "PCI:0:2:0"
 Driver "intel"
 Screen 0
 Vendorname "Intel"
  Option "MigrationHeuristic" "greedy"
 Option "AccelMethod" "exa"
 Option "ExaNoComposite" "true"
EndSection

Oddly I thought my exanocomposite was set to false, but maybe it changed with an update? That was from a month ago I used false.

On 965 using 2:2.2.1-1ubuntu6 everything works fine now by default:

- compiz works
- EXA is used ( newer rendering architecture )
- migration heuristic is greedy ( => smooth scolling )
- overlay video is used instead of texture video ( xv works with compiz )

855GM.

This is not fixed for me. The option increases the usability by a large factor leading me to believe that it is NOT "fixed" if I still have to enter it manually to get firefox to scroll without crawling...

A day or two ago compiz became slow again for me. Playing any video fullscreen results in a couple frames per second. Doing anything compiz related with a video running results in low frames per second. This happened before I updated to newest kernel.
I added 2gb more of ram (now 3gb) and same problem.
I hope this gets fixed, or if there is a way to revert back a week to when it was working for me.
intelpatch=1 is still in environment (I'll try removing it since it is not recommended), and my xorg is the same as before.
Also with compiz running slow again it makes firefox run slow (scrolling, looking through bookmarks etc). So basically with compiz running the entire OS is a bit slower. But for whatever reason a week ago it ran perfectly fine. I could have a couple videos at fullscreen with not much slowdown (20fps).

Anyone else notice a slowdown over the past couple days?

I have 915GM in Dell Laptop PentiumM 512RAM

With Xorg.conf changes from post #12 above and xserver-xorg from Hardy repository:

Plant Penguin Racer = 35-40 fps
glxgears= 1450+
Firefox3 no problems

I am still trying to get ProjectM visualization to work in Amarok at above 2 fps. Works great on my desktop with nvidia fx5200 (35 fps) with no tweaking .projectM/config.inp (changing config.inp on laptop didnt help)

Can someone with 915GM try ProjectM (in Hardy repositories) and tell me if fps is acceptable on their hardware? I am thinking their is something missing in intel driver OpenGL code that ProjectM needs to run properly.

I have copied the output from xorg.0.conf dealing with drm, etc below
Not sure the significance of Bad V_BIOS checksum and "setting screen physical size to 331 X 207" (my resolution is 1680X1050)

thanks
Dixon

I have 945GM and projectM went at around 3 FPS; the other visualizations work fine.

HTH

I am still experiencing this problem.

I run a Dell Latitude D610, with the 915GM graphics card.
Hardy Beta with patches up to date (Apr16), including xserver-xorg-video-intel 2:2.2.1-1ubuntu12
I have the INTEL_BATCH=1 variable in /etc/environment
xorg.conf is as clean as after running sudo dpkg-reconfigure -phigh xserver-xorg

this configuration has been reported to work up in the trail at least with version 6 of intel driver.... maybe got broken later?.

Anyhow, another comment is that I am running the laptop using a docking extension and an external monitor. this has not been commented before in the trail. and maybe could be a direction to investigate.

I have had many problems today trying to have the laptop screen or the external monitor to work, so I will not mess up diagnostics with those problems (did not get right resolution or vesa driver was loaded)....

advice will be welcomed...
thanks

Regarding problems with intel video cards and vga out, I can point out bug #137234

"On 965 using 2:2.2.1-1ubuntu6 everything works fine now by default" - Gabor CZIGOLA. I just ordered a laptop with the 965, and want to confirm that other people agree with Gabor.

Is 965 working now? And if so, with what CPU utilization on regular 2D, Compiz/Xv, Google Earth use, and so on? Will Hardy be commited with EXA or not?

jhwilliams: on my 965, EXA is on by default with the greedy tweak, video uses XV with comparable CPU use to prior ubuntu versions. Everything works as well or better than it did in gutsy, as far as I can tell.

to those having trouble with dual monitors: I'd like to point out that the 'Screen Resolution' (in System->Preferences) tool in hardy actually does a decent job of managing dual screens on xrandr1.2-compliant drivers like intel, though to get extended mode you still need to add a 'Virtual' line in xorg.conf.

@ jhwilliams
It works for me. But there is still a bug for me when using compiz that causes Xorg CPU to go to 80%. Even scrolling ubuntu forums or anywheres causes cpu to go high which makes compiz unusable for me (full screen video is bad as well).
But not many people are posting this problem, so maybe it is only a few people that are still experiencing this. It worked fine for me with the beta (then one day decided to stop working perfectly, see my previous posts), so I'm going to have to install it again maybe and see if it is working there. I'm also going to have to try and format/install the RC first to see if it fixes this problem and also the problem with ubuntu not recognizing my LG 204wt monitor (it is not listed anywheres in screen/graphics).

Hi,

I'm also experiencing similar issue on my Intel D945GNTL motherboard based desktop. I'm running xserver-xorg-video-intel 2:2.2.1-1ubuntu12. I've tried all workarounds mentioned above adding options "MigrationHeuristics" = "greedy", "AccelMethod" = "EXA", "ExaNoComposite" = (both "false" and "true"), but no visible change in performance.

00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)

Attached is the video I recorded using recordmydesktop, to demonstrate flickering happening in xterm during resizing. I'm running Ubuntu Hardy (AMD64) on 1440x900 display resolution.

TIA
Ashish Shukla

I think it can be safely said that any further slowdowns of video playback while compiz (or perhaps another compositive manager which uses indirect glx) is running, are because of the fact that the video frames are being transferred over aiglx as textures. Unless the kernel supports something like TTM to accelerate this, video playback will continue to stutter. When using a non-compositing window manager (metacity with compositing off), video playback is perfectly fine.

So perhaps this bug depends on support of ttm in the kernel.

Hi,

The status of this bug is "Fix Released". Can anyone point me to the
fix. I'm not able to find it. I'm running Ubuntu Hardy (amd64) ?

TIA
--
Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --

I have the same Firefox scrolling issue here on a PC freshly upgraded to Hardy. The video card is ATI with fglrx drivers.

Lionel, this thread is only related to the intel driver which is used with the graphics cards listed at http://intellinuxgraphics.org/documentation.html. I'd run lspci -a, find out the model of your ATI card, and then do a google search for it and hardy.

the fix(add 3 options to xorg.conf and INTEL_... to environment) worked for me ubuntu hardy heron 8.04 LTS, intel card 945GM, toshiba satellite a200

thank you

"I think it can be safely said that any further slowdowns of video playback while compiz (or perhaps another compositive manager which uses indirect glx) is running, are because of the fact that the video frames are being transferred over aiglx as textures. Unless the kernel supports something like TTM to accelerate this, video playback will continue to stutter. When using a non-compositing window manager (metacity with compositing off), video playback is perfectly fine.
So perhaps this bug depends on support of ttm in the kernel."

Can u explain better what u mean? Is the next kernel going to support this TTM module? The blue screen on compiz when using xv is quite annoying and i'd like to be able to enable video texturing as soos as possible...

No, it didn't work.

in the beggining everything looked ok, but after a while everytime i rotated cube in 3D my laptop crashed. always.

so i launched recovery-mode and let ubuntu setup the X by itself. The xorg.conf has changed to:
Section "Device", Identifier "Configured Video Device" EndSection. By now i can rotate cube as i did with 7.10 before upgrading.

Linux xxx 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

toshiba satellite a-200

i've found a fix that works for me: Bug#186058

Hopefully, Intrepid will include TTM.

On Wed, Apr 30, 2008 at 09:49:43AM -0000, Fabio Povoledo wrote:
>
> "I think it can be safely said that any further slowdowns of video playback while compiz (or perhaps another compositive manager which uses indirect glx) is running, are because of the fact that the video frames are being transferred over aiglx as textures. Unless the kernel supports something like TTM to accelerate this, video playback will continue to stutter. When using a non-compositing window manager (metacity with compositing off), video playback is perfectly fine.
> So perhaps this bug depends on support of ttm in the kernel."
>
> Can u explain better what u mean? Is the next kernel going to support
> this TTM module? The blue screen on compiz when using xv is quite
> annoying and i'd like to be able to enable video texturing as soos as
> possible...
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are the registrant for
> xf86-video-intel.
>
> Status in X.org xf86-video-intel: In Progress
> Status in Source Package "xserver-xorg-video-intel" in Ubuntu: Fix Released
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> The default acceleration mode in hardy, which I understand is EXA, is incredibly slow. The experience of running compiz with it is awful.
>
> Changing to XAA in the config file solves the issue, though then I obviously lose video.

Bryce,
Are you saying that there is little to no chance that TTM support (fedora 9 includes this?) will make it into an hardy, before intrepid is released?

Hi all,
throwing this in as the above suggestions haven't done anything to help my situation. Firefox performance using certain pages (gmail, slashdot comments) can safely still be called balls-achingly, if not balls-crunchingly, slow :(

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

Relevant bits of xorg.conf:

Section "Device"
 Identifier "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
 Driver "intel"
 Option "AccelMethod" "exa"
 Option "MigrationHeuristic" "greedy"
 Option "ExaNoComposite" "true"
EndSection

Section "Monitor"
 Identifier "Generic Monitor"
EndSection

Section "Screen"
 Identifier "Default Screen"
 Device "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
 Monitor "Generic Monitor"
 DefaultDepth 24
 SubSection "Display"
  Depth 24
  Modes "1280x800"
  Virtual 1280 1824
 EndSubSection
EndSection

/etc/environment includes INTEL_BATCH="1":
$ echo $INTEL_BATCH
1

Adding the INTEL_BATCH value increased glxgears from ~300fps to >600fps, but no improvement to firefox scrolling, which has stood still at under 1 fps on the two sites mentioned above. I've tried with accelmethod xaa, and with compiz turned on and off - generally the desktop has remained resonably responsive with any options I can throw at it, but firefox hasn't got any better.

Bryce,

Can I make a request re: 05_intel_exa_force_greedy.patch? Currently this patch forces the "greedy" heuristic which is currently the best option for many Intel cards (mine included). However, it effectively disables EXA acceleration for most cases, as far as I understand.

Wouldn't it be better to revise the patch so that the Intel driver's MigratonHeuristic *defaults* to "greedy" rather than forcesit? That way, if I want to test the "smart" or "always" heuristics to see if improvements are made in future versions of Xorg, I can specify them in my xorg.conf. That won't break user's setups and will make this patch more future-proof.

dsyates, that is correct. Also it looks like upstream will not be supporting TTM, but instead will focus on GEM. This is particularly evidenced by yesterday's libdrm release which also omitted TTM. So TTM looks like a dead end and we won't be pursuing it ourselves. Hopefully GEM will develop rapidly, however we don't anticipate it to be delivered in time for Intrepid. But we'll see.

Following up on my previous post - the "force greedy" patch was disabled in version 2:2.3.2-2ubuntu2 of the intel driver (although only because it was causing a segmentation fault). I hope this patch doesn't get re-introduced, as my Intel 855GM seems pretty snappy using the "always" MigrationHeuristic - even scrolling with compiz enabled seems faster now.

I would suggest that during the development cycle, the migration heuristic is left untouched, as it seems the new release of the Xorg server has improved EXA performance with the default migration heuristic. I have been following the Xorg mailing list, and Xorg 1.5 (including the release candidates) use the "ExaOptimizeMigration" parameter by default, which supposedly improves EXA's "always" heuristic to match "greedy" in some cases.

If it causes slow-downs for too many users, however, then the (fixed) patch can be re-introduced later.

This bug reappeared for me since the migration to the 2.6.27 kernel

The bug seems to be reappeared to me too in Intrepid 64bit up-to-date with intel x3100.

I've also recently noticed slowness on the x3100 in Intrepid

Odd, running intrepid livecd alpha 6 compiz seems to run faster than hardy (less CPU, can scroll in firefox without 90% CPU, it is only around 50-60% CPU and very responsive).
But I had similar experience when running hardy alphas. Compiz would work fine, then I would get an update causing massive CPU being used for xorg rendering compiz unusable and I havn't been able to get it working good since (until intrepid alphas).

Intel g965 x3000

I too have this problem in Intrepid, I'm using an Intel X3100 on a Dell Studio 15. My glxgears fps is around 600 and I can't run Google Earth properly. Should this bug be reopened?

I'm also seeing this on my x3100. I went from 1200 fps in glxgears with Hardy to 450 in Intrepid.

I can also confirm performance regression after upgrading from 8.04 to 8.10 Beta. glxgears shows 1100fps on Hardy and only 650fps on Intrepid. It looks like INTEL_BATCH is not supported in Intrepid. I'm using Acer Aspite One laptop with Intel 945GME GPU

I had this problem and tried to solve it with adding those three lines of Option to xorg.conf file. However, it did not solve my problem and I still had very slow scrolling and other performance issues.

I eventually decided to try the new version that is Intrepid so upgraded from 8.04 to 8.10 beta version, and now it works.
I don't seem to have the problem anymore.

I have given up
I am using a T60 with intrepid with a Intel 945 graphics card

Tried all the options EXA / XAA, intel_batch and nothing seems to improve the speed
running at 222fps using glxgears

Any suggestions ???????

Please help

I noticed slow in Intrepid too....... intel X3100

My laptop is lenovo with this vga card using intrepid beta (updated daily)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

tried INTEL_BATCH=1, and some xorg.conf config but no luck

glxgears with compiz on:
2412 frames in 5.0 seconds = 482.269 FPS

without compiz:
2785 frames in 5.0 seconds = 556.983 FPS
2862 frames in 5.0 seconds = 572.289 FPS

Someone requested me to share this link. Might be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=18128

Juan Carlos: thanks for the link! seems to have solved the issue for some, but i'm still getting much lower fps than I should be on my 945 (350 instead of 900). with compositing on its an abysmal 270... :( no stranger to getting direct rendering working so i've tried all the usual.. seems there is still a bug here

For those interested in the fix, try running "vblank_mode=0 glxgears -info" and if that improves your speed, follow the instructions in the above posters link

Actually scratch that, vblank_mode actually makes my performance worse by about 100fps, consistently with compositing both on or off... that's odd

I have also the performance problem in Intrepid with an Intel 865G using EXA, with XAA acceleration it is much more faster. Scrolling was not slow, but in Firefox, and in Dolphin tab switching was slow, also switching to another window was slow and I got graphics corruption (screenshot attached), all this with EXA.

Intrepid with EXA
x11perf -aa10text
560000 reps @ 0.0100 msec ( 99900.0/sec): Char in 80-char aa line (Charter 10)

Intrepid with XAA
x11perf -aa10text
560000 reps @ 0.0102 msec ( 49700.0/sec): Char in 80-char aa line (Charter 10)

With and GEM Kernel and Intel 2.5 would it be better?

The same loss of EXA performance compared to XAA on an Intel 865G I have also on OpenSUSE 11.0 with kernel 2.6.25.XX. There a quiet longstanding issue on that at freedesktop.org I reported:
http://bugs.freedesktop.org/show_bug.cgi?id=17605

Short summary:
- Don't mess with the MigrationHeuristic server option (message of Intel)
- Kernel 2.6.27 (at least on OpenSUSE 11.1 Beta2 LiveCD) solves the problem without a configuration change.
- Intel driver 2.5 doesn't solve the issue
- It is not clear to this time, why the EXA acceleration with Intel video drivers on a 865G work beginning with 2.6.27

I used Kubuntu and OpenSUSE as well and this is NOT a propagation of a certain distribution, but only for referring to my test environment, where occur the same problems as described.

But as you said, the problem still remains in Intrepid, which is already delivered with 2.6.27?
So take this as a hint only...

Curley: Thanks a lot for your input! I'm glad too see people starting to pay attentin again... But I'm afraid things are a bit more messed up.

MigrationHeuristic is the ONLY thing preventing my system on my 945gm from crawling when I use compositing (and i do a lot its part of my workflow so yes I do need it).

XAA is not useable at all with Intrepid because compositing is completely broken since I think early Betas.

Intrepid is already using 2.6.27. I'm also using a kernel I compiled myself from the latest sources available in the repositories...

I guess I have to try the OpenSuse disk and figure out what they did - have you run any benchmarks between opensuse and ubuntu? what does "glxgears -info" show? (yes I know its not an accurate measurement, but in this case it will do)

Apparently "MigrationHeuristic" shouldn't be changed anymore, at least for Intel users. One settings that may help performance is:

Option "ExaOptimizeMigration" "true"

See "man exa" for more details.

Yeah I understand the concept :) The point of the bug report is when its not working like its supposed to :)

Your suggestion provides a similar boost that greedy does minus some compositing elements going haywire so yay, but it's still not being configured properly by default. Your suggestion (and the older greedy) provide visible performance increases (at least on such low framerates as we're getting with the new configurations)...

But the real problem isn't even there, its here it seems https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/284082

@citizenofnowhere: Benchmarks you can find in the bug report at freedesktop.org, which I referred to. The glxgears I'll deliver later. Fortunately, the OpenSUSE's package maintainers are very actively tracking the problem together with Intel and issuing updates of drivers, Mesa and Xorg every couple of days in a special repository. I hope there will be a change soon.

curley: that's good to hear! i was starting to worry after trying the 2.5 driver version and libdrm version 2.4.1 and getting like 70fps.

fingers crossed that they come up with something soon!

Here are the diagnostic files for both cases, EXA and XAA on OpenSUSE 11.0, using XX.Org X Server 1.5.2, libdrm 2.4.1 and the latest Mesa 7.2 patches. Regardless of what these files say,
- the overall performance using EXA is still horribly slow on my 865G compared to XAA
- starting X server and switching to KDE after logon flickers in EXA mode and shows for about half a second (plus minus) an uninitialized video buffer)
- switching on KDE Desktop Effects (Composite) crashes the X server with a backtrace leading to libdrm (happens already for some months even in libdrm 2.3, for both XAA and EXE acceleration).
Not really useful at the moment.

On the other hand, what people recommended in this thread, and ignoring the recommendations of Intel developers, using MigrationHeuristic "greedy" leads to a broken systray, where are no icons visible, but only some kind of "colored trash".

I'm experiencing performance problems also with Sabayon, on a Intel Corporation 82G33/G31, with compiz (but also with ubuntu)...

for the moment the best performances seem to be with the

INTEL_BATCH=1

and this

Section "Device"
    Identifier "VESA"
    Driver "i810"
    #Option "RenderAccel" "on"
    #Option "XAANoOffscreenPixmaps"
    #Option "BusType" "PCI"
    #Option "ColorTiling" "on"
    #Option "EnablePageFlip" "on"
    #Option "AccelMethod" "XAA"
    Option "UseEvents" "True"
        Option "AccelMethod" "exa"
        Option "MigrationHeuristic" "greedy"
        Option "ExaNoComposite" "false"
        Option "ExaOptimizeMigration" "true"
EndSection

but the performance is not good enough yet...

in particular, when selecting log off in KDE the "darkening" effect is really slow...

has a solution been found for this problem yet?

I'm having the same problem in intrepid.
it has improved with Option "MigrationHeuristic" "greedy"
        Option "ExaNoComposite" "false"
        Option "ExaOptimizeMigration" "true"
intel batch has done nothing
thinkpad T60

Can any Ubuntu developer explain what does "Fix Released" mean?
Like others, in intrepid, I still need to add "MigrationHeuristic greedy" to fix EXA making everything slow when compiz is running. So what has been fixed?

Who are you, and why are you spamming me?

On Thu, Dec 11, 2008 at 7:28 PM, Elias K Gardner <email address hidden> wrote:

>
> I think you will like it.
>
> Please accept or reject this invitation by clicking below:
>
> http://www.bebo.com/in/8284883029a71428419b135
>
> ......................................................................
> Please do not reply directly to this email.
>
> This email was sent to you at the direct request of Elias K Gardner
> <email address hidden>. You have not been added to a mailing list.
>
> If you would prefer not to receive invitations from ANY Bebo members
> please click here - http://www.bebo.com/unsub/8284883029a71428419
>
> Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm not spamming you I'm getting the same shit myself.

On Thu, Dec 11, 2008 at 7:52 PM, Thom Pischke <email address hidden>wrote:

> Who are you, and why are you spamming me?
>
> On Thu, Dec 11, 2008 at 7:28 PM, Elias K Gardner <email address hidden>
> wrote:
>
> >
> > I think you will like it.
> >
> > Please accept or reject this invitation by clicking below:
> >
> > http://www.bebo.com/in/8284883029a71428419b135
> >
> > ......................................................................
> > Please do not reply directly to this email.
> >
> > This email was sent to you at the direct request of Elias K Gardner
> > <email address hidden>. You have not been added to a mailing list.
> >
> > If you would prefer not to receive invitations from ANY Bebo members
> > please click here - http://www.bebo.com/unsub/8284883029a71428419
> >
> > Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
> >
> > --
> > EXA is balls-achingly slow
> > https://bugs.launchpad.net/bugs/177492
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

The EXA Bug thread is not the time nor the place for self promotion.

On Thu, Dec 11, 2008 at 12:28 PM, Elias K Gardner <email address hidden> wrote:

>
> I think you will like it.
>
> Please accept or reject this invitation by clicking below:
>
> http://www.bebo.com/in/8284883029a71428419b135
>
> ......................................................................
> Please do not reply directly to this email.
>
> This email was sent to you at the direct request of Elias K Gardner
> <email address hidden>. You have not been added to a mailing list.
>
> If you would prefer not to receive invitations from ANY Bebo members
> please click here - http://www.bebo.com/unsub/8284883029a71428419
>
> Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org xf86-video-intel: Fix Released
> Status in "xserver-xorg-video-intel" source package in Ubuntu: Fix Released
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> The default acceleration mode in hardy, which I understand is EXA, is
> incredibly slow. The experience of running compiz with it is awful.
>
> Changing to XAA in the config file solves the issue, though then I
> obviously lose video.
>

I'm also getting the same spam from <email address hidden>!
We should open a bug in lauchpad!
It seems that all this email are sent to gmail accounts.
What are the doing with our email address? That is not privacy.

On Thu, Dec 11, 2008 at 9:08 AM, unimatrix <email address hidden> wrote:

> I'm not spamming you I'm getting the same shit myself.
>
>
> On Thu, Dec 11, 2008 at 7:52 PM, Thom Pischke <<email address hidden>
> >wrote:
>
> > Who are you, and why are you spamming me?
> >
> > On Thu, Dec 11, 2008 at 7:28 PM, Elias K Gardner <email address hidden>
> > wrote:
> >
> > >
> > > I think you will like it.
> > >
> > > Please accept or reject this invitation by clicking below:
> > >
> > > http://www.bebo.com/in/8284883029a71428419b135
> > >
> > > ......................................................................
> > > Please do not reply directly to this email.
> > >
> > > This email was sent to you at the direct request of Elias K Gardner
> > > <email address hidden>. You have not been added to a mailing list.
> > >
> > > If you would prefer not to receive invitations from ANY Bebo members
> > > please click here - http://www.bebo.com/unsub/8284883029a71428419
> > >
> > > Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
> > >
> > > --
> > > EXA is balls-achingly slow
> > > https://bugs.launchpad.net/bugs/177492
> > > You received this bug notification because you are a direct subscriber
> > > of the bug.
> > >
> >
> > --
> > EXA is balls-achingly slow
> > https://bugs.launchpad.net/bugs/177492
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Götz

I believe all of you have received an invite to bebo sent on my behalf. This
was a mistake.

This morning I joined the social networking site bebo which has recently
been bought by AOL Time Warner. They asked to search my email contacts for
people who already use bebo. I allowed this and selected three of my friends
who apparently currently have bebo accounts and clicked "add friends". Below
this button bebo had kindly listed and selected every email in my
addressbook which they promptly sent invites to without my knowledge.

Again I am deeply sorry.

I hope this is an appropriate way to attempt to correct the situation (I
realize it does mean getting two emails from me).

thanks for your understanding
elias k gardner

PS I am trying to contact bebo so that I may express to them how
*angry *(understatement
of my life) I am at being decieved like this. I have now spent the better
part of an hour copying the email addresses of who I believe bebo sent this
SPAM to and will doubtlessly never get my email address off of peoples spam
filters.

It actually looks like someone "Commented" on the EXA is balls achingly slow
bug with this spam.

On Thu, Dec 11, 2008 at 1:27 PM, G. Christ <email address hidden> wrote:

> I'm also getting the same spam from <email address hidden>!
> We should open a bug in lauchpad!
> It seems that all this email are sent to gmail accounts.
> What are the doing with our email address? That is not privacy.
>
>
> On Thu, Dec 11, 2008 at 9:08 AM, unimatrix <email address hidden> wrote:
>
> > I'm not spamming you I'm getting the same shit myself.
> >
> >
> > On Thu, Dec 11, 2008 at 7:52 PM, Thom Pischke <<email address hidden>
> > >wrote:
> >
> > > Who are you, and why are you spamming me?
> > >
> > > On Thu, Dec 11, 2008 at 7:28 PM, Elias K Gardner <email address hidden>
> > > wrote:
> > >
> > > >
> > > > I think you will like it.
> > > >
> > > > Please accept or reject this invitation by clicking below:
> > > >
> > > > http://www.bebo.com/in/8284883029a71428419b135
> > > >
> > > >
> ......................................................................
> > > > Please do not reply directly to this email.
> > > >
> > > > This email was sent to you at the direct request of Elias K Gardner
> > > > <email address hidden>. You have not been added to a mailing list.
> > > >
> > > > If you would prefer not to receive invitations from ANY Bebo members
> > > > please click here - http://www.bebo.com/unsub/8284883029a71428419
> > > >
> > > > Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
> > > >
> > > > --
> > > > EXA is balls-achingly slow
> > > > https://bugs.launchpad.net/bugs/177492
> > > > You received this bug notification because you are a direct
> subscriber
> > > > of the bug.
> > > >
> > >
> > > --
> > > EXA is balls-achingly slow
> > > https://bugs.launchpad.net/bugs/177492
> > > You received this bug notification because you are a direct subscriber
> > > of a duplicate bug.
> > >
> >
> > --
> > EXA is balls-achingly slow
> > https://bugs.launchpad.net/bugs/177492
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> Götz
>
> --
> EXA is balls-achingly slow
> https://bugs.launchpad.net/bugs/177492
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org xf86-video-intel: Fix Released
> Status in "xserver-xorg-video-intel" source package in Ubuntu: Fix Released
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> The default acceleration mode in hardy, which I understand is EXA, is
> incredibly slow. The experience of running compiz with it is awful.
>
> Changing to XAA in the config file solves the issue, though then I
> obviously lose video.
>

Alan Tam wrote:
> Can any Ubuntu developer explain what does "Fix Released" mean?

I am not an Ubuntu developer but Fix Released means that the appropriate
fix for the bug has been released as part of the latest (usually
development) version of the package in question.

Shriramana Sharma.

Why is #193318 a dupe of this one? They are not related. #193318 concerns all video cards while this one is ATI-specific. Doesn't anyone moderate the dupes? How do you remove a dupe?

Why is the driver not fixed for the respective chipsets ?

I had to use the Option "MigrationHeuristic" "greedy" in Jaunty to get reasonable performance on the intel GM45

Just to confirm that:

        Option "AccelMethod" "EXA"
        Option "ExaNoComposite" "false"
 Option "MigrationHeuristic" "greedy"

did the trick for me on Fujitsu-Siemens and i945 chipset.

Athough, I tried only

 Option "MigrationHeuristic" "greedy"

and it also worked.

Cheers,
juky