Re: X11 OpenGL and Wine
Re: X11 OpenGL and Wine
- Subject: Re: X11 OpenGL and Wine
- From: Ben Byer <email@hidden>
- Date: Sat, 10 Nov 2007 21:26:52 -0800
On Nov 10, 2007, at 2:52 PM, Ryan Walklin wrote:
I've been trying to get Wine up and running under Leopard (Intel) for
a wee while now. I needed to use the LDFLAG workaround (export
LDFLAGS="-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/
Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/
OpenGL.framework/Versions/A/Libraries/libGL.dylib")
so that the Wine configure script can find libGL.dylib under
/usr/X11/lib, and then set DYLD_FALLBACK_LIBRARY_PATH (export
DYLD_FALLBACK_LIBRARY_PATH="$HOME/lib:/usr/local/lib:/usr/lib:/usr/
X11/lib")
so that Wine can find various X11 extensions (XRENDER in particular).
Normal Windows apps that run under linux work fine, however attempting
to run anything requiring OpenGL (Steam for example) fails with the
error:
I'm not *positive* this is the problem, but I want to clear a couple
of things up first so that we can eliminate them as potential problem
causes.
1. In the Wine bugzilla bug, you mentioned this:
More correctly Wine should link to
/System/Library/Frameworks/OpenGL.Framework/Versions/A/Libraries/
OpenGL.dylib,
as the /usr/X11/lib library consists of links to the Framework. This
can be
achieved by directly linking to the framework (-Framework OpenGL -
framework
GLUT) rather than -lGL and -lGLU on OS X.
I've seen this mentioned before, but this is incorrect. Link against /
usr/X11/lib/libGL.dylib. Do not link to OpenGL framework. Use that
workaround (LDFLAGS="-Wl,-dylib_file,/System/Library/Frameworks/
OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/
Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib") as a
magical incantation to work around a bug in ld64. Do not try to link
against OpenGL.framework unless you are a native Cocoa/Carbon app.
Explanation: OpenGL in X11 is done using an extension call GLX.
There are three ways to implement GLX (all should look the same to the
X client, but some understanding of the internals might help):
* Software 3D rendering: /usr/X11/lib/libGL.dylib includes a copy of
the Mesa3D library which can render your polygons in software, and
then just send them to the X server as simple 2d operations. This is
a fallback mechanism, and very slow, but will always work -- the
server never even knows you're using OpenGL.
* Accelerated Indirect GLX (aka AIGLX) -- /usr/X11/lib/libGL.dylib
contains code which takes each OpenGL call, serializes it and puts it
into a GLX packet which it sends over the wire to the X server. The
server decodes it, recognizes it as an OpenGL command, and then calls
OpenGL.framework/.../libGL.dylib with the parameters that the client
passed to /usr/X11/lib/libGL.dylib. This is faster, but requires
server support for OpenGL, which is something that didn't work until
about 6 months ago in Leopard.
* Direct Rendering Interface (DRI) -- in this mode, /usr/X11/lib/
libGL.dylib sends a packet using the DRI extension over the wire to
the X server, but this packet is fairly simple -- it says "reserve a
blank window on the screen for me with these dimensions and at this
position". The X server replies back with a handle that allows the X
client to draw on that window (aka "surface"). /usr/X11/lib/
libGL.dylib then makes calls directly into OpenGL.framework/.../
libGL.dylib to draw onto that surface. This is even faster than
AIGLX, but only works if the client and server are on the same machine.
Theoretically, /usr/X11/lib/libGL.dylib handles all of the above for
you automatically, choosing the fastest available method. Originally
(during Leopard's development), we only supported software rendering.
Eventually, we got AIGLX working. It was then brought to our
attention that AIGLX was significantly slower than DRI with X11 on
Tiger, so I eventually had to implement DRI. In order to do so, we
had to revert back to the /usr/X11/lib/libGL.dylib from Tiger, because
recent versions of Mesa don't support AppleDRI. When we went to do
that, we discovered that ld64 did not like the fact that we had a
dylib linking to another dylib with the same name, but there was no
time to fix this before Leopard's release. Hence, the workaround.
2. Why do you need to set DYLD_FALLBACK_PATH? That way be dragons;
that's why Gimp-2.2 doesn't work on Leopard. It's a measure of last
resort. We should be able to find a better way.
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden