Initial DRI3000 protocol specs available

[Keith Packard]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> If a DRI2 client also grabs the buffer, then we have to fallback to blits.
> That should be fairly easy to detect and handle.

So, the question is whether the NameWindowPixmap IDs are stable across
pixmap replacement. I'm frankly tempted to add a new event to Composite
that is sent whenever the window pixmap changes -- that way applications
wouldn't have to guess that the pixmap changed whenever the window was
resized. This would also provide an opportunity to improve resize
performance as the X server could over-allocate window pixmaps during
the resize operation, and then shrink them back down once the final size
had been selected.

> We are concerned with the GEM objects backing the Pixmaps, which may
> be changed at whim by the driver.

Huh?

> We cannot perform simple name exchanges currently in DRI2 because the
> Damage is badly ordered wrt the Invalidate event and there is no
> coordination between client <-> server <-> compositor on when the
> buffers are reusable by the client.

Right, so we clearly need to pass the backing buffer from application to
X server and thence to the compositor. What I'm not sure about is how to
name these buffers, and how to scope their lifetime.

Here's a quick proposal -- have the X server assign server XIDs to the
buffers, and send those XIDs to the compositor in events. Now the
compositor is responsible for telling the server (some new 'IdlePixmap'
call?) when it finishes with the objects, at which point they can be
released back to the application.

We'd need some magic to make sure the pixmaps got freed if the
compositor crashed, but I think that's easier than trying to figure out
how to allocate XIDs in the compositor ID space from within the X
server.

This would replace NameWindowPixmap, and would eliminate the current
race conditions between the ConfigureNotify and the NameWindowPixmap
call while also providing traceable ownership of the buffer contents:

busy    application     X server        compositor

        
A       Draw to buffer A
        Allocate pixmap ID for buffer A, 'Pixmap Aa'
        SwapRegion Pixmap Aa

                        Allocate server ID for Pixmap Aa, 'Pixmap Ax'
                        Send 'window pixmap changed' event 'Pixmap Ax'

                                        Receive event
                                        Convert 'Pixmap Ax' into buffer A
                                            using TextureFromPixmap
                                        paint screen using buffer A
                                        ...
AB      Draw to buffer B
        Allocate pixmap ID for buffer B, 'Pixmap Ba'
        SwapRegion Pixmap Ba

                        Allocate server id for Pixmap Ba, 'Pixmap Bx'
                        Send 'window pixmap changed' event 'Pixmap Ax'

                                        Receive event
                                        IdlePixmap Pixmap Ax
                                        Convert 'Pixmap Bx' into buffer B
                                            using TextureFromPixmap
                                        paint screen using buffer B

B                       Mark Pixmap Aa as idle

BC      Draw to buffer C
        Allocate pixmap ID for buffer C, 'Pixmap Ca'
        SwapRegion Pixmap Ca
                        Reply with Pixmap Aa idle
                        Allocate server id for Pixmap Ca, 'Pixmap Cx'
                        Send 'window pixmap changed' event 'Pixmap Cx'

                                        Receive event
                                        IdlePixmap Pixmap Bx
                                        Convert 'Pixmap Cx' into buffer C
                                            using TextureFromPixmap
                                        paint screen using buffer C

C                       Mark Pixmap Ba as idle

CA      Draw to buffer A
        SwapRegion Pixmap Aa
                        Reply with Pixmap Ba idle
                        Send 'window pixmap changed' event 'Pixmap Ax'

                                        Receive event
                                        IdlePixmap Pixmap Cx
                                        paint screen using buffer A

A                       Mark Pixmap Ca as idle

At this point, we're in a steady state, using three buffers for
the window -- a 'back buffer', a 'front buffer' and an 'idle buffer'.

One easy thing for memory usage is to consider idle buffers as suitable
for discard in the kernel; that would get us to one pinned buffer in the
idle case, although we'd be using three buffers while active.

It would be nice to flip between two buffers instead, but there may be
compositor rendering traffic in flight using buffer A as the application
draws to B and then C.

Hrm. What we need is for the client to learn that the compositor has
marked a buffer idle before it starts drawing; the current design places
that information in the reply to SwapRegion, which is one drawing cycle
too late for us.

Consider an application which wants to be completely synchronized with
screen updates. Such an application would use the new SwapComplete event
to detect when its contents were presented to the screen, starting a new
frame each time that event was received (assuming it had new data to
present).

First off, we want the SwapComplete event to be delayed until the
compositor is done updating the screen. A new request from the
compositor to signal rendering complete could be sent to the server to
flag which window contents were present on the screen.  When the
SwapComplete for the whole screen was delivered, the X server would then
forward suitable SwapComplete events to the windows as appropriate.

Next, we need the application to learn about idle buffers sooner.

One option would be to remove the idle buffer data from the SwapRegion
request and create a SwapGetIdle request that fetched the idle buffers
separately from doing the swap operation. The application would call
this before selecting the target rendering buffer for each frame.

The other option would be to create SwapIdle event which the X server
would deliver immediately after the compositor marked a buffer as
idle. We would need to rewire the X protocol library to deliver this
event directly to the DRI3 library. As long as this event were delivered
before the SwapComplete, when the client started rendering the next
frame, it would get the previous back buffer as intended.

I don't think this event would have the same problems as the current
Invalidate event; it wouldn't be pulling any active objects out from
under the application.

> I think we definitely want to support window swapping with DRI3
> compositors. DRI2 compositors will just have to continue to force
> blits.

Yup.

> As I see it the challenge is to prevent sending the buffer release
> (SwapIdle) back to the client before all interested third parties have
> had a chance to snoop its contents and react. Sketching that out we
> need to increment the busy count everytime we send an Invalidate and
> expect the client (compositor) to send a release after they have
> finished processing the buffer.

See above plan.

-- 
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/20130221/e3116083/attachment.pgp>