On 02/20/2013 10:50 PM, Keith Packard wrote:
Stéphane Marchesin <[email protected]> writes:
On Wed, Feb 20, 2013 at 12:42 PM, Keith Packard <[email protected]> wrote:
Stéphane Marchesin <[email protected]> writes:
I'm interested in two specific use cases:
- Swap to an overlay and flip a crtc in an atomic fashion,
As you may remember, I proposed a bunch of RandR changes to support
per-CRTC pixmaps and atomic mode setting operations a while back. With
hardware now commonly supporting multiple overlays, even that stuff
wouldn't suffice anymore.
Off the top of my head, we'd need to construct some Drawable that
represented each overlay, and then perform a PolySwapRegion operation to
synchronously update their contents from appropriate back buffers.
Right, that's what I'm after. If you have a bunch of GL surfaces
you're rendering to, a "main drawable" and 2 overlays, I'd like the
ability to swap to arbitrary overlays or to my main surface. Of course
the GL extension for that is still TBD, but having the ability in DRI3
would be a nice start.
Having an actual API to design to would be a huge help though; I suspect
anything we do in advance will just get messed up by the GL ARB.
Well, if you have vsync enabled for your CopyRegion implementation,
then you'll need to vsync for each region right? What I'm after is a
"swap all these regions together, vsync only once" type of thing.
Oh. I've been focused on the GL swapbuffers APIs. SwapRegion isn't a
general CopyRegion operation. I've neglected to write down some of the
more important semantics which underlie the goals of this work.
EGL_NOK_swap_region (supported by Mesa) allows specifying multiple
subrectangles to swap together.
EGLAPI EGLBoolean EGLAPIENTRY eglSwapBuffersRegionNOK(EGLDisplay dpy,
EGLSurface surface, EGLint numRects, const EGLint* rects);
For SwapRegion, I want to be able to require that the X server always be
free to just swap the entire contents of the source buffer with the
destination buffer -- the region is just the 'damaged' area within the
window; areas outside of that don't *need* to be copied from the new
buffer, but the client guarantees that the entire buffer contain the
correct contents for the window and that only the area within the
specified region differs from the current window contents.
For a compositing manager, you really do want to pull data from all of
the window pixmaps and paint them into the frame buffer in one giant
operation. The usual way of doing this is to construct the whole next
screen frame in a new single image and then use SwapRegion to get that
onto the screen. Then the individual updates could use a sequence of
SwapRegion operations to construct that intermediate buffer; once that
was ready, a single SwapRegion would move that to the scanout buffer.
Presumably that final SwapRegion would be a simple page flip operation
in the driver, so it would take "no" time or memory bandwidth.
It might be fun to figure out how to bypass the intermediate back buffer
though, and for that we'd need some complicated PolySwapRegion request
that queued up all of the changes in one giant request to be executed at
the right time, but that seems like something that wouldn't match how I
imagine compositing managers working today.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
