On Fri, 01 Aug 2003 17:57:14 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
>
> > 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])));
Ok. I was afraid that drivers may register client-only extensions. If
they don't then the old logic is fine.
> 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.
I thought about this too. In a single-card environment this is still
safe. I thought that it was one important goal to enable third party
drivers to add their own extensions. In a single-head environment this
is no problem. Maybe we could check that the same function is never
registered twice. Only if all functions are registered successfully then
an extension should be added by a driver.
> 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?
Removing that functionality would make things a lot simpler indeed.
> 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?
Felix
------------ __\|/__ ___ ___ -------------------------
Felix ___\_e -_/___/ __\___/ __\_____ You can do anything,
Kühling (_____\Ä/____/ /_____/ /________) just not everything
[EMAIL PROTECTED] \___/ \___/ U at the same time.
-------------------------------------------------------
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
