On Wed, Feb 20, 2013 at 10:50 PM, Keith Packard <[email protected]> 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.
I don't think we need to involve the ARB just yet, the copy sub buffer is a MESA extension and never went to the ARB. So I don't see that as a problem. With that said, I don't think it's that difficult/different. I can design a GLX extension spec and send a draft, then we can work from there. > >> 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. > > 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. That is actually not what you want because it is a waste of bandwidth. Since compositors are typically bandwidth limited, you instead want to paint only the relevant sub regions. Those are easy to determine by transforming X damage regions into screen coordinates. Most non-trivial compositing managers are already using partial update schemes through GLX_MESA_copy_sub_buffer or the GLX_EXT_buffer_age extensions + copies. I don't think it is far fetched to support a list of rectangles instead. Stéphane > 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] _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
