X.org xf86-video-intel

INTEL_BATCH=1 should be enabled per default for Intel graphic hardware

Reported by unggnu on 2008-02-26
24
Affects Status Importance Assigned to Milestone
xf86-video-intel
Invalid
Undecided
Unassigned
xserver-xorg-video-intel (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

In the course of Bug #177492 I was experimenting a little bit with the option INTEL_BATCH=1 which makes glxgears significant faster but according to some posts only this one and not higher 3d applications. For getting better results I have installed OpenArena (a game with Quake 3 engine) and used the Benchmark Howto from http://dri.freedesktop.org/wiki/Benchmarking for OA. The result was amazing. It was 1/3 faster with INTEL_BATCH=1 then without.
According to Bryce Harrington a new wish list report should be created if this option has an effect on real 3d apps which is the case at least for me.
INTEL_BATCH=1 should be enabled per default for Intel hardware if many people experiences the same and there are no regressions.

It would be great if many other with Intel graphic cards could recheck this with the same procedure.
After adding, removing or commenting out INTEL_BATCH=1 from /etc/environment only a logout is needed since GDM is restarted per default since Gutsy and the file environment seems to be reread after X restart. This option seems to also work in Gutsy so there is no need for an upgrade/installation but of course the latest Intel driver is only in Hardy.

My platform is a Sony TX2 Laptop with Intel 915 chipset, 1.5 GB memory and 1.2 GHZ Pentium M ULV processor.
Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)

I am using a fresh Hardy Alpha 5 installation with all current updates. I have changed nothing except adding the line >>Option "MigrationHeuristic" "greedy" << to xorg.conf device section to fix the EXA bug #177492 which hopefully is activated by default in Hardy in the future and of course adding/removing INTEL_BATCH=1 to /etc/environment. Compiz was activated on every test like in the default configuration. I have ran the command in standard gnome console.

Results without INTEL_BATCH=1 and glxgears:
3543 frames in 5.0 seconds = 708.474 FPS
3588 frames in 5.0 seconds = 717.553 FPS
3556 frames in 5.0 seconds = 711.136 FPS

Results without INTEL_BATCH=1 and OpenArena DRI Benchmark:
840 frames, 27.6 seconds: 30.4 fps
840 frames, 27.5 seconds: 30.6 fps

Results with INTEL_BATCH=1 and glxgears:
4073 frames in 5.0 seconds = 814.452 FPS
4298 frames in 5.0 seconds = 859.514 FPS
4368 frames in 5.0 seconds = 873.452 FPS

Results with INTEL_BATCH=1 and OpenArena DRI Benchmark:
840 frames, 20.3 seconds: 41.5 fps
840 frames, 20.0 seconds: 41.9 fps

mabovo (mabovo) wrote :

The latest xorg-xserver-intel driver released today, my MAcBook 2nd Duo T7400@2.16 GHz with Intel I945GM with INTEL_BATCH=1 glxgears results in
8411 frames in 5.0 seconds = 1682.175 FPS
8418 frames in 5.0 seconds = 1683.559 FPS
8402 frames in 5.0 seconds = 1680.286 FPS
8421 frames in 5.0 seconds = 1684.066 FPS
8412 frames in 5.0 seconds = 1682.298 FPS

unggnu (unggnu) wrote :

It only helps if you show your results with INTEL_BATCH in contrast to without it. Since glxgears isn't such a great benchmark I would appreciate it if you could run the OpenArena benchmark.
Btw. the Howto seems to only work with Hardy

OpenArena benchmark installation:

sudo apt-get install openarena
mkdir -p ~/.openarena/baseoa/demos
wget -O ~/.openarena/baseoa/anholt.cfg http://people.freedesktop.org/~anholt/benchmarking/anholt.cfg
wget -O ~/.openarena/baseoa/demos/anholt.dm_68 http://people.freedesktop.org/~anholt/benchmarking/anholt.dm_68

OpenArena benchmark start:

openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'

mabovo (mabovo) wrote :

My result with INTEL_BATCH=1

mabovo@macbook:~$ openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
840 frames, 9.1 seconds: 92.2 fps
mabovo@macbook:~$

mabovo (mabovo) wrote :

My result without INTEL_BATCH=1

mabovo@macbook:~$ openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
840 frames, 14.0 seconds: 59.9 fps
mabovo@macbook:~$

unggnu (unggnu) wrote :

Thank you for testing. 50% faster is really impressive.

mabovo (mabovo) wrote :

Some few more updates in xorg and I tested again with INTEL_BATCH=1 gave
mabovo@macbook:~$ openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
840 frames, 8.9 seconds: 94.1 fps
mabovo@macbook:~$

Bryce Harrington (bryce) on 2008-02-27
Changed in xserver-xorg-video-intel:
importance: Undecided → Wishlist
status: New → Confirmed
Bryce Harrington (bryce) wrote :

Since it seemed curious that upstream would not just make this parameter the default, I inquired as to possible side effects or hidden bugs that this parameter might trigger. Here is Eric Anholt's response, via Rolla:

"I seem to recall that there were some issues with cliprect handling with
INTEL_BATCH or something, and I may have had concerns with
synchronization with it. I remember that quick inspection said that
leaving it disabled was the right thing to do.

It's irrelevant now anyway, as that path is replaced in TTM mode, and
we're doing the equivalent code even in non-TTM.

Not dumping all of your commands into the ring saves a copy and allows
greater concurrency, leading to performance improvements.

Of course, we also expose other bugs (poorly implemented hang-detection
timeouts) by allowing greater concurrency, and that's among the stuff
we're working on fixing in master.

So, setting INTEL_BATCH now in old mesa would probably be a bad idea for
that reason alone, ignoring the other reasons I seem to remember with
that specific implementation of the batch buffer idea."

So, it sounds like there may be corner cases where this setting would bring instabilities. I'm not sure it's worth taking that risk for Hardy. But I'll leave this bug open in case folks wish to research it more thoroughly.

What I'd like to hear is if people try out this setting and it causes a bug. We don't need more confirmation of the performance effects.

unggnu (unggnu) on 2008-02-27
description: updated
unggnu (unggnu) wrote :

Thanks for pointing it out. I guess you are right that it is the best to not activate INTEL_BATCH by default for Hardy since it is very easy to activate it manually, the release is LTS and default config is fast enough for normal usage, at least with greedy.

mabovo (mabovo) wrote :

For my convenience I will let it enabled and just in case of instabilities will post comments here.
Thanks Bryce / unggnu.

Vincenzo Ciancia (vincenzo-ml) wrote :

If INTEL_BATCH enables greater concurrency, bugs can be really difficult to be traced. We will probably never have a deadlock in 99% of cases, but some unlucky guy with a specific configuration, or us in 1% cases, will experience deadlocks under compiz, without being able to tell if this was compiz or INTEL_BATCH fault. Replicating the conditions of concurrency problems is a difficult problem.

For example, compiz sometimes hangs, if for some reason the animation lasts too long (e.g. if I use the shift switcher plugin under heavy CPU load). This is not due to INTEL_BATCH (I had this problem before) but seems a symptom of a concurrency problem. So, even if I am currently happy with INTEL_BATCH, and was among those who asked to make it default, I am happy that it is left off for Hardy, and until upstream enables it.

pierrestz (coolos) wrote :

I tried the INTEL_BATCH=1 on my laptop (i915GM, pentium-M 1000MHz ULV) and it improves my performance.
I have the same measures with EXA or XAA for acceleration.

glxgears :
+33% (655fps->871fps)

openarena benchmark :
+32% in 640x480 (22.8fps->30.2fps)
+18% in 1024x768 (14.9fps->17.6fps)

Francois Thirioux (ft73) wrote :

OK for the FPS increase, but see how Sauerbraten looks after intel_batch=1, there are bugs in ammo and health amount display.

Siegfried Gevatter (rainct) wrote :

I can also confirm the performance improvement (up to 3x more FPS).

Don't activate INTEL_BATCH by default.

There are problems with planetpenguin-racer. The screensaver "ant-spotlight" crashes (often) with INTEL_BATCH switched on.

Lionel Dricot (ploum) wrote :

Well, For me, running without INTEL_BATCH is not an option. Running a straight Hardy Beta gives me bug #206049

Adding INTEL_BATCH=1 was the solution.

INTEL_BATCH might cause some glitches but if it solves a total unusable system, it worth trying it.

Bryce Harrington (bryce) wrote :

For Intrepid we're going to be getting the nice TTM enabled stuff, with the properly implemented batch buffer equivalent. This INTEL_BATCH=1 is really experimental code and not suitable for a release, especially not an LTS. So I'm going to close this as a WONTFIX. We'll be getting the fully baked version in Intrepid.

Of course, users are more than welcome to turn this on locally for the speed benefits, but the Ubuntu Xorg team will NOT be supporting such configurations - so if you have instabilities or other issues while using INTEL_BATCH=1, please turn it off and reproduce the issue without it, before reporting a bug.

Changed in xserver-xorg-video-intel:
status: Confirmed → Won't Fix

Bryce,

what about closing this bug as INTEL_BATCH=1 is no more supported?

cheers,

Bryce Harrington (bryce) wrote :

Right; closing.

Changed in xserver-xorg-video-intel:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments