AW: observations with git X server intel/MTRR/performance
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 = 0xe000, size = 0x1000, 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
observations with git X server intel/MTRR/performance
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=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x07f80 ( 2040MB), size=8MB, count=1: uncachable reg02: base=0x07f70 ( 2039MB), size=1MB, count=1: uncachable reg03: base=0x0e000 ( 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(0xe000) is not aligned on a size(0x77) boundary [ 211.173759] mtrr: no MTRR for e000,77 found And on every exit of the x session: waiting for X server to shut down error setting MTRR (base = 0xe000, size = 0x1000, type = 1) Invalid argument (22) and dmesg gets mtrr: no MTRR for e000,1000 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
AW: observations with git X server intel/MTRR/performance
Julien Cristau wrote: While LIBGL_DRIVERS_PATH is still set to /opt/gfx-test/lib/dri, my xterm session doesn't hold any LD_LIBRARY_PATH export. xterm can be installed setgid utmp. In that case ld.so will ignore LD_LIBRARY_PATH. Thanks for pointing out! In my case it is -rwxr-sr-x 1 root ssh /usr/bin/ssh-agent For the time being I commented out #use-ssh-agent in /etc/X11/Xsession.options and LD_LIBRARY_PATH is set all the way though kde. Thanks again, 7oby ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: observations with git X server intel/MTRR/performance
On Thu, 2008-11-06 at 14:03 +0100, Tobias Hain wrote: Hello, 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=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x07f80 ( 2040MB), size=8MB, count=1: uncachable reg02: base=0x07f70 ( 2039MB), size=1MB, count=1: uncachable reg03: base=0x0e000 ( 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(0xe000) is not aligned on a size(0x77) boundary [ 211.173759] mtrr: no MTRR for e000,77 found And on every exit of the x session: waiting for X server to shut down error setting MTRR (base = 0xe000, size = 0x1000, type = 1) Invalid argument (22) and dmesg gets mtrr: no MTRR for e000,1000 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? Getting working MTRRs has been getting harder and harder over time. So we're trying to make things work without them. 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. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
