Harold L Hunt II | 1 Mar 04:47 2004
Picon

Indirect OpenGL acceleration - New notes

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


Gmane