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. Googling a little, there reports of similar problems around. Fedora people believe this to be solved by installing the latest mesa-libGL & mesa-libGLU packages. Gentoo doesn't have those... For now, I've gone back to 1.4.2, as 1.5 was not usable for me due to these issues. If anyone has any workable ideas, I'd be happy to switch back again.
i have the same problem
I have same problem on my laptop (intel video card). Glxinfo and Opengl application return "Failed to initialize TTM buffer manager. Falling back to classic." in terminal. If I run etracer (game) menu is 2D and is working ok, but after I had started the game (3D) it crash with: "etracer: ../common/dri_bufmgr_fake.c:982: dri_fake_emit_reloc: Assertion `target_fake->is_static || target_fake->size_accounted' failed. Neúspěšně ukončen (SIGABRT)" Some other application (AOM in wine, torcs etc.) hangs whole X - which are not able to recover itself by restart -> I have to restart whole computer! There is emerge --info info ---- Portage 2.2_rc8 (default/linux/amd64/2008.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.26-gentoo x86_64) ================================================================= System uname: Linux-2.6.26-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T5250_@_1.50GHz-with-glibc2.2.5 Timestamp of tree: Sat, 13 Sep 2008 08:30:02 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.62-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.26 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=core2 -fomit-frame-pointer -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.1/env /usr/kde/4.1/share/config /usr/kde/4.1/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=core2 -fomit-frame-pointer -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="cs_CZ.utf8" LC_ALL="cs_CZ.utf8" LDFLAGS="-Wl,-O1" LINGUAS="cs" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/desktop-effects /usr/local/portage/layman/kdesvn-portage /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip X a52 aac aalib acl acpi additions alsa amd amd64 apache2 archivearts berkdb bluetooth bzip2 cairo calendar captury cdr cli cracklib crypt ctype cups dbus dhcp directfb dri dts dv dvd dvdr dvdread editor encode exif fame fat fbcon ffmpeg flac fortran ftp gd gdbm gif glitz gpm hal hdaps highlight history htmlhandbook iconv icq imap imlib inotify ipv6 irc isdnlog jabber java jingle jpeg jpeg2k kde kdehiddenvisibility ladspa lame laptop libcaca libnotify libwww live lm_sensors mad matroska mbrola messenger midi mikmod mmx mmxext mp3 mpeg mplayer msn mudflap multilib mysql mysqli ncurses network nls nptl nptlonly nsplugin ntfs objc++ ogg openal opengl openmp oscar oss pam pcre pdf perl php pie png ppds pppd prediction python qt3 qt3support qt4 rar readline recode reflection reiserfs samba scanner sdk sdl semantic-desktop server session simplexml slang spell spl sql sse sse2 ssl ssse3 subversion svg sysfs taglib tcpd telepathy themes theora tiff tools truetype unicode usb v4l vnc vorbis wifi wmf x264 xcb xcomposite xine xinerama xml xmlreader xmlwriter xorg xsl xv xvid xvmc zip" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulawmulti null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="cs" USERLAND="GNU" VIDEO_CARDS="intel i810 vga vesa dummy" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
http://bugs.freedesktop.org/show_bug.cgi?id=13922 It seems that you need libdrm >= 2.4.0, which is not yet released. It sounds like the latest libdrm from the git repo might work.
(In reply to comment #3) > http://bugs.freedesktop.org/show_bug.cgi?id=13922 > > It seems that you need libdrm >= 2.4.0, which is not yet released. It sounds > like the latest libdrm from the git repo might work. > Probably not "we want", rather "portage want" to be consistent :-) - I have the same prolem.
I've tried libdrm live ebuild from x11 overlay, it didn't fix anything for me. I have i965.
> I've tried libdrm live ebuild from x11 overlay, it didn't fix anything for me. > I have i965. > I tried the same, and xf86-video-i810-2.4.2-r1 (I also have i965) even nicely said in configure: DRI_MM: yes. What I've heard TTM is being replaced by GEM. Maybe GEM is not yet present in the i965 driver, or am I totally on the wrong track? I was thinking of going back to xf86-video-i810-2.1.1; but it would not compile, probably given the xorg-server 1.5.0 environment (Although it said: DRI_MM yes for just libdrm-2.3.*). Also notable is that I had to provide my own xf86mm.h since libdrm-9999 didn't feel like it, if anyone wants to reproduce. Could i have forgotten to remerge something? (After upgrading to libdrm-9999 i remerged xf86-video-i810, mesa and xorg-server) I wonder if >=libdrm2.4.0 really solves it, as far as i965 goes, or will we need newer xf86-video-i810 aswell? (I tried xf86-video-i810-9999 but it just crashed my X server) What do you all think?
I've found similar information. They want to 'skip' ttm and provide newer gem that is not complete yet. On some other bug in gentoo bugzilla it was said that one need whole xorg from git to make gem work.
Seeing this thread: http://ubuntuforums.org/showthread.php?p=5771396 it also seems as you may need GEM-support in the kernel.
I managed to rid the error by downgrading to mesa-7.0.3 and libdrm-2.3.0, however still having xf86-video-i810-2.4.2-r1. Sadly enough xorg-server-1.5.0 requires >=media-libs/mesa-7.1 and thus I am now on xorg-server-1.4.2 and xorg-x11-7.3 (No cool dri2 effects of transparent gl-windows and the like ;_; (Which i were able to have before in xorg-server-1.5.0 prior to this error appearing) (However transparent xv works like a charm)). The tricks seemed to be the version of mesa, and i now have in /etc/portage/package.keywords: =media-libs/mesa-7.0.3 in /etc/portage/package.mask: >x11-base/xorg-x11-7.3 >x11-base/xorg-server-1.4.2 I also needed to downgrade from xorg-x11-7.4, since that would not work with xorg-server-1.4.2. This is no real solution, as is it a temporary compromise until all this GEM/UXA-stuff get sorted out. This works for me in the meantime, unless somebody comes up with a better solution (Preferably so that one might be able to use xorg-server-1.5.0 in all its glory). This is my emerge --info, if anybody cares: Portage 2.1.4.4 (default/linux/amd64/2008.0, gcc-4.3.1, glibc-2.7-r2, 2.6.26-tuxonice_proxy_edition x86_64) ================================================================= System uname: 2.6.26-tuxonice_proxy_edition x86_64 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz Timestamp of tree: Tue, 16 Sep 2008 07:34:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="candy distlocks metadata-transfer parallell sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LC_ALL="en_GB.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en sv ja" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/desktop-effects /usr/portage/local/layman/java-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa amd64 berkdb bzip2 caps cjk cli cracklib crypt cups dbus dri emacs encode esd exif ffmpeg fontconfig fortran gcj gdbm gpm gtk hal hddtemp iconv ieee1394 ipv6 isdnlog java javascript jpeg jpeg2k latex lm_sensors midi mmx mmx2 mp4 mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre perl png pppd python readline reflection samba sdl session spl sse sse2 sse3 ssl ssse3 startup-notification svg sysfs tcpd theora threadsafe tiff truetype unicode usb v4l v4l2 vorbis x264 xcomposite xinerama xorg xulrunner xvid zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="synaptics joystick keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en sv ja" USERLAND="GNU" VIDEO_CARDS="i810 fbdev vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
http://bugs.gentoo.org/show_bug.cgi?id=236917 Well, before GEM is ready, we i965 users will have to stay low (1.4.2) for a while.
One thing that gets back at me now though is that I had it all working nicely, including dri2 neat stuff, under 1.5.0, but then some update ruined it. Shouldn't it be possible, with some overlay of some kind, to somehow get that functionality back but using TTM (just like it was for me), seeing how GEM is not mature yet. However i can not recall what ersions of everything I had before. To note though is that it doesn't seem like xorg-server-1.5.0 itself is causing the problem, rather that xorg-server-1.5.0 currently pulls in newer mesa which don't work. Maybe it also has to do something with newer versions of libdrm aswell. I was actually able to getthe error under xorg-server-1.4.2 aswell, by upgrading mesa and libdrm; that's what I'm basing all this off.
anyone tried out the new mesa 7.2? Still broken?
(In reply to comment #12) > anyone tried out the new mesa 7.2? Still broken? > From what i can recall it didn't work with mesa 7.2. It seems that past mesa 7.0.* TTM got thrown out or something. Anyone more knowing on the matter please fill me in here. Also, from what i gather, 2.6.27-series kernel has GEM support. Shall I once again try out stuff to see if i get working GEM as soon as 2.6.27 hits tuxonice-sources?
> Also, from what i gather, 2.6.27-series kernel has GEM support. That's wrong, can you tell us how you come to that conclusion? (a short look at the source would've been enough to verify) gem-enabled kernel is currently available as a git-branch on fdo by eric anholt. I think kernel-inclusion is optimistically going to happen in 2.6.28-rcs. I'm currently trying to get a gem-enabled system running, though it still has lot's of problems, just reported some mesa-bug upstream about that.
(In reply to comment #14) > > Also, from what i gather, 2.6.27-series kernel has GEM support. > > That's wrong, can you tell us how you come to that conclusion? (a short look at > the source would've been enough to verify) > > gem-enabled kernel is currently available as a git-branch on fdo by eric > anholt. I think kernel-inclusion is optimistically going to happen in > 2.6.28-rcs. Oh, my bad! Guess it was all the talk of about the difficulties about patching 2.6.26 for GEM but how it was easy for 2.6.27 (And the easy part i misinterpreted as being already done in, not as in easy to patch).
As I've said in another bug, TTM is dead. Better move on. The focus is now on GEM. Judging how many CCs we have here, I'd say this is something all of you really want to try. Here's my plan for now: 1) I won't be putting xf86-video-i810-2.4.97.0 to portage. Simply because a lot of stuff has been merged right after this version, so you'd all be testing something that's just too far away from the next RC. Remember that these days, 2.5 == master, so you'll all be getting UXA, GEM, kernel mode-setting and much more. The only missing pieces are DRI2 and XvMC support for 965+. 2) I will however be putting the next RCs into portage with a p.mask. As soon as the GEM stuff becomes available, I'll try to put it in portage as well. As I only own an 855GM laptop, there might be bugs with other chips, be prepared to file bugs _upstream_ :) 3) Intel has decided to provide GEM as a separate package for widespread testing. As I've said, I'll be putting this in Portage, however I think this will always be under p.mask. The long term approach will be to rely on newer kernels for GEM bits (and/or x11-base/x11-drm I guess). 4) I _will_ need help with all this stuff. As I'm not even sure my laptop will benefit from GEM, I will need assistance to test ebuilds once I write them. I'm thinking all this stuff could first be done in a branch of the x11 overlay... I just need to sit down one day and get it done. Help will be greatly appreciated ;) Thanks for your patience
> Thanks for your patience No man, thank *YOU* for your support!!! I've a laptop with 945GM, not using accel right now as I unmerged beryl once it became obsolete, but can help with the tests.
I have a 965. I'll be happy to help test.
Same here. If it becomes easily doable (e.g. overlay) I'll gladly test it on my 965.
(In reply to comment #16) > 4) I _will_ need help with all this stuff. As I'm not even sure my laptop will > benefit from GEM, I will need assistance to test ebuilds once I write them. I've an integrated i915 (centrino) and accordingly with the news I've found on internet I should expect a +50% in 3D performance! WOW! I'm eager to test it :D
> I've an integrated i915 (centrino) and accordingly with the news I've found on > internet I should expect a +50% in 3D performance! WOW! I'm eager to test it :D I think this improvement is in comparison to a system without TTM *or* GEM. Compared to TTM, GEM seems to slightly inferior: http://marc.info/?l=dri-devel&m=121127531521174&w=2 Can someone please tell me the versions of the packages I could go back to so as to get TTM support, until GEM arrives?
i have exactly the same problem with 965GM card and xorg-server 1.5
Why are people here labelling this as a "problem"? TTM was simply thrown aside for intel driver and so it isn't provided in the lower levels, and the driver is smart enough to not use that old in-development code path... GEM is hoped to arrive into the 2.6.28 kernel (probable release time somewhere around December). There are kernel git branches actively worked on for the merge, so I'm considering to try to merge that into 2.6.27 codebase at the right moment for my own testing
This is a problem because those with Intel cards cannot run xorg-server 1.5 with anything like decent 3D performance.
(In reply to comment #24) > This is a problem because those with Intel cards cannot run xorg-server 1.5 > with anything like decent 3D performance. > Indeed, however there should actually be SOME configuration that should work as I had it working under xorg-server-1.5 until after an upgrade whereafter i was force to downgrade to, among other things, xorg-server 1.4. I'm just saying this to point out that should be possible to downgrade to some specific set of drivers mesa etc. and still use xorg-server 1.5, but dumbly enough i don't know the versions of everything involved in the working configuration i had. Did anybody else experience this; good 3D under xorg-server 1.5 but suddenly after an upgrade it stopped working? In that case it might still be possible to run xorg-server 1.5 with TTM in the meantime, waiting for GEM. However i guess the versions needed might not be in portage anymore.
Hi all, just a quick word to let you know I'm currently in the process of making GEM available to you all for testing. For now, I'm running into some issues and I don't know if they are configuration issues or real bugs I'm running into. Anyhow, GEM should be available shortly, I promise :) At least now, I'm working on it. Cheers
(In reply to comment #26) > Hi all, just a quick word to let you know I'm currently in the process of > making GEM available to you all for testing. > > For now, I'm running into some issues and I don't know if they are > configuration issues or real bugs I'm running into. > > Anyhow, GEM should be available shortly, I promise :) At least now, I'm working > on it. > > Cheers > Excellent. Since linux kernel 2.6.27 is out, can I ask to stick your patches to that version ? ;) Thanks for your work !
(In reply to comment #27) > Excellent. Since linux kernel 2.6.27 is out, can I ask to stick your patches to > that version ? ;) Well since GEM only *just* got merged before 2.6.28-rc1... I'd say it's a definitive no :) I understand running such an unstable kernel will put off a lot of people but I just can't backport those patches, and they are probably bound to evolve some more as more people test it before the final 2.6.28. Sorry :)
(In reply to comment #25) > (In reply to comment #24) > > This is a problem because those with Intel cards cannot run xorg-server 1.5 > > with anything like decent 3D performance. > > > Indeed, however there should actually be SOME configuration that should work as > I had it working under xorg-server-1.5 until after an upgrade whereafter i was > force to downgrade to, among other things, xorg-server 1.4. I'm just saying > this to point out that should be possible to downgrade to some specific set of > drivers mesa etc. and still use xorg-server 1.5, but dumbly enough i don't know > the versions of everything involved in the working configuration i had. > > Did anybody else experience this; good 3D under xorg-server 1.5 but suddenly > after an upgrade it stopped working? In that case it might still be possible to > run xorg-server 1.5 with TTM in the meantime, waiting for GEM. Yes, i upgraded my system to ~x86 yesterday and 3D performances where 5-10% better (in terms of quake3 fps). Now i'm stuck with the "TTM" error, after rebooting after a mesa re-compile.
with 2.5.0 in the tree, what is the current status of this?
(In reply to comment #30) > with 2.5.0 in the tree, what is the current status of this? > the same
The same, but not quite ;) Technically, 2.5.0 is GEM Ready (TM) and is built with GEM support. Actually, you only need to GEM kernel to start using it. I suggest using the "drm-intel-next" branch of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (which is based on 2.6.28-rc2, iirc) Beware though that this is _highly_ experimental, even more so than TTM was 2 months ago. I, for one, still can't get it to work properly on my 855GM laptop. Feel free to try it, but you get to keep the pieces if it breaks. You all have been warned. Bugs about GEM should go *directly* to http://bugs.freedesktop.org/ Thanks
Oh and of course, you'll need mesa from master... libdrm from master wouldn't hurt either although it's not required. Thanks
upgrading to 2.5.0 (with xorg-server 1.4.2) with a non-GEM (2.6.27-zen3) kernel pulls in a variety of things, but causes an odd bug: when I log into KDE, the screen is completely white, but the cursor changes in the correct context. I think the screen is being drawn in a buffer somewhere but not being displayed properly. By the way, to get rid of the problem, I had to downgrade a bunch of packages. Libdrm-2.3.1 didn't work (exactly the same behavior), but libdrm-2.3.0 worked fine. I went back to mesa-7.0.3 Is this expected?
(In reply to comment #34) > upgrading to 2.5.0 (with xorg-server 1.4.2) with a non-GEM (2.6.27-zen3) kernel > pulls in a variety of things, but causes an odd bug: when I log into KDE, the > screen is completely white, but the cursor changes in the correct context. I > think the screen is being drawn in a buffer somewhere but not being displayed > properly. I've some similar issues on my Thinkpad X40: some part of the screen are not displayed correctly. For example, this happen on Firefox; most of the page is not rendered, but if I move the mouse and the mouse pass hover a link, the link shows up correcly. Usualy, doing a page down / page up show the page correctly.
(In reply to comment #35) > I've some similar issues on my Thinkpad X40 What Intel chip do you have in there, because I have similar issues on my 855GM laptop. If that's the case, I've opened a bug on freedesktop. If you want a quick workaround, you can put this bit in your Device section: Option "EXANoComposite" "true" Beware though that it'll slow down X a fair bit.
(In reply to comment #36) > (In reply to comment #35) > > I've some similar issues on my Thinkpad X40 > > What Intel chip do you have in there, because I have similar issues on my 855GM > laptop. If that's the case, I've opened a bug on freedesktop. Intel 82852/855GM rev 02
(In reply to comment #37) > Intel 82852/855GM rev 02 Bingo. Here's the bug's URL if you want to watch it too :) http://bugs.freedesktop.org/show_bug.cgi?id=18138
(In reply to comment #32) > The same, but not quite ;) > > Technically, 2.5.0 is GEM Ready (TM) and is built with GEM support. Actually, > you only need to GEM kernel to start using it. > > I suggest using the "drm-intel-next" branch of > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (which is based > on 2.6.28-rc2, iirc) > > Beware though that this is _highly_ experimental, even more so than TTM was 2 > months ago. I, for one, still can't get it to work properly on my 855GM laptop. > > Feel free to try it, but you get to keep the pieces if it breaks. You all have > been warned. > > Bugs about GEM should go *directly* to http://bugs.freedesktop.org/ > > Thanks > intel-965GM xorg-server-1.5.2 xf86-video-intel-2.5.0 git-sources-2.6.28_rc3-r1 All the same. Unchanged. dl@isit-rukin-va ~ $ glxinfo name of display: :0.0 Failed to initialize TTM buffer manager. Falling back to classic. d
ok, I'm running 2.6.28-rc3-zen1. Could you post a guide to try this out? It would be good to be able to do it entirely in portage :) I'm currently running mesa-7.0.3, xf86-video-intel-2.4.2, libdrm-2.3.0, xorg-server-1.4.2, xorg-x11-7.3, and I'm using a 965 on a Thinkpad T61.
(In reply to comment #40) > ok, I'm running 2.6.28-rc3-zen1. Could you post a guide to try this out? It > would be good to be able to do it entirely in portage :) > > I'm currently running mesa-7.0.3, xf86-video-intel-2.4.2, libdrm-2.3.0, > xorg-server-1.4.2, xorg-x11-7.3, and I'm using a 965 on a Thinkpad T61. I don't want to sound like an elitist prick or anything, but actually getting GEM to work is far from trivial. Basically, you'll need: 1) a fully up to date 100% ~x86 or ~amd64 system, not a half-stable-half-unstable one, 2) you'll need to get -intel 2.5.0 to work (if that step fails, open a bug and don't bother with GEM, it won't work either), 3) _then_ you'll need to fetch the proper kernel (see below) 4) you'll need -intel, mesa and xorg-server from the x11 overlay (with their corresponding deps of course). Do *NOT* enable the "dri2" useflag. For the kernel, I suggest getting the "drm-intel-next" branch from Eric Anholt's git tree : git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (see http://anholt.livejournal.com/39544.html for more information) As for getting this into portage, the answer is no :) Sorry. I _really_ don't want people to get the impression that GEM is ready for mass consumption. Nor do I want to support GEM in its current form. And until GEM bits become available in portage, bugs should go directly to FreeDesktop's bugzilla, using this detailed how-to: http://intellinuxgraphics.org/how_to_report_bug.html But please do add "remi@gentoo.org" as a CC so I can track these bugs, I still want to know about them :) Thanks
(In reply to comment #41) > (In reply to comment #40) > > ok, I'm running 2.6.28-rc3-zen1. Could you post a guide to try this out? It > > would be good to be able to do it entirely in portage :) > > > > I'm currently running mesa-7.0.3, xf86-video-intel-2.4.2, libdrm-2.3.0, > > xorg-server-1.4.2, xorg-x11-7.3, and I'm using a 965 on a Thinkpad T61. > > I don't want to sound like an elitist prick or anything, but actually getting > GEM to work is far from trivial. > > Basically, you'll need: > 1) a fully up to date 100% ~x86 or ~amd64 system, not a > half-stable-half-unstable one, > 2) you'll need to get -intel 2.5.0 to work (if that step fails, open a bug and > don't bother with GEM, it won't work either), > 3) _then_ you'll need to fetch the proper kernel (see below) > 4) you'll need -intel, mesa and xorg-server from the x11 overlay (with their > corresponding deps of course). Do *NOT* enable the "dri2" useflag. > > For the kernel, I suggest getting the "drm-intel-next" branch from Eric > Anholt's git tree : > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (see > http://anholt.livejournal.com/39544.html for more information) > > As for getting this into portage, the answer is no :) Sorry. I _really_ don't > want people to get the impression that GEM is ready for mass consumption. > > Nor do I want to support GEM in its current form. > > And until GEM bits become available in portage, bugs should go directly to > FreeDesktop's bugzilla, using this detailed how-to: > http://intellinuxgraphics.org/how_to_report_bug.html > > But please do add "remi@gentoo.org" as a CC so I can track these bugs, I still > want to know about them :) > > Thanks > I'm trying what you have say and it goes well, but I'm using a vanilla kernel (2.6.28-rc4). Also, sometimes, system freezes and I have to reboot it. I still don't know if it's fault of the X system or the kernel.
Not sure, if it helps, but my typical scenario is : 1) I can run the system without freeze for whole day 2) I suspend to ram (gnome-power-manager) 3) I resume 4) within 30 minutes or my X freezes... is not responding to keyboard at all, have to hard poweroff the system and reboot I have fully updated ~x86 system, intel graphics
(In reply to comment #43) > Not sure, if it helps, but my typical scenario is : > > 1) I can run the system without freeze for whole day > 2) I suspend to ram (gnome-power-manager) > 3) I resume > 4) within 30 minutes or my X freezes... is not responding to keyboard > at all, have to hard poweroff the system and reboot > > I have fully updated ~x86 system, intel graphics > Same as me, but without suspend. What kernel do yo use?
(In reply to comment #44) > (In reply to comment #43) > > Not sure, if it helps, but my typical scenario is : > > > > 1) I can run the system without freeze for whole day > > 2) I suspend to ram (gnome-power-manager) > > 3) I resume > > 4) within 30 minutes or my X freezes... is not responding to keyboard > > at all, have to hard poweroff the system and reboot > > > > I have fully updated ~x86 system, intel graphics > > > > Same as me, but without suspend. What kernel do yo use? > vanilla-2.6.28-rcX (X=2,3,4)
(In reply to comment #43) > Not sure, if it helps, but my typical scenario is : > > 1) I can run the system without freeze for whole day > 2) I suspend to ram (gnome-power-manager) > 3) I resume > 4) within 30 minutes or my X freezes... is not responding to keyboard > at all, have to hard poweroff the system and reboot > > I have fully updated ~x86 system, intel graphics > I've a vanilla kernel 2.6.27.4 and since the libdrm-2.4.1, my system freeze after maybe 10min after a resume (from ram or disk). The freeze seems to be keybaord and click related. My mouse cursor still moving over the screen, but keyboard nor clicks works I've to wait maybe ~3-5 min to let the system works again. All the keyboard key pressed or mouse clicks are buffered and played when the system "un-freeze". Then my linux works okay for the rest of the time (until i suspend to ram or disk again). So from my point of view, it's related to libdrm-2.4.1 upgrade. Hope this helps
IIRC I had that that issue even before the libdrm upgrade, this did not change anything on my system
My issue on freezing was gone with linux kernel 2.6.27.6 I've also upgraded to x11-drivers/xf86-video-intel-2.5.1 and my X11 seems to be more responsive. But still having the drawing issue (comment #35). In short; 2.5.1 seems better but not perfect ;)
I cannot stress this enough : *file bugs at FreeDesktop.org if you want your bugs fixed* Thanks :)
(In reply to comment #49) > I cannot stress this enough : > > *file bugs at FreeDesktop.org if you want your bugs fixed* > > Thanks :) > I've completed your bug report. Thanks for your advice, even if I didn't like to have dozen of bugzilla accounts ...
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. Source: http://archlinux.org/pipermail/arch-general/2008-November/018957.html That solution should increase graphics performance. Hopefully it will help someone, it helped me.
(In reply to comment #51) Didn't work for me, I'm stuck at 60fps which is my screen refresh rate. Intel 965GM xorg-x11-7.4 xorg-server-1.5 xf86-video-intel-2.4.2-r3 (direct rendering won't work with 2.5.0) mesa-7.2 $ glxgears -info Failed to initialize TTM buffer manager. Falling back to classic. GL_RENDERER = Mesa DRI Intel(R) 965GM 20061102 GL_VERSION = 1.4 Mesa 7.2 GL_VENDOR = Tungsten Graphics, Inc [...] 299 frames in 5.0 seconds = 59.643 FPS
(In reply to comment #52) > Didn't work for me, I'm stuck at 60fps which is my screen refresh rate. > ... > 299 frames in 5.0 seconds = 59.643 FPS > As told in comment #51, glxgear is not a performance monitor. Now that said, intel drivers (and probably other) now use your refresh rate to save some CPU cyles (there is no _real_ reasons to try to draw more often that your monitor can do ..). But it can save your CPU and some power (really usefull in laptop). You can try : __GL_SYNC_TO_VBLANK="0" glxgears
(In reply to comment #51) > 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. > Source: http://archlinux.org/pipermail/arch-general/2008-November/018957.html > > That solution should increase graphics performance. Hopefully it will help > someone, it helped me. > hey ! thank you - it increased FPS from 54 -> 540 :). Originally i had vblank_mode 3 ...
> You can try : > __GL_SYNC_TO_VBLANK="0" glxgears > Doesn't work... still 60 FPS.
I managed to disable vblank with x11-misc/driconf. The code from #51 didn't work because I left driver="i915" (thinking at the kernel module) while I had to set driver="i965".
(In reply to comment #56) > I managed to disable vblank with x11-misc/driconf. Congratulations on getting your system globally use more power than necessary by drawing more than the monitor can display, have tearing issues/glitches because the drawing is not synchronized to not coincidence with a scanout to display, etc :)
(In reply to comment #57) > (In reply to comment #56) > > I managed to disable vblank with x11-misc/driconf. > > Congratulations on getting your system globally use more power than necessary > by drawing more than the monitor can display, have tearing issues/glitches > because the drawing is not synchronized to not coincidence with a scanout to > display, etc :) > your sarcasm is completely unnecessary. My only objective was to verify that the fps went down to 500 (xorg-server-1.5.2) from 1200 (1.3). After the test, I re-enabled vsync.
Sorry, but glxgears is NOT a benchmark. glxgears is not a benchmark. glxgears is not a benchmark. Guys, please understand that. glxgears is only a quick test if the very basic 3D works or not. http://dri.freedesktop.org/wiki/Benchmarking lists some proper ways to measure 3D speed. Any claims about 3D getting slower with proof being glxgears numbers will be dismissed in a heartbeat upstream, but proper numbers from proper benchmarks tend to get looked at more seriously
(In reply to comment #55) > > You can try : > > __GL_SYNC_TO_VBLANK="0" glxgears > > > Doesn't work... still 60 FPS. > Try to add "export INTEL_BATCH=1" to your ~/.bashrc script
(In reply to comment #59) Since there is some emphatic insistence about glxgears not being a benchmark, I'll provide some benchmark data. Regardless what upstream says, glxgears is a good indicator when something is broken. That's why nobody is presenting benchmark data, it's really not necessary to show when something isn't working as it should. DRI is working fairly well on my system currently, but no where near where it should be performing. Intel 965GM Chipset Portage 2.1.4.5 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.27 i686) With the following setup: media-libs/mesa-7.0.3 x11-drivers/xf86-video-intel-2.4.3 x11-libs/libdrm-2.3.1 x11-base/xorg-server-1.4.2 Benchmark result using Q3demo: 1346 frames, 12.9 seconds: 104.1 fps With the following setup: media-libs/mesa-7.2 x11-drivers/xf86-video-intel-2.5.1 x11-libs/libdrm-2.4.1 x11-base/xorg-server-1.5.2 Benchmark result using Q3demo: xorg-server-1.5: 1346 frames, 14.6 seconds: 92.4 fps The latest drivers are quite a bit more stable, so I've kept with the second setup even though it's a bit slower. Every package marked "stable" in the tree currently is very broken on this hardware and extremely buggy, with frame rates about half for the above test. There is absolutely no reason this hardware shouldn't easily get much higher framerates based on the hardware specs. What's even worse is the fact that there are a handful of older 64M video cards that can best this benchmark and even some ancient 32M cards. There is a diligent effort to fix this stuff upstream. I'm not sure filing more bugs upstream to point out that it is broken will tell them something they don't already know. Hopefully this bug can serve to show what stable setups people have with intel cards. I seriously doubt there is a quick fix for the moment. Will have to wait for upstream to stabilize this latest set of major changes.
Linux 2.6.28 is out, and the x11-drivers/xf86-video-intel-2.5.1-r1 is working on my laptop. Little bit faster (maybe related to kernel itself, not on the video part). Refresh bug in comment #35 (see #38 for upstream report) still in effect on my laptop.
(In reply to comment #62) > Linux 2.6.28 is out, and the x11-drivers/xf86-video-intel-2.5.1-r1 is working > on my laptop. Little bit faster (maybe related to kernel itself, not on the > video part). Thanks for testing, I appreciate it. > Refresh bug in comment #35 (see #38 for upstream report) still in effect on my > laptop. Yeah, nothing's changed on my laptop either in the past couple of weeks. I guess we'll just have to wait (or bite the bullet and ditch our old 855 laptops to buy new ones...) Thanks :)
Updated to 2.6.28 Fully updated ~x86 With glxgears I still get: Failed to initialize TTM buffer manager. Falling back to classic. GL_RENDERER = Mesa DRI Intel(R) 945GME 20061102 x86/MMX/SSE2 GL_VERSION = 1.4 Mesa 7.2 GL_VENDOR = Tungsten Graphics, Inc and 60 FPS cap I thought that with 2.6.28 this was to be solved. Anyone else still having this issue after 2.6.28? I think I am missing something. Any more ideas on fixing 3D and the TTM issue? Thanks so much, ~Constrabus
(In reply to comment #64) > Updated to 2.6.28 > Fully updated ~x86 > > With glxgears I still get: > Failed to initialize TTM buffer manager. Falling back to classic. > GL_RENDERER = Mesa DRI Intel(R) 945GME 20061102 x86/MMX/SSE2 > GL_VERSION = 1.4 Mesa 7.2 > GL_VENDOR = Tungsten Graphics, Inc Normal, Mesa 7.2 doesn't support GEM. Otherwise, it would show up in GL_RENDERER. You'll need an unreleased version of mesa for this to work properly. > 60 FPS cap Again, normal. vblank-sync has been turned on by default now. You can disable it using x11-misc/driconf. > I thought that with 2.6.28 this was to be solved. Only the kernel bits are solved with 2.6.28. Basically, for all issues to be gone, we'll have to wait for xorg-server 1.6 and mesa 7.3/7.4. > Any more ideas on fixing 3D and the TTM issue? Try the -9999 ebuilds from the "x11" overlay and report any bugs you might have to http://bugs.freedesktop.org/. Beware though, there's a lot of experimental stuff in there. Use at your own risk. Thanks
On Gentoo-2.6.28 Kernel & Intel-2.5.1-r1 & Xorg-1.5.3 & mesa-7.2 things have quite worsened for me. Once I start an 3d application (like compiz) my whole system freezes. When downgrading to Intel-2.4.3 compiz works. But once I suspend the system or anything it will hang... :( Downgrading to mesa 7.0.3 & xorg 1.4.3 & libdrm 2.3 atm :(
Switching to UXA acc. method makes things worst on my 855GM. So my reccomendation is to stay with the following versions : x11-drivers/xf86-video-intel-2.4.3 x11-base/xorg-server-1.4.2
Let me summarize the current state of things as I understand it. Please correct me if I am off-base: 1) linux 2.6.28 supports GEM in the Intel DRI driver 2) xf86-video-intel, as of 2.5.x, has code that supports GEM 3) xorg-server 1.5 does not properly support GEM at this time 4) mesa 7.2 does not support GEM, but mesa 7.3 or 7.4 *might* 5) When {3, 4} are fixed GEM support will work Clarifications?
xorg-server is fine, the only bit needed is mesa from git at the moment. I hope a new mesa release will happen soon.
Would I be correct them in saying that mesa from git would resolve things? git clone git://anongit.freedesktop.org/git/mesa/mesa I believe there is also a mesa-9999 ebuild in the x11 overlay. With the latest (unstable) mesa will this work?
(In reply to comment #68) > Let me summarize the current state of things as I understand it. Please > correct me if I am off-base: > > 1) linux 2.6.28 supports GEM in the Intel DRI driver True. If gentoo-sources works, stick with it. > 2) xf86-video-intel, as of 2.5.x, has code that supports GEM 2.5 has GEM support but 2.6 has seen a *lot* of bug fix. Using is definitely recommended (by me ;) ) > 3) xorg-server 1.5 does not properly support GEM at this time As Hanno said, xorg-server has nothing to do with GEM. It's a driver-only issue. > 4) mesa 7.2 does not support GEM, but mesa 7.3 or 7.4 *might* s/might/will/. But on some chips, mesa 7.2 may still work using its old behavior. So you get a X driver that uses GEM and 3D apps that don't use it... Complicated, I know :) > 5) When {3, 4} are fixed GEM support will work If you want to help debug GEM and report bugs upstream, I suggest you add the "x11" overlay using layman, unmask xf86-video-intel-2.5.99.x, mesa-9999 and their deps. That way, you'll be pretty close to what should be released within the next few weeks. Right now, the release of Xorg 1.6 is blocked by : - the final DRI2 spec/libraries - the last round of DRI2 driver fixes - mesa having a new release. Thanks
I'm interested in this, my AIGLX is reverting to software rendering with 2.6.28 (git-sources) and I'm compiling new xserver from x11 overlay to see if it helps.
(In reply to comment #71) > > 2) xf86-video-intel, as of 2.5.x, has code that supports GEM > > 2.5 has GEM support but 2.6 has seen a *lot* of bug fix. Using is definitely > recommended (by me ;) ) I tried to compile 2.5.99.1 from the x11 overlay. It fails with: In file included from /usr/include/xorg/edid.h:15, from bios_reader.c:46: /usr/include/X11/Xmd.h:152: error: conflicting types for 'CARD32' Well, a very similar error has once been fixed for xf86-video-intel-2.5.1 - i think the fix was 2.5.1-0002-include-X11-Xmd.h-to-define-CARD16-needed-by-edid.patch. I tried to modify the ebuild in the overlay, but i didn't get very far. The patch was rejected, and i didn't try harder to make it work, yet. Just wanted to let you know.
Created attachment 177612 [details] X log when the problem happen.
Created attachment 177614 [details] dmesg of 2.6.28-git7 with Kernel Mode Settings enabled. This is for a macbook 4,1 with Intel 965 chipset.
I tried sys-kernel/git-sources-2.6.28-r7 with KMS activated and x11 overlay and it didn't work. The framebuffer is set to 1280x800 (my LCD resolution), but X cannot start with the following message: (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB ... (WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device or resource busy) (EE) GARTInit: AGPIOC_INFO failed (Invalid argument) (WW) intel(0): /dev/agpgart is either not available, or no memory is available for allocation. Using pre-allocated memory only. (WW) intel(0): DRI2 requires UXA ... (EE) intel(0): Failed to allocate space for kernel memory manager (==) intel(0): VideoRam: 15868 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Tiled allocation failed. (II) intel(0): Attempting memory allocation with untiled buffers. (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Untiled allocation failed. (II) intel(0): Couldn't allocate 3D memory, disabling DRI. (II) intel(0): Attempting memory allocation with untiled buffers. (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Untiled allocation failed. (EE) intel(0): Couldn't allocate video memory Kernel dmesg show some info, warnings and errors as well: Kernel command line: ro root=/dev/ram0 real_root=/dev/all/root quiet video=intelfb:mode=1280x800-32,accel,hwcursor,mtrr dolvm lpj=2393878 nodetect ... Linux agpgart interface v0.103 agpgart-intel 0000:00:00.0: Intel 965GM Chipset agpgart-intel 0000:00:00.0: detected 15868K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0x80000000 [drm] Initialized drm 1.1.0 20060810 ------------[ cut here ]------------ WARNING: at drivers/gpu/drm/drm_crtc.c:213 drm_mode_object_get+0x38/0x93() Hardware name: MacBook4,1 drm_mode_object_get called w/o mode_config lock Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28-git7 #2 Call Trace: [<c0226316>] warn_slowpath+0x71/0xa8 [<c0444d52>] ? schedule+0x8a6/0x8e2 [<c02e661a>] ? __udelay+0x32/0x34 [<c03cbe95>] ? i2c_stop+0x3a/0x3e [<c03cc4c8>] ? bit_xfer+0x378/0x382 [<c022dc64>] ? lock_timer_base+0x1f/0x3e [<c022dccb>] ? try_to_del_timer_sync+0x48/0x4f [<c022dcdf>] ? del_timer_sync+0xd/0x18 [<c044506e>] ? schedule_timeout+0xa6/0xbc [<c022d975>] ? process_timeout+0x0/0xa [<c03530b6>] drm_mode_object_get+0x38/0x93 [<c03531f1>] drm_mode_connector_update_edid_property+0xe0/0x156 [<c036392f>] intel_ddc_get_modes+0x27/0x40 [<c03623a7>] intel_lvds_init+0xe5/0x272 [<c03611b8>] intel_modeset_init+0x32e/0x579 [<c034de7b>] ? drm_irq_install+0xf0/0x11f [<c0357fe4>] i915_driver_load+0x686/0x6d6 [<c034fd30>] drm_get_dev+0x2be/0x359 [<c034bc7b>] drm_init+0x66/0x9b [<c059b11e>] i915_init+0x46/0x48 [<c0201132>] _stext+0x4a/0x10c [<c059b0d8>] ? i915_init+0x0/0x48 [<c024ce09>] ? register_irq_proc+0x7f/0x9b [<c024ce78>] ? init_irq_proc+0x53/0x60 [<c057e300>] kernel_init+0x105/0x156 [<c057e1fb>] ? kernel_init+0x0/0x156 [<c020359b>] kernel_thread_helper+0x7/0x10 ---[ end trace f98088819d95879c ]--- ------------[ cut here ]------------ [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [drm] TV-15: set mode NTSC 480i 0 [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1 [drm] LVDS-8: set mode 1280x800 17 Console: switching to colour frame buffer device 160x50 fb0: inteldrmfb frame buffer device registered panic notifier [drm] Initialized i915 1.6.0 20080730 on minor 0 intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM chipsets intelfb: Version 0.9.6 intelfb: 00:02.0: Intel(R) 965GM, aperture size 256MB, stolen memory 16124kB intelfb: Cannot remap FB region. I guess the traceback (some others like that are displayed) or the error about vblank are not related, but I'm afraid the "Cannot remap FB region" is bad. For full logs, see my attachments.
Please stop posting new issues here. If you have any issues, please open *new* bugs either here or in freedesktop's bugzilla. If you do open bugs upstream, please add "remi@gentoo.org" as a CC so that I can keep track of them. And for the record, KMS *just* entered Linus's git tree. It's way more experimental than GEM. If you use KMS, things *will* break. You have all be warned :) Thanks
Please open a new bug if you want to solve a particular issue wich is out of the scope (not really, but not really on the topic here). (In reply to comment #73) > I tried to compile 2.5.99.1 from the x11 overlay. It fails with: > In file included from /usr/include/xorg/edid.h:15, > from bios_reader.c:46: > /usr/include/X11/Xmd.h:152: error: conflicting types for 'CARD32' > > Well, a very similar error has once been fixed for xf86-video-intel-2.5.1 - i > think the fix was > 2.5.1-0002-include-X11-Xmd.h-to-define-CARD16-needed-by-edid.patch. > > I tried to modify the ebuild in the overlay, but i didn't get very far. The > patch was rejected, and i didn't try harder to make it work, yet. > > Just wanted to let you know. > You pointed the right area, but not the right patch. If you want to install a experimental video driver, I strongly suggest that you use xorg-server-9999. CARD32 is well defined with the -9999 series. But, on my 855 video card, X just core dump, and I've not enough time to debug it.
From issue in comment #35 (In reply to comment #38) > (In reply to comment #37) > > Intel 82852/855GM rev 02 > > Bingo. Here's the bug's URL if you want to watch it too :) > > http://bugs.freedesktop.org/show_bug.cgi?id=18138 Remi, thanks for the libdrm-2.4.3 wich seems to be better on the screen refresh error. Fonts double glyphs stay here. I'll update upstream bug with that info too.
Sorry posting about multiple things at once. Here goes the last bit of my status, don't consider it as another issue, just reporting for other users. For the record, with 2.6.28-git7: - KMS really break things today, I managed to get X to start without any flickering, wonderful... until it crashed my machine minutes later. - Need to remember to set your xorg.conf: Option "AccelMethod" "UXA", otherwise it will use EXA. - xorg-server-1.5.3 + UXA will break xrender and thus cairo and thus gtk and thus mozilla... - xorg-server-1.5.3 AIGLX falls back to software rendering due an drmMap error. - xorg-server-9999 breaks randomly, but seems to have AIGLX working, at least no drmMap error, however glxinfo says it's using software rasterizer and vendor is SGI. - xorg-server-9999 often fails to load appletouch input device. I masked (actually removed my unmasking) the whole x11 overlay and back to 1.5.3 as it really seems more usable. Only drawback is the software rasterizer for AIGLX.
mesa 7.3-rc1 is out, xorg-team: Maybe add this masked to the portage-tree? As this issue is hitting so many people (pretty much all with intel cards).
Ok guys, I'll be closing this bug fixed for 2 reasons : 1) there's nothing new to add here, and 80+ comments are already hard to track 2) everything needed to fix this is available in the x11 overlay without any -9999 packages, just add the x11 overlay and update @world. A couple extra notes : - don't try KMS, unless you want to report bugs to freedesktop - packages will be going to portage as soon as mesa gets more testing, possibly another beta release, but all packages in the overlay are nearing completion. If you have any issues with those packages, please leave this bug alone and open *new* bugs to avoid bothering the 30+ people in the CC list. Thanks for your patience.
Stumbled on this thread while trying to figure out why googleearth runs at slide-show speeds on my eeepc-901... kernel 2.6.28-r1, xorg-server-1.5.3-r1, mesa-7.2, 945GME chip, glxgears showing 190-280 fps yet still complains about TTM. The only conclusion I can draw is that the chapter on X-Windows (sic) in the unix haters handbook is long due for an update, I think it could even deserve its own section by now :)
Please read over the rest of the thread carefully. It states that, although intel-2.5.0 will work, you should be using the latest -testing (e.g. 2.6.1 minimum). If you has read the rest of the thread carefully you would also know that mesa 7.3 is required. You can get all this stuff from the x11 overlay in layman.
