[Mesa3d-dev] Re: GLX_EXT_texture_from_pixmap
brian.paul at tungstengraphics.com
Tue Feb 7 07:06:43 PST 2006
Adam Jackson wrote:
> On Monday 06 February 2006 07:58, David Reveman wrote:
>>here's the latest version of the texture from pixmap spec that Xgl will
>>be supporting. It's not fully implemented in Xgl yet, just so much of it
>>that you can get an indirect rendering compositing manager running using
> Regarding issue 5 (rebinding and texturing directly from the pixmap image),
> I've suspected for a while now that we need some form of protocol whereby
> apps can signal to the compositing manager that they've rendered a frame to a
> given pixmap and therefore that it should be rendered from quickly. Others
> have proposed using sync counters as an even/odd toggle indicating whether
> the pixmap is "baked" or not. I think we want the ability to specify live
> updates to the pixmap as an (optional) attribute to BindTexImage to
> accomodate for this sort of handshaking in the future.
I think there's some implicit and explicit clues to indicate when
drawing to a pixmap is completed.
With OpenGL rendering, the glFlush/glFinish() commands are used to
force any buffered rendering commands to be completed (with the
implication is the results are to be displayed immediately). The
SwapBuffers function does an implicit glFlush.
With Xlib rendering, any buffered rendering commands are supposed to
be completed when any Xevent-getting function is called, or an
explicit XFlush() or XSync() is used.
These would seem to be the signals to "push" rendering to the screen.
There's other times when the window system wants to "pull" images to
repaint the screen. In that case I think it's OK to get pixmap images
that aren't completely rendered. Sure, you may get some
glitches/artifacts, but we've been living with that for many years.
If the pixmap is _copied_ to a texture, though, you kind of get double
> Other than that it's been fairly easy to hook this - well, "this" when it was
> still called EXT_texture_from_drawable - up in the GLX implementation in the
> xfree86 DDX, and we've been pretty pleased with the results so far. I don't
> see anything in this revision that will make life any harder in the xfree86
> Currently we're just doing TexImage2D to dump the bits from the pixmap to the
> texture, which is suboptimal but works surprisingly well as long as your
> pixmaps are in host memory (thank you, XaaNoOffscreenPixmaps). In the future
> there's probably some integration to be done with the GetImage path for
> accelerated downloads, or with on-card copies from pixmap storage to texture
> storage, or live updates as mentioned above. Also in the medium-to-long term
> we should look into unifying the GLX code between the xgl and xfree86 DDX's.
> I haven't had the chance to look at the xgl side in too much detail, but I
> expect there's some common themes.
More information about the xorg