Feedback on GL_EXT_texture_from_pixmap

[James Jones]

On Tuesday 07 February 2006 03:11 pm, Deron Johnson wrote:
> I've reviewed the extension spec and I feel that this is
> definitely heading in the right direction. Looking Glass
> definitely needs something like this and I'm eager to try it out.

I'm glad others are excited about this as well :-)

> A couple of questions/concerns:
>
> My biggest concern is about the statement that clients need to
> rebind in order to get the latest pixmap contents for use by
> texturing. This seems to be an accomodation for devices which
> copy on BindTexImage. I'm mostly interested in getting excellent
> performance on devices which don't do a copy. Forcing clients to
> go through an expensive rebind transaction when it is not
> necessary for a device seems like an unnecessary slow-down.
> Perhaps one way of addressing this is to indicate to the user in
> the FBconfig whether the device is going to do a copy so that the
> client can rebind or not.

I believe this statement has been left in as an oversite.  The 
resolution to this issue was to not require rebinding to obtain 
up-to-date pixmap contents.  Implementations that require a copy 
would either need to perform that copy whenever the pixmap is 
rendered to, or simply not support the extension.  This extension 
is meant only as a way to expose direct texturing from drawables on 
implementations that can support it.  No benefit is gained if 
implementations must perform an internal copy.  As not all pixmaps 
will necessarily be compatible with this extension, even on 
implementations that support it, applications should always have a 
fallback path anyway.

Please also refer to paragraph 7 in the description of 
glXBindTexImageEXT.  This paragraph defines the result of texturing 
operations using a pixmap that is currently being rendered to.

> Also, could someone please provide an example of how to switch
> between rendering with one pixmap texture and then rendering
> with another pixmap texture? I'm not exactly sure whether a
> release is necessary in between; an example would clarify this.

No unbinding should be necessary if the pixmaps have already been 
set up to be used as textures:

/* Step 0: Assume these are set up elsewhere */
GLXpixmap pm1;
GLXpixmap pm2;

/* Step 1: Create pixmap textures */
GLint textures[2];
glGenTextures(2, textures);

glBindTexture(GL_TEXTURE_2D, textures[0]);
glXBindTextureImageEXT(display, pm1, GLX_FRONT_LEFT_EXT, NULL);

glBindTexture(GL_TEXTURE_2D, textures[1]);
glXBindTextureImageEXT(display, pm2, GLX_FRONT_LEFT_EXT, NULL);

/* Step 2: Draw, texturing from pixmap "pm1" */
glBindTexture(GL_TEXTURE_2D, textures[0]);
glBegin(...);
...
glEnd();

/* Step 3: Draw, texturing from pixmap "pm2" */
glBindTexture(GL_TEXTURE_2D, textures[1]);
glBegin(...);
...
glEnd();

An optimized application would only perform Step 1 when necessary, 
for example when a new pixmap was allocated.  It would then leave 
the pixmap bound to a texture until the pixmap or texture was no 
longer needed.

Does this example clarify the intended usage?

> Another question that I have is whether this extension will be
> supported by other versions of Xorg besides Xgl? Or is Xgl
> eventually going to be mainstreamed into Xorg? If so, in what
> time frame?

NVIDIA will support this extension in a future driver release, so 
no, it will not be an Xgl only feature.  Any driver that supports 
OpenGL rendering could potentially be modified to support this 
extension.

> Finally, do we need a new request to tell the Composite extension
> to round up its backing pixmap dimensions to the nearest power
> of two? Otherwise we can use texture_from_pixmap on devices that
> don't support rectangle_texture and/or non-power-of-two
> extension.

It's not clear to me that it is desireable to support this extension 
on these devices.  Perhaps users should fall back to calling 
CopyTexSubImage, and use a scheme that stores the contents of 
multiple pixmaps in a single texture to avoid eating up memory in 
this case?  This seems like something that would be best dealt with 
by an application with more knowledge than the X or OpenGL driver.

Thanks,
-James Jones

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