Initial DRI3000 protocol specs available

[Ian Romanick]

On 02/20/2013 10:50 PM, Keith Packard wrote:
> Stéphane Marchesin <stephane.marchesin at gmail.com> writes:
>
>> On Wed, Feb 20, 2013 at 12:42 PM, Keith Packard <keithp at keithp.com> wrote:
>>> Stéphane Marchesin <stephane.marchesin at gmail.com> 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.
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel