Initial DRI3000 protocol specs available

[Stéphane Marchesin]

On Wed, Feb 20, 2013 at 10:50 PM, Keith Packard <keithp at keithp.com> 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.

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.
>
> --
> keith.packard at intel.com