Hm, I've discovered some drm messages:

Mar  3 02:47:38 localhost kernel: [    0.000000] Kernel command line: root=/dev/sda2 ro reboot=warm noexec=off vga=0x314 drm.debug=0x06
Mar  3 02:47:38 localhost kernel: [   13.685785] [drm] Initialized drm 1.1.0 20060810
Mar  3 02:47:38 localhost kernel: [   13.754462] [drm] MTRR allocation failed.  Graphics performance may suffer.
Mar  3 02:47:38 localhost kernel: [   13.754565] [drm] set up 127M of stolen space
Mar  3 02:47:38 localhost kernel: [   14.135180] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
Mar  3 02:47:38 localhost kernel: [   14.461449] fb0: inteldrmfb frame buffer device
Mar  3 02:47:38 localhost kernel: [   14.461482] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Mar  3 02:47:41 localhost kernel: [   20.803413] [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object
Mar  3 05:23:24 localhost kernel: [ 9359.280471] [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object

A relevant kernel bug is filed here http://bugzilla.kernel.org/show_bug.cgi?id=15431

I have eliminated the MTTR error message by adding these options to my kernel configuration:

CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

However OpenGL performance is still unsatisfactory (probably up to 3-5 times slower than in Windows XP SP3):

[birdie@localhost ~]$ glxgears
4044 frames in 5.0 seconds = 808.746 FPS
4012 frames in 5.0 seconds = 802.318 FPS

Please, advise how OpenGL performance can be improved.

The only issue with your glxgears numbers is that they're not pinned to your vertical refresh rate.  Updating the graphics stack to master should fix that.  glxgears is not a benchmark.

Sounds like you don't have PAT enabled in your kernel?  You should fix that, because then you don't rely on MTRRs

I have no idea what your criteria are for "unplayable" or what framerates you got, so it's hard to do anything with this bug.  You'll probably want to do some investigation of why openarena is slow.  Info is at http://dri.freedesktop.org/wiki/IntelPerformanceTuning

Created attachment 33732 [details]
dmesg with drm.debug=0x04

Well, with all settings set to maximum I can play Quake 3 in Windows and FPS keeps steadily around 100FPS.

On Linux with the same settings i get around 50FPS at best and quite often FPS falls below 20, the movement becomes jerky and it's getting really hard to play because the game doesn't follow your mouse movements.

In both Linux and Windows I have the resolution of Quake 3 set to 1600x1200 with 32 bit depth, 32 bit textures, texture and geometric details set to maximum.

PAT is enabled here:

CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y

from dmesg:
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] original variable MTRRs
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000] New variable MTRRs

On my G45 I have the same MTRR error and work around it by booting with  "enable_mtrr_cleanup mtrr_spare_reg_nr=1"

CONFIG_X86_PAT is enabled.

OK, so acceleration is working, it's just not as good as you hope.  There are improvements that could be done to the driver on Ironlake for 3D games, but they aren't done yet.

(In reply to comment #5)
> Well, with all settings set to maximum I can play Quake 3 in Windows and FPS
> keeps steadily around 100FPS.
> 
> On Linux with the same settings i get around 50FPS at best and quite often FPS
> falls below 20, the movement becomes jerky and it's getting really hard to play
> because the game doesn't follow your mouse movements.

Is this retail Quake3 or ioquake?  There was some recent discussion on the mesa3d-dev list about a bug in the extension detection code in Quake3 that caused it to erroneously not use some extensions.  This caused a major drop in performance.

(In reply to comment #8)
> 
> Is this retail Quake3 or ioquake?  There was some recent discussion on the
> mesa3d-dev list about a bug in the extension detection code in Quake3 that
> caused it to erroneously not use some extensions.  This caused a major drop in
> performance.
> 

I'm using retail Quake 3 version, I will try ioquake3 and report the results later.

ioqake3 has the same performance issue.

I may attach Windows screenshot with 100FPS and Linux screenshot with 30FPS, both of the same scene and identical settings.

Created attachment 35346 [details]
Quake 3 screenshot at 640x480 showing 60FPS limit

I've noticed this bug with the Linux Intel drivers: most applications that I run have an upper 60FPS limit, probably due to this message when I run glxgears:

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately 1/1936613746 the monitor refresh rate.
300 frames in 5.0 seconds = 60.000 FPS

For instance Quake 3 never goes beyond 60FPS even in 640x480 mode, that's more than weird taking into consideration that Intel Clarkdale HD GPU has approximately the same performance as NVIDIA 6800GT.

Now Phoronix has really shown that there's something inherently wrong with Linux Intel drivers: http://www.phoronix.com/scan.php?page=news_item&px=ODIwMQ

> On average, Windows 7 with the Intel driver is 10x faster than Ubuntu 10.04 with the Intel driver.

Pinning to your monitor's refresh rate of 60hz is sensible behavior -- don't waste many watts of power to render indistinguishable (except for framerate number) results.

As far as the performance when below refresh rate not matching up, we've got other bugs open to track our limitations, particularly comparing nexuiz performance where we're far below Windows numbers.

Is there some other issue?  Is there something unique to quake3 (please say openarena, as it's harder to test quake3) performance?  If so, please record a demo of where the bad behavior is and attach the file so that we can see what issue you're seeing.

Created attachment 36524 [details]
q3config.cfg for 1600x1200 desktop resolution with FPS < 35

OK, here's a configuration file for 11 yo game, where in 1600x1200 desktop mode you'll never get more than 35FPS and playing is excruciatingly slow.

Under Windows Q3 has no problems with the same configuration.

Your dmesg indicates you don't have the intel_ips driver loaded.  That is critical for graphics performance on Ironlake.  Once you get that loaded, you should see /sys/kernel/debug/dri/0/i915_cur_delayinfo report of the current p-state lower from the maximum (9 on my system, see i915_drpc_info for limits) toward the higher-performance minimum (0 on my system, about 3x faster than 9).  Please fix your kernel and re-test.

Created attachment 41579 [details]
Entire /sys/kernel/debug/dri/*

(In reply to comment #14)
> Your dmesg indicates you don't have the intel_ips driver loaded.  That is
> critical for graphics performance on Ironlake.  Once you get that loaded, you
> should see /sys/kernel/debug/dri/0/i915_cur_delayinfo report of the current
> p-state lower from the maximum (9 on my system, see i915_drpc_info for limits)
> toward the higher-performance minimum (0 on my system, about 3x faster than 9).
>  Please fix your kernel and re-test.

modprobing intel_ips made zero difference:

$ lsmod | grep intel_ips
intel_ips               8761  0

$ cat /sys/kernel/debug/dri/0/i915_drpc_info (dri/64/i915_drpc_info is the same)
HD boost: no
Boost freq: 0
HW control enabled: no
SW control enabled: no
Gated voltage change: no
Starting frequency: P0
Max P-state: P0
Min P-state: P0
RS1 VID: 0
RS2 VID: 38
Render standby enabled: yes

and Quake 3 performance hasn't changed a bit. GLXgears performance also hasn't changed a bit. I'm now attaching the entire /sys/kernel/debug/dri directory (compressed with XZ).

I'm running Fedora 14 i686, I have mesa-libGL-7.9-5.fc14.i686, kernel 2.6.37-rc8 and GIT snapshot of Intel X.org driver.

Looks like your CPU doesn't support gfx turbo, so that's probably not the issue.  Ian's suggestion sounded promising; have you looked into the mesa archives to find out which extensions should be enabled and confirm that they are on your system?  It's quite possible we just have a lot of performance work to do on our ILK GL drivers.  Hi-z is one of the big optimizations we're missing aiui, I'm not sure of its status on ILK.

(In reply to comment #16)
> Looks like your CPU doesn't support gfx turbo, so that's probably not the
> issue.  Ian's suggestion sounded promising; have you looked into the mesa
> archives to find out which extensions should be enabled and confirm that they
> are on your system?  It's quite possible we just have a lot of performance work
> to do on our ILK GL drivers.  Hi-z is one of the big optimizations we're
> missing aiui, I'm not sure of its status on ILK.

You message sound absolutely cryptic to me, I just don't understand what I have to do and for what I've to look for.

Anyway I wonder if there's maybe an OpenGL profiler utility/application which can collect which calls a particular application is issuing and how much time the system spends running those calls. That can help you identify which OpenGL calls need to be improved/properly implemented.

For CPU performance bottlenecks, the tool is called sysprof.   But at least on my machine, while running openarena the CPU is nearly idle.  

Have you tested against ioquake3 yet?

(In reply to comment #18)
> For CPU performance bottlenecks, the tool is called sysprof.   But at least on
> my machine, while running openarena the CPU is nearly idle.  
> 
> Have you tested against ioquake3 yet?

I tested ioquake3 (1.36-8.svn1802.fc14 i686) months ago, and aside from inability to properly set ingame brightness (the game is very darkish regardless brightness settings) the FPS is just the same as in the official Quake 3 binary (1.32b).

I even tried disabling cpufreq power savings (I'm referring to still unresolved bug 30364 in Intel drivers) to no avail.

I no longer own this hardware, so I have to close this bug report.