Ian Romanick wrote:
[snip]
The functions __glXEnableExtension and __glXDisableExtension take a name of an extension and either enable or disable the extension. This mirrors the functionality of _mesa_enable_extension and _mesa_disable_extension. The function __glXAddExtension is used to add a new extension string and default state to the internal extension table. The state of the extension can later be changed via __glXEnableExtension or __glXDisableExtension.
_mesa_disable_extension() is never used, AFAIK, since by default, Mesa disables all (or most) extensions and it's up to drivers to enable the ones they support. We may never need __glXDisableExtension, but I suppose it's good to have for completeness.
Yeah. I pretty much just added it for completeness. The XP half of my brain kept screaming to take it out, though. :)
The function __glXExtensionBitIsEnabled is used to determine if one of the compiled-in extensions is enabled. Each extension has a bit defined in glxextensions.h. If a driver (or the libGL.so GLX code) wants to determine if GLX_SGIX_pbuffer is enabled, it would make this call:
pbuffer_enabled = __glXExtensionBitIsEnabled(SGIX_pbuffer_bit);
Why not pass the extension string and return a boolean?
It actually turned out to be LESS code to do it this. Usually, less code == less bugs. Since GLX extensions are not added very often (and this will only become MORE true in the future), there doesn't seem to be a bit maintainence problem. This roughly mimics the way that Mesa internally checks to see if an extension is enabled. It just uses a single bit per extension instead of an int. :)
The final function is __glXGetClientExtensions. This function returns the string of all the client-side enabled GLX extensions.
IMPORTANT!
I didn't change it in this patch, but I believe that the current implementation of glXQueryExtensionsString is wrong. I haven't been able to find any "official" GLX documentation to confirm this, but the "GLX Extension Availability" section of http://oss.sgi.com/projects/ogl-sample/registry/doc/rules.html says:
"glXQueryExtensionsString...intersects the returned string with the set of extensions it can support and then appends any client-side only extensions to the list."
Our implementation of does not do this. Depending on what the consensus is, I believe an additional function __glXGetClientOnlyExtensions should be added that returns the list of client-side extensions, and __glXGetClientExtensions should be modified to not return those extension strings. glXQueryExtensionsString should then be modified to append the string returned by __glXGetClientOnlyExtensions to the extension string.
Sounds good. A concrete example of a client-side only extension is GLX_ARB_get_proc_address, for those wondering.
The catch is that some extensions are only supported for direct contexts (i.e., GLX_OML_sync_control). Is it possible for
glXQueryExtensionsString to know if the app has a direct context?
No. glXQueryExtensionsString() is context-independant. I'm not sure how to resolve this issue. Maybe just no-op the sync-related functions if using an indirect context, somehow.
Most of these functions are defined to return an error for an indirect context, so that's not a problem. In reading your e-mail and re-reading some of my notes, the other part of the issue is that glXGetClientString( GLX_EXTENSIONS ) should return the list of extensions that the libGL.so *can* support. This may or may not have anything to do with what the driver can support. By that mark, it __glXGetClientExtensions should return all of the extensions that libGL.so either has a wire-encoding for or can call directly for direct rendering.
If that's done, then we would have to make some sort of useful combination of the string returned by QueryServerString( ... GLX_EXTENSIONS ) and the extensions supported by direct rendering. One way to do this would be to add a flag to each extension that says it is client-side or direct rendering only. That way it would get added on automatically by the call to __glXGetClientOnlyExtensions.
Wow. This has got to be one of the MOST irritating parts of GLX!
[snip]
My thinking is to create a new structure like the following and replace the data fields in the __DRIdrawablePrivateRec with a single function that fills in the structure with the current values.
typedef struct {
[snip]
} driSwapCountInfoRec;
I don't think anyone's looked at this as closely as you so you may just have to use your best judgement. My only preference is to keep things as simple as practical.
Okay. I'm going to ping a couple IHVs to see what they think.
------------------------------------------------------- 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
