Adam Jackson wrote:
On Monday 06 February 2006 07:58, David Reveman wrote:
Hey,
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
it.
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
buffering automatically.
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
DDX.
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.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
