From: Hanno <ml...@hb...> - 2007-04-11 23:42:54
|
Hi, In fact, this bugged me a long time and now I'd finally like to have a=20 solution: https://bugs.freedesktop.org/show_bug.cgi?id=3D8160 The issue is: compiz has now some fallback code to indirect rendering if direct doesn't=20 work. But that's completely useless, because it'll fail some lines later,=20 exactly here: glxExtensions =3D glXQueryExtensionsString (dpy, screenNum); if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) The issue is, glXQueryExtensionsString won't return texture_from_pixmap on= =20 AIGLX if LIBGL_ALWAYS_INDIRECT isn't set. Now, the hacky solution would be to do something like the patch I attached = to=20 the bug 8160. The proper solution would probably to add an optional parameter to=20 glXQueryExtensionsString to force indirect rendering. Shouldn't be that har= d,=20 some fiddling around with stdarg/va_list. As this probably results in a sma= ll=20 API-change, I wanted to have the opinion of the mesa-folks how to solve thi= s=20 best. =2D-=20 Hanno B=C3=B6ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: ja...@hb... |
From: Michel <mi...@tu...> - 2007-04-12 06:05:09
|
On Thu, 2007-04-12 at 01:02 +0200, Hanno Böck wrote: > > The proper solution would probably to add an optional parameter to > glXQueryExtensionsString to force indirect rendering. Shouldn't be that hard, > some fiddling around with stdarg/va_list. As this probably results in a small > API-change, I wanted to have the opinion of the mesa-folks how to solve this > best. A more natural solution might be for it to take the current context into account when appropriate. That would still require the app to make the context current before querying the extensions though. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Brian P. <bri...@tu...> - 2007-04-12 16:05:15
|
Hanno Böck wrote: > Hi, > > In fact, this bugged me a long time and now I'd finally like to have a > solution: > https://bugs.freedesktop.org/show_bug.cgi?id=8160 > > The issue is: > compiz has now some fallback code to indirect rendering if direct doesn't > work. But that's completely useless, because it'll fail some lines later, > exactly here: > glxExtensions = glXQueryExtensionsString (dpy, screenNum); > if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) > > The issue is, glXQueryExtensionsString won't return texture_from_pixmap on > AIGLX if LIBGL_ALWAYS_INDIRECT isn't set. > > Now, the hacky solution would be to do something like the patch I attached to > the bug 8160. > > The proper solution would probably to add an optional parameter to > glXQueryExtensionsString to force indirect rendering. Shouldn't be that hard, > some fiddling around with stdarg/va_list. As this probably results in a small > API-change, I wanted to have the opinion of the mesa-folks how to solve this > best. We can't just add new parameters to existing GLX API functions like glXQueryExtensionsString(). It would be better to create a new function/GLX extension. -Brian |
From: David R. <da...@no...> - 2007-04-13 17:32:52
Attachments:
aiglx-workaround.diff
|
On Wed, 2007-04-11 at 16:26 -0700, James Jones wrote: > On Wednesday 11 April 2007 04:02 pm, Hanno Böck wrote: > > Hi, > > > > In fact, this bugged me a long time and now I'd finally like to > > have a solution: > > https://bugs.freedesktop.org/show_bug.cgi?id=8160 > > > > The issue is: > > compiz has now some fallback code to indirect rendering if direct > > doesn't work. But that's completely useless, because it'll fail > > some lines later, exactly here: > > glxExtensions = glXQueryExtensionsString (dpy, > > screenNum); if (!strstr (glxExtensions, > > "GLX_EXT_texture_from_pixmap")) > > > > The issue is, glXQueryExtensionsString won't return > > texture_from_pixmap on AIGLX if LIBGL_ALWAYS_INDIRECT isn't set. > > > > Now, the hacky solution would be to do something like the patch I > > attached to the bug 8160. > > > > The proper solution would probably to add an optional parameter > > to glXQueryExtensionsString to force indirect rendering. > > Shouldn't be that hard, some fiddling around with stdarg/va_list. > > As this probably results in a small API-change, I wanted to have > > the opinion of the mesa-folks how to solve this best. > > This is close to a proper solution. The problem here is, and always > has been, that there is no notion of an indirect-rendering or > direct-rendering only extension in GLX. GLX extensions are not > specific to a context. The result of glXQueryExtensionsString() > refers to extensions available on the display connection, not the > current context according to the GLX spec. Yes, the current way compiz checks for GLX_EXT_tfp using both a direct and indirect context is useless and I'll remove it. > > I believe AIGLX reports TFP in the server extension string and not > the client extension string. This implies the client has no > support for the extension, regardless of whether the client is > being used for direct or indirect rendering. However, there is > currently no mechanism for the client to report that it supports > the protocol but not the direct rendering implementation. > > I think the correct solution would be extendeding GLX to support the > notion of per-context GLX extension strings, and a mechanism could > then be added to query the GLX extensions supported by the current > context. > > Or, just do something hacky in the short term and assume all drivers > will eventually support both indirect and direct rendering TFP in > the near future. This one-off, hopefully temporary problem may not > be enough to justify a whole new extension-querying API. I agree. So as I understand the the client side GLX code will return TFP support if it can be sure that a direct rendering context is not going to be used. Defining LIBGL_ALWAYS_INDIRECT, is one way of telling it that a direct rendering context won't be used. Another way would be to disable support for direct rendering clients on the the server side (not sure this is possible with AIGLX today), which would be a more appropriate solution but I understand that people might want to avoid this. Does anyone know if some code similar to this would work? glxExtensions = glXQueryExtensionsString (dpy, screenNum); if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) { setenv ("LIBGL_ALWAYS_INDIRECT", "1", 1); glxExtensions = glXQueryExtensionsString (dpy, screenNum); if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) indirectRendering = TRUE } We know pretty well what the problem is and what needs to be done to fix it so I would be OK with including a workaround like this in head if people insist that they want it there. - David |
From: Michel <mi...@tu...> - 2007-04-13 17:52:33
|
On Fri, 2007-04-13 at 13:32 -0400, David Reveman wrote: > > Does anyone know if some code similar to this would work? > > glxExtensions = glXQueryExtensionsString (dpy, screenNum); > if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) > { > setenv ("LIBGL_ALWAYS_INDIRECT", "1", 1); > glxExtensions = glXQueryExtensionsString (dpy, screenNum); > if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) > indirectRendering = TRUE > } > > We know pretty well what the problem is and what needs to be done to fix > it so I would be OK with including a workaround like this in head if > people insist that they want it there. I'm afraid it may not work because LIBGL_ALWAYS_INDIRECT is only checked in __glXInitialize(). 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? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Brian P. <bri...@tu...> - 2007-04-13 18:18:07
|
Michel Dänzer wrote: > On Fri, 2007-04-13 at 13:32 -0400, David Reveman wrote: >> Does anyone know if some code similar to this would work? >> >> glxExtensions = glXQueryExtensionsString (dpy, screenNum); >> if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) >> { >> setenv ("LIBGL_ALWAYS_INDIRECT", "1", 1); >> glxExtensions = glXQueryExtensionsString (dpy, screenNum); >> if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) >> indirectRendering = TRUE >> } >> >> We know pretty well what the problem is and what needs to be done to fix >> it so I would be OK with including a workaround like this in head if >> people insist that they want it there. > > I'm afraid it may not work because LIBGL_ALWAYS_INDIRECT is only > checked in __glXInitialize(). > > 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? I'm hesitant to change the parameters or semantics for glXQueryExtensionsString() since some apps may depend on it working just the way it does. I'd be happier with a new function that queried the GLX extensions supported by the current context. Ian overhauled the extension-related code in GLX a while back and might have extra insight. I haven't looked at this stuff in years. Ian? -Brian |
From: Michel <mi...@tu...> - 2007-04-17 10:19:17
|
[ Apologies for the late followup, I've been away over the weekend ] On Fri, 2007-04-13 at 12:17 -0600, Brian Paul wrote: > 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? > > I'm hesitant to change the parameters or semantics for > glXQueryExtensionsString() since some apps may depend on it working just > the way it does. The spec seems ambiguous about this, or am I missing something? If not, such apps rely on undocumented behaviour of specific implementations. Moreover, it would seem odd for an app to force indirect rendering and rely on not knowing which extensions are really supported then, but I guess weirdness like that does exist... > I'd be happier with a new function that queried the GLX extensions > supported by the current context. That sounds fine if the above is really intractable. > Ian overhauled the extension-related code in GLX a while back and might > have extra insight. I haven't looked at this stuff in years. Ian? Indeed, I'm very interested in hearing his opinion as well. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: David R. <da...@no...> - 2007-04-13 21:04:46
Attachments:
mesa-always-indirect-wm.diff
|
On Fri, 2007-04-13 at 19:50 +0200, Michel Dänzer wrote: > On Fri, 2007-04-13 at 13:32 -0400, David Reveman wrote: > > > > Does anyone know if some code similar to this would work? > > > > glxExtensions = glXQueryExtensionsString (dpy, screenNum); > > if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) > > { > > setenv ("LIBGL_ALWAYS_INDIRECT", "1", 1); > > glxExtensions = glXQueryExtensionsString (dpy, screenNum); > > if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap")) > > indirectRendering = TRUE > > } > > > > We know pretty well what the problem is and what needs to be done to fix > > it so I would be OK with including a workaround like this in head if > > people insist that they want it there. > > I'm afraid it may not work because LIBGL_ALWAYS_INDIRECT is only > checked in __glXInitialize(). > > 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. How about putting something like the attached workaround in mesa? It's checking if the client is the window manager for any screen and avoids using direct rendering if that's the case. It would be more better to check if the client is the compositing manager but I couldn't think of a way to check that without creating a top-level window and that seemed a bit too nasty here. - David |
From: Michel <mi...@tu...> - 2007-04-17 10:19:51
|
[ 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. > How about putting something like the attached workaround in mesa? It's > checking if the client is the window manager for any screen and avoids > using direct rendering if that's the case. It would be more better to > check if the client is the compositing manager but I couldn't think of a > way to check that without creating a top-level window and that seemed a > bit too nasty here. I don't like either way. If there's really no clean GLX solution a wrapper script such as the one used by Debian makes more sense to me. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: David R. <da...@no...> - 2007-04-17 21:25:09
|
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. > > > > How about putting something like the attached workaround in mesa? It's > > checking if the client is the window manager for any screen and avoids > > using direct rendering if that's the case. It would be more better to > > check if the client is the compositing manager but I couldn't think of a > > way to check that without creating a top-level window and that seemed a > > bit too nasty here. > > I don't like either way. If there's really no clean GLX solution a > wrapper script such as the one used by Debian makes more sense to me. ok. - David |
From: Michel <mi...@tu...> - 2007-04-18 08:58:33
|
On Tue, 2007-04-17 at 17:24 -0400, David Reveman wrote: > On Tue, 2007-04-17 at 12:18 +0200, Michel Dänzer wrote: > > > > 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? Heh, I was rather thinking in the glXQueryExtensionsString implementation, but perhaps the spec could be worded more clearly. > 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. I agree that would appear to be the most plausible interpretation, but as it doesn't explicitly say it doesn't depend on the context, and due to the issues below... > If this interpretation of the spec is correct, any code that relies on > the current context being taken into account is obviously wrong. In particular, it would mean that it's illegal for GLX_EXT_texture_from_pixmap (or any GLX extension, for that matter) to be supported with indirect rendering only, wouldn't it? But if that's legal, and glXQueryExtensionsString is not supposed to take the context into account, how are apps supposed to know whether it's supported? Do you agree there's an inconsistency? Moreover, the GL spec only mentions the connection and no contexts for glGetString either, but it returns a different extensions string with an indirect context (glxinfo -i). So at the very least there seems to be an inconsistency between our current implementations of these two extension query mechanisms. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Ian R. <id...@us...> - 2007-04-18 16:38:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGJkg5X1gOwKyEAw8RAs1DAKCH78uDo2EK3qekeFS7ARuWlGgKxQCfYQzj KHFxZqm8Xwo0PNyQb2pSlJY= =rXkI -----END PGP SIGNATURE----- |
From: James J. <ja...@nv...> - 2007-04-18 17:09:19
|
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=E4nzer 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=E4nzer 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= =20 rendering contexts except that no one bothered to specify protocol for it. = =20 That particular case seems like an extension spec bug. I'll assume there a= re=20 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=20 extensions by definition. b) Implementations should be allowed to expose GLX extensions that support= =20 only indirect or direct rendering (or some other subset of GLX contexts for= =20 that matter). Should we instead consider adding a general mechanism to do this? =20 glXQueryContextExtensionString or something? This is my vote, even though= =20 I'll probably get stuck writing the code for it here :-) I'd rather code=20 this than add a new FBConfig attribute for every extension that requires th= is=20 functionality. Thanks, =2DJames 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 > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
From: James J. <ja...@nv...> - 2008-01-24 01:23:49
|
On Wednesday 18 April 2007 09:32 am, Ian Romanick wrote: > Sorry for coming into this thread so late. >=20 > David Reveman wrote: > > On Tue, 2007-04-17 at 12:18 +0200, Michel D=E4nzer 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=E4nzer 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=20 current > >>>> before calling glXQueryExtensionsString? > >>> That's actually what compiz is doing now as I thought that > >>> glXQueryExtensionsString took the current context into account. Howev= er, > >>> 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. >=20 > 100% spot on. >=20 > 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. >=20 > I see two options for GLX_EXT_texture_from_pixmap: >=20 > 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. >=20 > 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. >=20 > 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= =20 indirect rendering. This is only a limitation in current DRI-based=20 implementations. I don't think Option #2 is not a valid solution. FBConfigs are also=20 direct/indirect rendering independent, right? Further, there are already=20 =46BConfig flags that specify whether a given FBConfig supports TFP. Perha= ps a=20 new FBConfig caveat could be defined in a new extension: GLX_INDIRECT_ONLY.= =20 On implementations that only support indirect rendering, all TFP-capable=20 =46BConfigs could be marked with this flag. Making current to contexts cre= ated=20 with such an FBConfig would fall back to indirect rendering. Also, there's Option 3) Create a new extension that allows querying which G= LX=20 extensions are supported with only indirect or direct rendering. I've=20 mentioned before that NVIDIA would be willing to colaborate on such an=20 extension. As Ian mentions, other extensions have such limitations, so it= =20 seems this solution would be the most generally useful. Thanks, =2DJames Jones nvpublic > _______________________________________________ > compiz mailing list > co...@li... > http://lists.freedesktop.org/mailman/listinfo/compiz >=20 |