Created attachment 18756 [details] screenshot of glxgears I'm using Gentoo - amd64 profile. Kernel: 2.6.25-gentoo-r7 x86_64 Intel(R) Pentium(R) Dual CPU T2370 @ 1.73GHz GenuineIntel GNU/Linux I have a Lenovo N200 with a GM965 chipset (X3100 graphics). I tried lots of different settings combinations in xorg.conf. When accelerated rendering is enabled both glxinfo and glxgears give this error: "Failed to initialize TTM buffer manager. Falling back to classic." glxgears looks weird, is really slow (60 fps) and messes up everythin on the same "height" (screenshot attached). The affected windows/parts-of-desktop are redrawn after moving something on top of them etc. I've attached a screenshot. Games tend to crash the system - besides the fact that I can't see much. The system is unresponsive then but sometimes shuts down cleanly after I press the power button. (I'm not sure if it's critical but it does crash and hang...) Reproducible: Always Steps to Reproduce: 1. startx 2. run glxgears or some other accelerated app Actual Results: It looks as on the screenshot. Affects other apps. Uses very little cpu (2%). Expected Results: Should look normal and run faster. That's the bug report on Gentoo's bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=237068
Created attachment 18757 [details] my xorg.conf
Created attachment 18758 [details] my Xorg log
Created attachment 18759 [details] output of glxinfo The "Failed to initialize TTM buffer manager. Falling back to classic." line is from the stderr and not stdout (ok I don't if it's written in C but I guess you get what I mean). So when I did 'glxinfo >> glxinfo-output' it was on the console and not in the file.
Created attachment 18760 [details] my 'lspci -v' output
Created attachment 18762 [details] dmesg output
The 'error message' (Failed to initialize TTM buffer manager) is just a warning. You are using a drm kernel driver that doesn't support TTM. But that's nothing to worry about, the driver still should work. The new DRI has sync-to-vblank enabled by default, so glxgears fps is limited by your refresh rate (60Hz).
I emerged driconf and disabled vblank-sync. Everything seems to work now. glxgears looks normal and does slightly over 600 fps. It's slow but it works :) Supertux works fine when I enable OpenGL in options so I guess it's kinda fixed. Big THANKS :D btw. Should I report a new vblank-sync bug? Because it definitely does not work right :) On the other hand turning it of was your first suggestion so I guess you know about it and it's one the To-Do... So should this bug be changed to fixed or works-for-me? and should there be another one?
(In reply to comment #7) > btw. Should I report a new vblank-sync bug? Because it definitely does not work > right :) On the other hand turning it of was your first suggestion so I guess > you know about it and it's one the To-Do... This bug is still valid. I changed the subject to better describe the bug. Btw, I only new about the vblank-sync because I also had low fps in glxgears and asked about it on IRC. I didn't know it would fix the bug.
The bad rendering looks like the bug fixed in commit 7b832b56bd971348329c3f4c753ca0abfdf3a3d1 Author: Keith Packard <keithp@keithp.com> Date: Mon Apr 21 16:31:10 2008 +1000 drm/i915: Handle tiled buffers in vblank tasklet The vblank tasklet update code must build 2D blt commands with the appropria tiled flags Signed-off-by: Dave Airlie <airlied@redhat.com>
I'd just like to confirm that's it's still here with the new Mesa 7.2_rc1.
It won't change when you update mesa, it will change when you update your kernel.
*** Bug 17443 has been marked as a duplicate of this bug. ***
2.6.26 and above should have the fix for this issue. The advantage of vblank sync is that you won't see tearing in your 3d apps anymore. It makes your glxgears numbers the same as your refresh rate though, so it may cause panic at first. :)
It seems this can be closed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.