Feedback on GL_EXT_texture_from_pixmap

[James Jones]

On Tuesday 07 February 2006 04:21 pm, David Reveman wrote:
> On Tue, 2006-02-07 at 15:46 -0800, James Jones wrote:
> > 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.
>
> Maybe we should add some text to spec that explains that this is
> only really a problem when using direct rendering or a threaded
> server.

There are cases, even with a single-threaded server with indirect 
rendering, where this is still an issue.  They are very difficult 
to describe over email.  I believe we will be demonstrating 
something like this at XDevConf, and then maybe we can come up with 
a good description of the problem and hopefully a solution to 
present here.

Thanks,
-James Jones

> > > 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
>
> -David