observations with git X server intel/MTRR/performance

[Tobias Hain]

Hello,

for regression testing and bisecting I have setup a git x-server, mesa, drm
stack according to this popular guide:
http://wiki.x.org/wiki/Development/git

I'm on intel GM965 and consider all components being of git master with
2.6.28-rc2 GEM enabled kernel. I hit on two problems I have only walkarounds
for and am looking for better solutions. This will likely help to improve
the above generic git x stack guide

Problem 1: Lost LD_LIBRARY_PATH results in Software Renderer Mesa
==========
Xorg has root ownership and +s bit:
-rwsr-sr-x 1 root root /opt/gfx-test/bin/Xorg

Executing this script with non root right, will launch KDE4 kwin in my case:

export LD_LIBRARY_PATH=/opt/gfx-test/lib
export LIBGL_DRIVERS_PATH=/opt/gfx-test/lib/dri
startx -- /opt/gfx-test/bin/Xorg -verbose -nolisten tcp

X starts with root rights and the composition manager will launch with 3D
acceleration (at least performance wise it seems so).

However doing glxinfo, glxgears from a terminal results in Software
Rasterizer being used:

glxinfo | grep OpenGL
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.3-devel

"LIBGL_DEBUG=verbose driconf" quickly reveals the source of the problem:
libGL error: dlopen /opt/gfx-test/lib/dri/i965_dri.so failed
(libdrm_intel.so.1: cannot open shared object file: No such file or
directory)

While LIBGL_DRIVERS_PATH is still set to /opt/gfx-test/lib/dri, my xterm
session doesn't hold any LD_LIBRARY_PATH export. And without LD_LIBRARY_PATH
libdrm_intel.so.1 is not found and in consequence the software renderer is
used.

The xterm session must be some child of the original startx process as the
still valid "LIBGL_DRIVERS_PATH" reveals. I know I can easily fix this path
afterwards. And doing so in xterm results in accel 3D:

glxinfo | grep OpenGL
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20080716 x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.3-devel

However who did intercept and resets the LD_LIBRARY_PATH export? How can I
be sure that no automatically launched component (kwin, ...) get's the
Software Renderer as a consequence of a not set path?

I also tried starting X with a modified /etc/kde4/kdm/kdmrc:
ExportList=LD_LIBRARY_PATH,LIBGL_DRIVERS_PATH
ServerCmd=/opt/gfx-test/bin/Xorg

But this doesn't help either. It doesn't protect LD_LIBRARY_PATH and only
LIBGL_DRIVERS_PATH is set.

Problem 2: MTRR not being set on intel
==========

My stock 8.10 system adds reg03 to the MTRR regions when launching x-server
with stock intel 2.4.2 drivers:

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size=    8MB, count=1: uncachable
reg02: base=0x07f700000 ( 2039MB), size=    1MB, count=1: uncachable
reg03: base=0x0e0000000 ( 3584MB), size=  256MB, count=1: write-combining

However if I launch the self build git x server stack reg03 is missing and
only reg00-reg02 being set. Instead I get so error messages in dmesg such
as:

[  209.308956] mtrr: base(0xe0000000) is not aligned on a size(0x770000)
boundary
[  211.173759] mtrr: no MTRR for e0000000,770000 found

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)

and dmesg gets
mtrr: no MTRR for e0000000,10000000 found

The intel driver tries to delete the MTRR, but for some reason it failed to
set it up when launching the X driver. Xorg.0.log doesn't reveal anything
suspicious. It does that behaviour with a PAT kernel as well as the old
fashioned MTRR kernel.

Again: I can fix that manually by writing the appropriate data to
/proc/mtrr. But how to properly fix that? Who exactly is supposed to set up
the MTRR registers? libdrm_intel.so? intel_drv.so? Can't be a privilege
problem sind Xorg is owned by root and +s bit set (see above). Which
interface does the intel component use to set the mtrr? A kernel API or
/proc/mtrr?

If I tested correctly this problem occurs with GEM and non GEM components
and must have something to do with how the git x server is installed in
/opt/gfx-test according to the guide on top.

Thanks,
7oby