Hi,
I attached a first attempt on a patch that makes client-side extensions aware of multiple screens and will allow extensions to be enabled conditionally by the drivers. This is a result of the thread "Observations about dynamic extension registration". It compiles but the drivers aren't changed yet. I'd like to get some feedback before I do that.
Some general remarks: glXGetClientString doesn't have a screen argument. Therefore available extensions and their characteristics are managed globally. glXQueryExtensionsString on the other hand does have a screen argument. Therefore which extensions are actually enabled is managed per screen. The semantics of the direct_support bit has changed subtly. It determines if an extension is available on a screen. It must be set even for client_only extensions. This was necessary as client_only extensions added by _one_ driver would be enabled on _all_ screens otherwise.
The proposed changes break binary compatibility. The patch ignores that for now. As this API hasn't been exposed in any XFree releases yet (according to Ian), we may get away with it. ;-)
I'll have to look at it more later, but this logic is wrong:
@@ -466,9 +491,8 @@
* the direct rendering driver supports it.
*/
for ( i = 0 ; i < 8 ; i++ ) {
- usable[i] = (client_support[i] & client_only[i])
- | (client_support[i] & (direct_support[i] & server_support[i]))
- | (client_support[i] & (direct_support[i] & direct_only[i]));
+ usable[i] = client_support[i] & psc->direct_support[i] & (
+ server_support[i] | client_only[i] | direct_only[i]);
}return __glXGetStringFromTable( usable );
This requires a client-side only that isn't a direct-rendering only extension be specifically enabled by the driver. Right now the only extension like that is GLX_ARB_get_proc_address. It would be irritating to force every driver to specifically enable these extensions, especially "client-only" implies that it's handled by libGL.so and not by the driver. I think the proper logic, which is the same what the current code implements is:
usable[i] = client_support[i] &
(client_only[i]
| (direct_support[i] & (server_support[i] | direct_only[i])));I'm also having second thoughts about allowing drivers to add function calls to the GLX dispatch table. This is a global table that has no way to identify the "owner" of a dispatch function. This functionality is currently only used by a single feature of the r200 driver. I think we'd be better off adding proper support for GLX_NV_vertex_array_range and GLX_MESA_agp_offset, hackish though they are, than supporting __glXRegisterGLXFunction. There's just way too much that can go wrong with it in a multi-card environment.
It should be easy enough to add entry-points for glXAllocateMemoryNV, glXFreeMemoryNV, and glXGetAGPOffsetMESA to the __DriverAPIRec. Is that okay with you, Keith?
If we take away the ability to add functions to the GLX function table, is it really useful for drivers to be able to add new extensions at all? That would also remove the need for the force_client parameter to __glXEnableExtension. There isn't much opportunity for "enum-only" extensions in GLX like there is in GL. Brian, Keith, Allen, can any of you think of a compelling argument for this functionality?
Do any of the IHVs on this list use this DRI functionality? PowerVR? ATI (yes, I know that ATI ships their own libGL.so)? Anyone?
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
