Bugzilla Bug 290153

When running a 32bit OpenGL application on i965 hardware, it's slow because
it's falling back to software.

The issue is that app-emulation/emul-linux-x86-xlibs-20081109 contains very old
mesa binaries and i965 isn't even included in this.

Hello,
this post to confirm what was said previously, using i915 driver.
Shouldn't mesa ebuild compile 32-bit opengl library too when used with
"multilibs" USE-flag ?

emul-linux-x86-xlibs-20091004 didn't solve the problem !

(In reply to comment #1)
> Hello,
> this post to confirm what was said previously, using i915 driver.
> Shouldn't mesa ebuild compile 32-bit opengl library too when used with
> "multilibs" USE-flag ?
> 

Mesa doesn't have multilib use flag.
What is the current status/opinion of amd64 team on this issue?

Oleg

*** Bug 293529 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> emul-linux-x86-xlibs-20091004 didn't solve the problem !
> 

emul-linux-x86-*-20091004 is hardmasked out at the moment for killing puppies
apparently -- however I will give this lot a shot to see if it WFM.

  Anyone have suggestions on best way to pull this off?

(In reply to comment #5)
> (In reply to comment #2)
> > emul-linux-x86-xlibs-20091004 didn't solve the problem !
<snip>
>   Anyone have suggestions on best way to pull this off?
> 

 Okay -- commented emul-linux-x86-* lines out of
/usr/portage/profiles/package.mask, 
 then added 
app-emulation/emul-linux-x86-xlibs ~amd64
app-emulation/emul-linux-x86-baselibs ~amd64

  to /etc/portage/package.keywords/wine 
(where I have the overrides for my wine build which requires this)

  and emerged.

the emerge complained about a file collision on /usr/lib32/libGLU* , but
couldn't find an owner, so proceeded:

This all looks *very* good -- especially since it rather looks like libGLU
matches its 64bit companion, and all the dri/*.so drivers appear matched.

 ls -l /usr/lib32/dri/
total 34856
-rwxr-xr-x 1 root root 2163340 Nov 22 16:11 i810_dri.so
-rwxr-xr-x 1 root root 2433836 Nov 22 16:11 i915_dri.so
-rwxr-xr-x 1 root root 2516524 Nov 22 16:11 i965_dri.so
-rwxr-xr-x 1 root root 2249028 Oct  3 14:15 mach64_dri.so
-rwxr-xr-x 1 root root 2298276 Oct  3 14:15 mga_dri.so
-rwxr-xr-x 1 root root 2167108 Oct  3 14:15 r128_dri.so
-rwxr-xr-x 1 root root 2231972 Oct  3 14:15 r200_dri.so
-rwxr-xr-x 1 root root 2232900 Oct  3 14:15 r300_dri.so
-rwxr-xr-x 1 root root 2201156 Oct  3 14:15 radeon_dri.so
-rwxr-xr-x 1 root root 2154724 Oct  3 14:15 s3v_dri.so
-rwxr-xr-x 1 root root 2224996 Oct  3 14:15 savage_dri.so
-rwxr-xr-x 1 root root 2228676 Oct  3 14:15 sis_dri.so
-rwxr-xr-x 1 root root 2006960 Oct  3 14:15 swrast_dri.so
-rwxr-xr-x 1 root root 2220388 Oct  3 14:15 tdfx_dri.so
-rwxr-xr-x 1 root root 2091044 Oct  3 14:15 trident_dri.so
-rwxr-xr-x 1 root root 2158980 Oct  3 14:15 unichrome_dri.so
atonner@lrssbra0240 ~ $ ls -l /usr/lib32/
Display all 574 possibilities? (y or n)
atonner@lrssbra0240 ~ $ ls -l /usr/lib32/x
ls: cannot access /usr/lib32/x: No such file or directory
atonner@lrssbra0240 ~ $ ls -l /usr/lib32/libGL*
-rw-r--r-- 1 root root    723 Nov 23 19:30 /usr/lib32/libGL.la
lrwxrwxrwx 1 root root     30 Nov 23 19:30 /usr/lib32/libGL.so ->
./opengl/xorg-x11/lib/libGL.so
-rw-r--r-- 1 root root    743 Nov 22 16:11 /usr/lib32/libGLU.la
lrwxrwxrwx 1 root root     11 Nov 23 19:30 /usr/lib32/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root     20 Nov 23 19:31 /usr/lib32/libGLU.so.1 ->
libGLU.so.1.3.070502
-rwxr-xr-x 1 root root 443920 Oct  3 14:15 /usr/lib32/libGLU.so.1.3.070300
-rwxr-xr-x 1 root root 427564 Nov 22 16:11 /usr/lib32/libGLU.so.1.3.070502
atonner@lrssbra0240 ~ $ ls -l /usr/lib/libGLU*
-rw-r--r-- 1 root root    743 Nov 18 21:53 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root     11 Nov 18 21:53 /usr/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root     20 Nov 18 21:53 /usr/lib/libGLU.so.1 ->
libGLU.so.1.3.070502
-rwxr-xr-x 1 root root 436712 Nov 18 21:53 /usr/lib/libGLU.so.1.3.070502

   Currently rebuilding my wine against this since I somehow suspect that the
libGL that it finds in /usr/lib32/opengl/ is what it links against -- but I of
course am guessing.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > emul-linux-x86-xlibs-20091004 didn't solve the problem !
>

   export LIBGL_DEBUG=verbose
   WINEDBG=+wgl wine /path/to/32bit/game >debuglog.log 2>&1

  I end up whacking myself on head since it seems I left my
/usr/lib32/dri/i965_dri.so from a test build in chroot lying around.

> > > (In reply to comment #2)
> > > > emul-linux-x86-xlibs-20091004 didn't solve the problem !
> >
This ebuild does not include the intel drivers (i810/i915/i965)_dri.so 
and building the intel drivers in a 32bit chroot (chroot built with same
portage rules/make.conf as the 64bit parent) ends up with the dlopen of the
i965_dri.so complaining about a missing symbol.

If someone were to give me a hint as to what was used in the build of the
emul-linux-x86-xlibs I'd be willing to take a shot at building xf86-video-intel
to match it and add those ...


   From what I can tell here, 32bit binaries on amd64 systems will NOT be able
to run opengl on intel chipsets.



> 

>    Currently rebuilding my wine against this since I somehow suspect that the
> libGL that it finds in /usr/lib32/opengl/ is what it links against -- but I of
> course am guessing.

Hello. What I did to figure that out is : launch a wine app, and then switch to
a console and use "lsof -p `pgrep wine` | grep GL". (Except if you are talking
about static link ?)

If there is any test I could do that would be useful, just tell me !