Notes on adding accelerated OpenGL support to Cygwin/X

Notes on adding accelerated OpenGL support to Cygwin/X

[Harold L Hunt II]

I assume that a lot of users and potential users are interested in 
accelerated OpenGL support.  Adding this isn't particularly hard, since 
we simply pass off OpenGL calls to the Win32 OpenGL system and because 
the Xdarwin (a.k.a. X on X, a.k.a. Apple) have already done a very 
similar system for their platform.

I am interested in adding this support as well, but I think it would be 
nice if some users and/or developers out there would help get this 
started by creating some of the boilerplate files for me and ensuring 
that these initial files compile correctly (although they will not do 
anything and might not link correctly).

I have put together a one page set of notes on the files that we need to 
adapt to our platform and the minor changes to the build system that we 
need to make to get those files to build:

http://msu.edu/~huntharo/xwin/devel/server/CygwinX-Accelerated-OpenGL-Support-20040128.pdf 
  (44 KiB)


These notes apply to the CYGWIN tag on the xorg repository that lives at 
freedesktop.org.  See the XWin Server development page for information 
on how to check out a tree:

http://x.cygwin.com/devel/server/


I encourage everyone to take a shot at this.  Most of the tasks marked 
as "Boilerplate", "Trivial", and "Easy" could be done by someone with no 
real knowledge of programming at all.  Now is your chance to jump in and 
start building your knowledge of programming.

Harold

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Brian Ford]

On Thu, 29 Jan 2004, Harold L Hunt II wrote:

> I am interested in adding this support as well, but I think it would be
> nice if some users and/or developers out there would help get this
> started by creating some of the boilerplate files for me and ensuring
> that these initial files compile correctly (although they will not do
> anything and might not link correctly).
>
I don't want to discourage anyone, but this is to let you know I am
trying to work this in "my spare time" :-).

> I have put together a one page set of notes on the files that we need to
> adapt to our platform and the minor changes to the build system that we
> need to make to get those files to build:
>
> http://msu.edu/~huntharo/xwin/devel/server/CygwinX-Accelerated-OpenGL-Support-20040128.pdf
>   (44 KiB)
>
Thanks for the notes.  I have
looked at this on and off for a year or two but always got lost quickly.

> These notes apply to the CYGWIN tag on the xorg repository that lives at
> freedesktop.org.  See the XWin Server development page for information
> on how to check out a tree:
>
> http://x.cygwin.com/devel/server/
>
Just built it for the first time :-).

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Alan Hourihane]

One note Harold on this....

You'll find that a lot of OpenGL drivers that are used on Windows are
seriously lagging behind in support for the hardware. That's because
a lot of vendors don't bother updating support for OpenGL directly
and are more interested in Direct3D.

Just run a native 'glinfo' application and you'll see that ATI and nVidia
are pretty good in this area and provide very up-to-date OpenGL drivers.
But others aren't so great.

Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa
that allows it to accept the OpenGL commands from the client and call
the equivalent Direct3D counterparts thus providing hardware that has
a more capable Direct3D layer much more benefit.

I think Karl Schultz on the Mesa list has the code and is integrating it,
but I don't know the status. You may want to contact him.

You won't need this to get started though, but it's certainly worth
investigating once you've got an initial implementation.

Alan.

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Brian Ford]

On Fri, 30 Jan 2004, Alan Hourihane wrote:

> One note Harold on this....
>
> You'll find that a lot of OpenGL drivers that are used on Windows are
> seriously lagging behind in support for the hardware. That's because
> a lot of vendors don't bother updating support for OpenGL directly
> and are more interested in Direct3D.
>
That is probably because Microsoft does the same.  They only ship/support
OpenGL 1.1.  Everything else is an extension that needs to be loaded
manually via GetProcAddress.

> Just run a native 'glinfo' application and you'll see that ATI and nVidia
> are pretty good in this area and provide very up-to-date OpenGL drivers.
> But others aren't so great.
>
But, you still have to jump through the GetProcAddress hoops to get there,
even with ATI and nVidia because of the base layer that Microsoft
provides.

> Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa
> that allows it to accept the OpenGL commands from the client and call
> the equivalent Direct3D counterparts thus providing hardware that has
> a more capable Direct3D layer much more benefit.
>
> I think Karl Schultz on the Mesa list has the code and is integrating it,
> but I don't know the status. You may want to contact him.
>
> You won't need this to get started though, but it's certainly worth
> investigating once you've got an initial implementation.
>
This would be a good option to have, but I wouldn't make it exclusive.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Alan Hourihane]

On Fri, Jan 30, 2004 at 11:11:41AM -0600, Brian Ford wrote:
> On Fri, 30 Jan 2004, Alan Hourihane wrote:
> 
> > One note Harold on this....
> >
> > You'll find that a lot of OpenGL drivers that are used on Windows are
> > seriously lagging behind in support for the hardware. That's because
> > a lot of vendors don't bother updating support for OpenGL directly
> > and are more interested in Direct3D.
> >
> That is probably because Microsoft does the same.  They only ship/support
> OpenGL 1.1.  Everything else is an extension that needs to be loaded
> manually via GetProcAddress.
 
Exactly. An ATI and nVidia do support later versions of OpenGL via this 
method.

> > Just run a native 'glinfo' application and you'll see that ATI and nVidia
> > are pretty good in this area and provide very up-to-date OpenGL drivers.
> > But others aren't so great.
> >
> But, you still have to jump through the GetProcAddress hoops to get there,
> even with ATI and nVidia because of the base layer that Microsoft
> provides.

Exactly again. It's not impossible though.

> > Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa
> > that allows it to accept the OpenGL commands from the client and call
> > the equivalent Direct3D counterparts thus providing hardware that has
> > a more capable Direct3D layer much more benefit.
> >
> > I think Karl Schultz on the Mesa list has the code and is integrating it,
> > but I don't know the status. You may want to contact him.
> >
> > You won't need this to get started though, but it's certainly worth
> > investigating once you've got an initial implementation.
> >
> This would be a good option to have, but I wouldn't make it exclusive.

No, but as an option.

Alan.

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Alexander Gottwald]

On Fri, 30 Jan 2004, Alan Hourihane wrote:

> Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa
> that allows it to accept the OpenGL commands from the client and call
> the equivalent Direct3D counterparts thus providing hardware that has
> a more capable Direct3D layer much more benefit.

I've seen this too. But it seems that this driver was not updated for a long 
time. The notes state that this driver was included in mesa 3.x and I've found
no evidence that anybody put hands on it later. 

But I might be wrong with this. 

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Alan Hourihane]

On Fri, Jan 30, 2004 at 06:54:57PM +0100, Alexander Gottwald wrote:
> On Fri, 30 Jan 2004, Alan Hourihane wrote:
> 
> > Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa
> > that allows it to accept the OpenGL commands from the client and call
> > the equivalent Direct3D counterparts thus providing hardware that has
> > a more capable Direct3D layer much more benefit.
> 
> I've seen this too. But it seems that this driver was not updated for a long 
> time. The notes state that this driver was included in mesa 3.x and I've found
> no evidence that anybody put hands on it later. 
> 
> But I might be wrong with this. 

I believe Kendall updated it for Mesa 5.x and Karl is working on getting
it integrated into the current Mesa 6.x - or that's my understanding. 
Karl is most certainly the best person to speak to as he's got the code.

Alan.

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Alexander Gottwald]

On Fri, 30 Jan 2004, Alan Hourihane wrote:

> I believe Kendall updated it for Mesa 5.x and Karl is working on getting
> it integrated into the current Mesa 6.x - or that's my understanding. 

This sounds promising.

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Harold L Hunt II]

I just spoke with Torrey Lyons regarding OpenGL acceleration in Xdarwin. 
  He enlightened me on several points:

1) Most of the code that I described in my first email is for the 
"direct" rendering path.  That path allows X Clients on the same machine 
as the X Server to avoid calling through the X Server and instead of the 
GLX lib draw directly to OpenGL.

2) There is another path called the "indirect" rendering path.  This 
path is used by all remote clients that use OpenGL as well as by local 
clients if the "direct" rendering path is not provided.  Thus, the 
"indirect" path must always be provided.

3) The "direct" path is not needed until later and the "indirect" path 
is much, much simpler.


Implementing the "indirect" path:

1) See xc/programs/Xserver/GL/apple/indirect.c

2) indirect.c should be simple to duplicate and will give all of the 
functionality needed for indirect acceleration.  This will still provide 
a tremendous boost in performance for OpenGL apps, as well as a decrease 
in CPU usage.

3) The only tricky bit is that we need to take a WindowPtr in indirect.c 
and translate it into either the HWND for the corresponding Win32 
window, or we need to translate it directly into a handle/pointer to the 
OpenGL surface associated with that window.


I actually already have most of the "direct" path code compiling, but I 
will be shelving that for the moment until we implement the "indirect" 
path.  Please, work on the "indirect" path first if you are interested 
in this.

Thanks for contributing,

Harold

Re: Notes on adding accelerated OpenGL support to Cygwin/X

[Brian Ford]

On Thu, 29 Jan 2004, Harold L Hunt II wrote:

> I just spoke with Torrey Lyons regarding OpenGL acceleration in Xdarwin.
>   He enlightened me on several points:
>
> 1) Most of the code that I described in my first email is for the
> "direct" rendering path.  That path allows X Clients on the same machine
> as the X Server to avoid calling through the X Server and instead of the
> GLX lib draw directly to OpenGL.
>
I'd say you covered both.  And, at least *I* was aware of both paths.

> 2) There is another path called the "indirect" rendering path.  This
> path is used by all remote clients that use OpenGL as well as by local
> clients if the "direct" rendering path is not provided.  Thus, the
> "indirect" path must always be provided.
>
True.

> 3) The "direct" path is not needed until later and the "indirect" path
> is much, much simpler.
>
That may be open for debate, I guess.

The last time I checked, the Linux DRI project implemented the direct
path first, and let software Mesa handle the indirect path.  In fact, it
may still be that way.  For them, that was more important, and certainly
more optimal.

For most Xwin users, however, I understand why the indirect path might be
more important.

> Implementing the "indirect" path:
>
> 1) See xc/programs/Xserver/GL/apple/indirect.c
>
> 2) indirect.c should be simple to duplicate and will give all of the
> functionality needed for indirect acceleration.  This will still provide
> a tremendous boost in performance for OpenGL apps, as well as a decrease
> in CPU usage.
>
> 3) The only tricky bit is that we need to take a WindowPtr in indirect.c
> and translate it into either the HWND for the corresponding Win32
> window, or we need to translate it directly into a handle/pointer to the
> OpenGL surface associated with that window.
>
I'm still trying to look at this, but I may not get to it until
next week.  I have done all the trivial stuff like copying the apple
files to a windows directory, modifying the Imakefiles, etc.

> I actually already have most of the "direct" path code compiling, but I
> will be shelving that for the moment until we implement the "indirect"
> path.  Please, work on the "indirect" path first if you are interested
> in this.
>
That's great!  I wouldn't shelve it, though.

It should be possible to roll out the direct stuff independently from the
indirect stuff like DRI Linux did (still using Mesa for indirect).

> Thanks for contributing,
>
I'll try :-).

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444