This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]