Initial DRI3000 protocol specs available

[Keith Packard]

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.

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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130220/f4715b0d/attachment.pgp>