AW: observations with git X server intel/MTRR/performance

Tobias Hain tobias.hain at gmx.de
Fri Nov 7 15:56:49 PST 2008


> On Thu, 2008-11-06 at 14:03 +0100, Tobias Hain wrote:
>> Hello,
>> Problem 2: MTRR not being set on intel
>> ==========
>> [...] 
>> And on every exit of the x session:
>> waiting for X server to shut down error setting MTRR (base = 0xe0000000,
>> size = 0x10000000, type = 1) Invalid argument (22)
>> 
>> But how to properly fix that? Who exactly is supposed to set up
>> the MTRR registers?

Eric wrote:
> 
> Things that use libpciaccess (the X Server) should be getting correct wc
> mappings thanks to using the resource_wc sysfs file.  If you update your
> kernel, the kernel also gets wc mappings using the new io_map_atomic
> interfaces.  So at that point, the MTRR shouldn't be necessary.

I do see the different interfaces for controlling address space cache
control:
http://lwn.net/Articles/278994/

If I use these stock ubuntu 8.10 compoents:
. libpciaccess 0.10.3
. x-server 1.5.2
. xf86-video-intel 2.4.2 (which is labelled 2.4.1 in ubuntu)
I don't get the above MTRR error messages.

But the self compiled
. x-server master or 1.5.3
. xf86-video-intel master or 2.5.0
throw these regardless of 2.6.28-rc2 or 2.6.28-rc3 or your drm-intel-next
branch and regardless of PAT or nopat kernel.

I don't see a performance difference anyway when manually applying a MTRR WC
region so I'm assuming the libpciaccess does the right thing. Still these
MTRR messages are confusing - I don't know which module of the xserver is
thowing them and why. And whether it tries to mess with old fashioned MTRRs
or whether it's just deprecated information logging.

--

Talking about performance: Going from 2.6.28-rc2 -> rc3 of your
drm-intel-next branch did improve glxgears performance from 800 -> 1000fps
on GM965 @T7500. Wobby windows are noticeable smoother on WUXGA screens now.

Performance didn't go up for me when going classic -> TTM -> GEM. But for
some reason it just did. Good work! Even if that wasn't the focus anyway.

Regards,
Tobias




More information about the xorg mailing list