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

[James Jones]

On Wednesday 18 April 2007 09:32 am, 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 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.
> 
> 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.
> 
> 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.

Option #1 is not even current-proof :-)  TFP is not meant to be limited to 
indirect rendering.  This is only a limitation in current DRI-based 
implementations.

I don't think Option #2 is not a valid solution.  FBConfigs are also 
direct/indirect rendering independent, right?  Further, there are already 
FBConfig flags that specify whether a given FBConfig supports TFP.  Perhaps a 
new FBConfig caveat could be defined in a new extension: GLX_INDIRECT_ONLY.  
On implementations that only support indirect rendering, all TFP-capable 
FBConfigs could be marked with this flag.  Making current to contexts created 
with such an FBConfig would fall back to indirect rendering.

Also, there's Option 3) Create a new extension that allows querying which GLX 
extensions are supported with only indirect or direct rendering.  I've 
mentioned before that NVIDIA would be willing to colaborate on such an 
extension.  As Ian mentions, other extensions have such limitations, so it 
seems this solution would be the most generally useful.

Thanks,
-James Jones

nvpublic

> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>