[arch-general] Archive xorg-server 1.4 on Arch Server
From my research it appears that many people who have Intel cards have this issue. I have the Intel 82945G/GZ using the xf86-video-intel driver. From
Hello. I have updated to Xorg-server 1.5 from testing. However I get extremely low fps (60fps) when running glx-gears. The error I get in the terminal is "Failed to initialize TTM buffer manager. Falling back to classic." After googling I came across this bug report on gentoo tracker: http://bugs.gentoo.org/show_bug.cgi?id=237468 the bug report it seems as if no work is going into supporting TTM, instead all the work with the driver is going into GEM support. I am not sure what TTM and GEM are, which makes my understand weak with the issue at hand.
From what I do understand it has something to do with dri (a backend?)
I have updated libdrm to 2.4.1 and xf86-video-intel to 2.5.1 and continue to receive the error as many others do. I am currently in the process of compiling a new kernel that has GEM support. Following the directions from comment 41 of the bug report.
From reading though the bug report is seems as if this GEM technology is unstable and not ready for any type of release.
If xorg-server 1.5 is moved from testing to extra, can we have an archive of xorg-server 1.4 and all related packages? This migration is going to affect a lot of archers with Intel cards. Many archers require much higher frames per second. By providing an archive of these packages it will allow new installations and people who upgrade a chance to downgrade to regain performance. Hopefully I was clear in my explanation if not feel free to ask me any questions. Thank you for taking the time to read this. Thank you, ~pyther
pyther wrote:
Hello.
I have updated to Xorg-server 1.5 from testing. However I get extremely low fps (60fps) when running glx-gears. The error I get in the terminal is "Failed to initialize TTM buffer manager. Falling back to classic."
After googling I came across this bug report on gentoo tracker: http://bugs.gentoo.org/show_bug.cgi?id=237468
From my research it appears that many people who have Intel cards have this issue. I have the Intel 82945G/GZ using the xf86-video-intel driver. From the bug report it seems as if no work is going into supporting TTM, instead all the work with the driver is going into GEM support. I am not sure what TTM and GEM are, which makes my understand weak with the issue at hand. From what I do understand it has something to do with dri (a backend?)
I have updated libdrm to 2.4.1 and xf86-video-intel to 2.5.1 and continue to receive the error as many others do. I am currently in the process of compiling a new kernel that has GEM support. Following the directions from comment 41 of the bug report.
From reading though the bug report is seems as if this GEM technology is unstable and not ready for any type of release.
If xorg-server 1.5 is moved from testing to extra, can we have an archive of xorg-server 1.4 and all related packages? This migration is going to affect a lot of archers with Intel cards. Many archers require much higher frames per second. By providing an archive of these packages it will allow new installations and people who upgrade a chance to downgrade to regain performance.
Hopefully I was clear in my explanation if not feel free to ask me any questions. Thank you for taking the time to read this.
Thank you, ~pyther
I don't remeber what GEM and TTM are either, but I've read about it on phoronix.com. That site has lots of articles related to graphic drivers, xorg etc. Eg http://www.phoronix.com/scan.php?page=article&item=xorg_kms_2008&num=1 http://www.phoronix.com/scan.php?page=search&q=GEM http://www.phoronix.com/scan.php?page=search&q=TTM
On Sun, 2008-11-16 at 13:55 -0500, pyther wrote:
I have updated to Xorg-server 1.5 from testing. However I get extremely low fps (60fps) when running glx-gears. The error I get in the terminal is "Failed to initialize TTM buffer manager. Falling back to classic."
That's not a bug, it's a feature. The 60fps you're getting is Vsync. Nothing wrong. The message you get is a warning. The DRI driver in intel-dri 7.2 has TTM support, but as X and kernel don't have support for it as it will never get integrated, the DRI driver will fallback to the old rendering method as in intel-dri 7.0. There's nothing buggy here and xorg-server 1.5 will go to extra without keeping 1.4 around.
There's nothing buggy here and xorg-server 1.5 will go to extra without keeping 1.4 around.
dev status? How many stoppers are there? Any idea when it will move?
On Sun, 2008-11-16 at 12:00 -0800, Amanai wrote:
dev status? How many stoppers are there? Any idea when it will move?
My stopper list: - time - xf86-input-synaptics should have better documentation about hotplugging configuration before it's thrown at our users - nvidia-7xxx All other stoppers have been solved. The first item should be fixable next weekend, as it looks now I have enough time then. xf86-input-synaptics could need some help, but it seems Pierre put something about this in a bugreport. Nvidia-7xxx is not a real stopper here. Cards this driver are ancient and can't keep up with todays standards, so the nv or vesa driver isn't such a big regression for these. If Nvidia provides us with a new (beta) driver with X.Org 7.4 support we're happy to package it.
On 21:13, Sun 16 Nov 08, Jan de Groot wrote:
- xf86-input-synaptics should have better documentation about hotplugging configuration before it's thrown at our users
I'm using this driver for my touchpad, works fine so far but one finger tapping doesn't work at all. My 10-synaptics.fdi looks like this: ---snip--- <?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <match key="info.product" contains="ETPS/2 Elantech Touchpad"> <merge key="input.x11_driver" type="string">synaptics</merge> <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge> <merge key="input.x11_options.SHMConfig" type="string">true</merge> <merge key="input.x11_options.AccelFactor" type="string">0.032</merge> <merge key="input.x11_options.LeftEdge" type="string">1700</merge> <merge key="input.x11_options.RightEdge" type="string">5300</merge> <merge key="input.x11_options.TopEdge" type="string">1700</merge> <merge key="input.x11_options.BottomEdge" type="string">4200</merge> <merge key="input.x11_options.FingerLow" type="string">25</merge> <merge key="input.x11_options.FingerHigh" type="string">30</merge> <merge key="input.x11_options.MaxTapTime" type="string">180</merge> <merge key="input.x11_options.MaxTapMove" type="string">220</merge> <merge key="input.x11_options.MinSpeed" type="string">0.625</merge> <merge key="input.x11_options.MaxSpeed" type="string">1.0</merge> <merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge> <merge key="input.x11_options.HorizScrollDelta" type="string">100</merge> <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge> <merge key="input.x11_options.VertScrollDelta" type="string">100</merge> <!-- Restore old synaptics driver defaults removed by Fedora/RH patch --> <merge key="input.x11_options.RTCornerButton" type="string">2</merge> <merge key="input.x11_options.RBCornerButton" type="string">3</merge> <merge key="input.x11_options.TapButton1" type="string">1</merge> <merge key="input.x11_options.TapButton2" type="string">2</merge> <merge key="input.x11_options.TapButton3" type="string">3</merge> </match> </match> </device> </deviceinfo> ---snip--- Thomas
On Sun, 16 Nov 2008 12:13:34 -0800, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sun, 2008-11-16 at 12:00 -0800, Amanai wrote:
dev status? How many stoppers are there? Any idea when it will move?
hotplugging configuration before it's thrown at our users - nvidia-7xxx
nvidia-7xxx take a look here http://www.nvnews.net/vbulletin/showthread.php?t=118088 and here are the sources ftp://download.nvidia.com/XFree86/Linux-x86/180.06/ ftp://download.nvidia.com/XFree86/Linux-x86_64/180.06/
On Monday 17 November 2008 02:29:18 Amanai wrote:
nvidia-7xxx take a look here http://www.nvnews.net/vbulletin/showthread.php?t=118088
and here are the sources ftp://download.nvidia.com/XFree86/Linux-x86/180.06/ ftp://download.nvidia.com/XFree86/Linux-x86_64/180.06/
That is the 180.xx driver which does not help here. The problem is the 71xx driver for tnt and old geforce cards. But as Jan said, those are rarly used and the nv driver is a good alternative. (3d acceleration of these cards is nearly useless these days anyway) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
2008/11/16 Jan de Groot <jan@jgc.homeip.net>:
On Sun, 2008-11-16 at 12:00 -0800, Amanai wrote:
dev status? How many stoppers are there? Any idea when it will move?
My stopper list: - time - xf86-input-synaptics should have better documentation about hotplugging configuration before it's thrown at our users - nvidia-7xxx
(...) Nvidia-7xxx is not a real stopper here. Cards this driver are ancient and can't keep up with todays standards, so the nv or vesa driver isn't such a big regression for these. If Nvidia provides us with a new (beta) driver with X.Org 7.4 support we're happy to package it.
I guess this applies also to nvidia-96xx, right?
On Mon, 2008-11-17 at 21:05 +0100, José M. Prieto wrote:
2008/11/16 Jan de Groot <jan@jgc.homeip.net>:
On Sun, 2008-11-16 at 12:00 -0800, Amanai wrote:
dev status? How many stoppers are there? Any idea when it will move?
My stopper list: - time - xf86-input-synaptics should have better documentation about hotplugging configuration before it's thrown at our users - nvidia-7xxx
(...) Nvidia-7xxx is not a real stopper here. Cards this driver are ancient and can't keep up with todays standards, so the nv or vesa driver isn't such a big regression for these. If Nvidia provides us with a new (beta) driver with X.Org 7.4 support we're happy to package it.
I guess this applies also to nvidia-96xx, right?
Nvidia-96xx was updated to a beta release recently, the current version in testing has support for X.Org 7.4.
On Sun, 16 Nov 2008 20:51:07 +0100, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sun, 2008-11-16 at 13:55 -0500, pyther wrote:
I have updated to Xorg-server 1.5 from testing. However I get extremely low fps (60fps) when running glx-gears. The error I get in the terminal is "Failed to initialize TTM buffer manager. Falling back to classic."
That's not a bug, it's a feature. The 60fps you're getting is Vsync. Nothing wrong. The message you get is a warning. The DRI driver in intel-dri 7.2 has TTM support, but as X and kernel don't have support for it as it will never get integrated, the DRI driver will fallback to the old rendering method as in intel-dri 7.0.
There's nothing buggy here and xorg-server 1.5 will go to extra without keeping 1.4 around.
I'm a bit confused. Can you explain to me about this Vsync thing? When running xorg-server 1.4 I was able to get ~650fps. I have not changed my xorg.conf since switching to xorg-server 1.5 where I get a max of 60fps.
From the gentoo bug report: http://bugs.gentoo.org/show_bug.cgi?id=237468
"When running programs from the console in xorg-server 1.5, I get the warning "Failed to initialize TTM buffer manager. Falling back to classic." glxgears performance has dropped by around 90% and compiz runs much slower. There are a variety of window placement issues that I believe are related. I have an Intel 965, using xf86-video-i810-2.4.2-r1 and mesa-7.1." There seems to be no mention of "vsync" anywhere on the page and many people have this issue. I would be more than willing to play with the "vsync" to see if this is an issue or not, but I am not sure where to start. If you can tell me where and what I should modify I would appreciate it.
On Sun, 2008-11-16 at 15:00 -0500, pyther wrote:
I'm a bit confused. Can you explain to me about this Vsync thing?
When running xorg-server 1.4 I was able to get ~650fps. I have not changed my xorg.conf since switching to xorg-server 1.5 where I get a max of 60fps.
There's no such thing as a 90% performance drop, glxgears is not a benchmark. As for vsync, it means that your framerate is tied to your refreshrate. This is done by default now to avoid heavy tearing issues when using 3D on intel chips. To restore to the old behaviour, put this in your ~/.drirc: <driconf> <device screen="0" driver="i915"> <application name="Default"> <option name="vblank_mode" value="0" /> </application> </device> </driconf> Replace i915 with the driver that suits your intel chip. I would advise against using xf86-video-intel-2.5.x and libdrm-2.4.x until GEM is merged into the kernel and things start using it. We're sticking to xf86-video-intel-2.4.x and libdrm-2.3.1 now because the newer versions cause regressions. The main improvements in the 2.5 series are related to GEM, and as long as our kernel doesn't have that, there's no need for a newer driver than 2.4.x.
On Sun, 16 Nov 2008 21:10:04 +0100, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sun, 2008-11-16 at 15:00 -0500, pyther wrote:
There's no such thing as a 90% performance drop, glxgears is not a benchmark. As for vsync, it means that your framerate is tied to your refreshrate. This is done by default now to avoid heavy tearing issues when using 3D on intel chips. To restore to the old behaviour, put this in your ~/.drirc:
<driconf> <device screen="0" driver="i915"> <application name="Default"> <option name="vblank_mode" value="0" /> </application> </device> </driconf>
Replace i915 with the driver that suits your intel chip.
I would advise against using xf86-video-intel-2.5.x and libdrm-2.4.x until GEM is merged into the kernel and things start using it. We're sticking to xf86-video-intel-2.4.x and libdrm-2.3.1 now because the newer versions cause regressions. The main improvements in the 2.5 series are related to GEM, and as long as our kernel doesn't have that, there's no need for a newer driver than 2.4.x.
That works wonders! Thank you so much and I'm sorry for all the trouble I caused! I am surprised I did not find that anywhere through Google. As I am sure this is going to be any issue for other users should this information be put into a wiki entry? Then there could be a post-install message for xf86-video-intel which directs users to that wiki page? Also do you mind if I put that information on the gentoo bug tracker? Sorry Again!
participants (7)
-
Amanai
-
Dieter Plaetinck
-
Jan de Groot
-
José M. Prieto
-
Pierre Schmitz
-
pyther
-
Thomas Bohn