This may well be due to using media-video/ati-drivers, but I don't have another 3d PCI-E card to verify this with. Launching apps from point2play (and using cedega directly) causes wine to start without any 3d acceleration. The 'system tests' in point2play demonstrate this, noting that the gl_test renders in software. Calling Point2Play from a shell with the following commandline enables acceleration: LIBGL_DRIVERS_PATH=/usr/lib32/modules/dri/ Point2Play My guess is that it's because the ATI libGL is unable to find the 32-bit DSOs. Could possibly put a: if [ -e /usr/lib32/modules/dri/fglrx_dri.so ]; then export LIBGL_DRIVERS_PATH=/usr/lib32/modules/dri fi Into the Point2Play launcher, but this doesn't account for if the fglrx driver is being used in Xorg. Reproducible: Always Steps to Reproduce: 1. Launch Point2Play on amd64 native system 2. Tools menu -> System Tests -> Run All 3. Click 'run tests' Actual Results: 3d acceleration test failed Expected Results: Should have passed Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r7 x86_64) ================================================================= System uname: 2.6.12-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 4000+ Gentoo Base System version 1.6.13 dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa avi bash-completion berkdb bitmap-fonts cdr crypt cups curl dvd dvdr eds encode fam firefox flac font-server foomaticdb fortran gdbm gif glut gnome gpm gstreamer gtk2 imlib ipv6 jpeg ldap lzw lzw-tiff mad mikmod mp3 mpeg ncurses nls ogg opengl pam pdflib perl png python quicktime readline sdl slang speex spell ssl tcltk tcpd tiff truetype-fonts type1-fonts usb userlocales vorbis xml2 xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
The Games Team doesn't support Windows gaming...
Same here with linux32 quake3 and linux32 doom3 ... The emul package always point to the Mesa whatever the opengl-update is set to. (e.g. 'ati'). alias linux32='LIBGL_DRIVERS_DIR=/usr/X11R6/lib32/modules/dri /bin/linux32' It isn't limited to Windows gaming under cedega/point2play.
AMD64, is this intentional?
AFAIK opengl client applications load their dri modules from a path that is inherited from the libGL.so library. For the binary ati libGL.so this is hardcoded to /usr/X11R6/lib/modules/dri: $ strings /usr/lib32/opengl/ati/lib/libGL.so.1.2 | grep modules/dri /usr/X11R6/lib/modules/dri This is probably because most other distros install their 32bit libs in /lib and 64bit in /lib64 (this is also the FHS standard and we do plan on moving to this in the future). In Gentoo right now we install 32bit libs in lib32 which is why the client app is unable to find the dri library. We could either try to correct this with sed in the ati-drivers ebuild or install and env.d file defining: LIBGL_DRIVERS_PATH="/usr/$(get_multilibdir)/modules/dri/:/usr/$(get_libdir)/modules/dri"
Thanks Herbie :) Is this only ATI causing the problem? Anyone here with nVidia having issues?
Nvidia does not install/use a dri module. So no, no such issue there.
As of ati-drivers-8.14.13-r5 LIBGL_DRIVERS_PATH is now set in the env.d file. Fixed in CVS, thanks for reporting.