This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Indirect OpenGL acceleration - New notes
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygx <cygwin-xfree at cygwin dot com>
- Date: Sun, 29 Feb 2004 22:47:49 -0500
- Subject: Indirect OpenGL acceleration - New notes
- Reply-to: cygwin-xfree at cygwin dot com
I posted some new and simplified notes on how to add indirect OpenGL
acceleration to Cygwin/X:
http://msu.edu/~huntharo/xwin/devel/server/CygwinX-Accelerated-OpenGL-Support-20040229.pdf
In addition, I have checked in the build framework for this into our
tree on freedesktop.org. You can find more information about our tree
on fd.o from this page:
http://x.cygwin.com/devel/server/
All you have to do to enable the indirect OpenGL acceleration build
framework is to edit xc/config/cf/cygwin.cf and change GlxUseWindows
from NO to YES. Then, if you don't want to rebuild the entire tree,
just do the following:
cd programs/Xserver
make Makefile
cd GL
make Makefile
make Makefiles
cd ..
make XWin.exe
That should result in a compilation of the currently empty
GL/windows/indirect.c file, which will cause XWin.exe to fail to link
since it can't find the OpenGL functions. I am a little confused about
why XWin.exe fails to link on so many functions, since it seems that
-lopengl32 is providing those functions (look some of them up via 'nm -g
/usr/lib/w32api/opengl32.a | grep function_name')... I could use a few
pointers on what is happening there.
Implementing indirect acceleration is a required first step to
implementing direct (DRI) acceleration because indirect acceleration is
used by clients that are across the network from the X Server, so you
always have to provide an indirect interface for network clients to fall
back on. DRI could come later if we find that the performance of the
indirect rendering is not acceptable. However, DRI will be considerably
more complex since both the X Server process and the client application
process will need to be able to write to the same OpenGL surface (as
explained to me by Torrey Lyons of X on X fame). X on X got lucky:
Apple wrote them an extension to the OS to provide this functionality :)
We may or may not have a problem with two applications trying to write
to the same surface in Windows; if it is not possible, then there may be
nothing we can do to work around it. Thus, indirect rendering is now
doubly attractive as a starting point since we know it is possible.
Harold