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

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

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'

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:~$

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:~$

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

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:~$

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.

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.

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

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.

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)

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

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.

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.

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.

Bryce,

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

cheers,

Right; closing.