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
