[Mesa3d-dev] [compiz] The direct/indirect rendering stuff and compiz

[James Jones]

On Wednesday 18 April 2007 09:32, Ian Romanick wrote:
> Sorry for coming into this thread so late.
>
> David Reveman wrote:
> > On Tue, 2007-04-17 at 12:18 +0200, Michel Dänzer wrote:
> >> [ Apologies for the late followup, I've been away over the weekend ]
> >>
> >> On Fri, 2007-04-13 at 17:04 -0400, David Reveman wrote:
> >>> On Fri, 2007-04-13 at 19:50 +0200, Michel Dänzer wrote:
> >>>> I wonder why I didn't get any feedback on my proposal: Make
> >>>> glXQueryExtensionsString take the current context into account when
> >>>> appropriate. Would it be feasible for compiz to make the context
> >>>> current before calling glXQueryExtensionsString?
> >>>
> >>> That's actually what compiz is doing now as I thought that
> >>> glXQueryExtensionsString took the current context into account.
> >>> However, as this is wrong I'd prefer to remove it.
> >>
> >> Why is it wrong? It seems odd that it shouldn't take the context into
> >> account when the context matters for whether an extension is really
> >> supported, I'm inclined to consider it a bug.
> >
> > A bug in the GLX spec? The GLX spec mentions nothing about contexts in
> > the description of glXQueryExtensionsString or GLX extensions in
> > general. It seems pretty clear that GLX extensions are specific to the
> > connection between the client and the server and that they are not
> > allowed to be context dependent. If this interpretation of the spec is
> > correct, any code that relies on the current context being taken into
> > account is obviously wrong.
>
> 100% spot on.
>
> There are several extensions that are only supported for direct
> rendering, so this isn't completely new territory (e.g.,
> GLX_OML_sync_control).  In these cases it is up to the application to
> only use the functionality in conjunction with a direct rendering context.

I don't see anything in GLX_OML_sync_control that prohibits use with direct 
rendering contexts except that no one bothered to specify protocol for it.  
That particular case seems like an extension spec bug.  I'll assume there are 
other GLX extensions that support only direct or indirect rendering though.

> I see two options for GLX_EXT_texture_from_pixmap:
>
> 1. Specify that it only works on indirect rendering contexts.  Compiz
> and other apps that use the functionality will have to request indirect
> contexts (i.e., pass FALSE for the 'direct' parameter of
> glXCreateNewContext).  Since it seems possible that future
> implementations may be able to support tfp on direct contexts, this
> doesn't seem very future proof.

It doesn't seem very present-proof.  NVIDIA supports this.

> 2. Add a flag to the fbconfigs to specify whether or not a fbconfig can
> support tfp.  This would be roughly analogous to the existing
> GLX_X_RENDERABLE flag.

If we're all agreed that:

a) The current GLX extension querying mechanisms don't support per-context GLX 
extensions by definition.

b) Implementations should be allowed to expose GLX extensions that support 
only indirect or direct rendering (or some other subset of GLX contexts for 
that matter).

Should we instead consider adding a general mechanism to do this?  
glXQueryContextExtensionString or something?  This is my vote, even though 
I'll probably get stuck writing the code for it here :-)  I'd rather code 
this than add a new FBConfig attribute for every extension that requires this 
functionality.

Thanks,
-James Jones

nvpublic

> Either option requires some modifications to the EXT_tfp spec.  Option
> #2 seems more future proof, but it also requires changes to X server and
> libGL code.  Even though I'll probably get stuck writing that code, I
> vote for #2.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev