Ian Romanick wrote:
Before I just launch into this, I will explain some of the motivation and
(brief) history that led to this document.
As near as I can tell, the GLX side of DRI has stagnated. I seems as though
we are approaching a critical mass to make some real improvements in that
area. Brian and I have had some discussions (both on and off the list)
about adding an extension handling mechanism for GLX that mirrors the
mechanism for regular GL. Some improvements in that area have already been
committed to the mesa4.1 branch, and they will soon (this weekend?) be merged
into the trunk.
The first change is a new function to query the version of the internal
(i.e., driver to libGL.so) GLX API. Drivers can use this function to
determine if certain data fields and functions are present in GLX. Drivers
can then expose enhanced functionality with new enough versions of libGL and
fallback with old versions. The __glXGetInternalVersion function returns
the version, which is currently a date, as an unsigned integer. Later, a
function called driCompareGLXAPIVersion will be added to determine if the
current API version is new enough. This will help drivers handle the case
where libGL is so old that it does not support the __glXGetInternalVersion
function.
The other change was to add private GLX functions that reside in libGL.so to
the table used by glXGetProcAddress. This allows drivers to avoid the
burden of using dlsym (see the end of lib/GL/mesa/src/drv/r200/r200_screen.c
in the trunk). They can simply call glXGetProcAddress to get pointers to
functions that may only exist in new versions of libGL.so.
__glXGetInternalVersion is a good example of such a function.
As soon as these changes find their way into the trunk, I will merge them
into the texmem-0-0-1 branch. I suspect that merging the mesa4.1 merged
trunk into the texmem branch will be very "exciting" work. :) Good thing
for me that next week is a holiday week...
This sets the stage for drivers to enable or disable GLX extensions in a
clean manner, compatible (forward and backward) manner. I believe that this
is important for our open source driver work and DRI in general for three
big reasons. This is why I am very interested in getting this stuff done.
1. We've fallen behind. There are other vendors of closed-source drivers on
Linux that don't use DRI that have a significant GLX feature advantage.
There is quite a bit of functionality, both the stuff I have listed below
and more, that our open source drivers just flat don't support.
2. Device independence. Pretty much any GLX extension that requires new
entry points could be implemented the same way that
GLX_NV_VERTEX_ARRAY_RANGE is implemented in the R200 driver (see the bottom
of lib/GL/mesa/src/drv/r200/r200_screen.c). The problem with that is that
most of the code would be the same or nearly the same for every single
driver. I've spent enough time refactoring duplicated code in the DRI code
base to know better than to fall into that trap! Not only that, adding the
extensions in this way would prevent libGL from being used to do indirect
rendering on a remote system (app running on x86 Linux, rendering on MIPS
SGI, for example) that did support the extensions.
3. Closed source drivers that use DRI. Quite a bit of this functionality is
or could be supported by those few IHVs that actually use DRI for their
close source drivers. The problem is that they have to supply their own
libGL. That just causes problems for everyone. I realize that supporting
closed source drivers is pretty low on most people's priority list, but
doing something to help both open and closed source drivers just gives me
that warm, fuzzy, win-win feeling. :)
I've done some sizing on these changes, and I think that I can handle most
of the device independent parts. I've already written code to handle
enabling and disabling of extensions. After I merge in Brian's changes to
the texmem branch, I will commit these changes to the branch. I've also
made the changes to the R100 driver to support the GLX_SGI_swap_control (and
the "MESA" version, see below). On some of the remaining extensions I've
notes about whether or not I can reasonably make the changes. On some of
them I've even noted that a "newbie" could probably make the changes.
The rest of this document is basically broken into two sections. The first
section lists the changes I propose be made to the internal GLX API. With
three exceptions, all of the changes are to the __DRI*Rec structures.
We'll have to be careful with those structures since they're accessed both by libGL and the DRI drivers. We should try our best to preserve forward/ backward compatibility
In general your ideas sound good. I'll try to work with you on this once you get going. -Brian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
