Initial DRI3000 protocol specs available

[Keith Packard]

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

> You manage ask yourself the question I was trying to lead: how the heck
> does the compositor learn that the underlying graphics object has
> changed?

It can certainly tell that the underlying contents have changed with
Damage events, but as to how it knows that it should do another
BufferFromPixmap request, I think that's gonna require another
event.

Now, the big question is how to deal with compositing managers which
don't know about DRI3. I suspect we'll just have to skip the DMA-BUF
swapping hack for window pixmaps unless the compositor gives us the OK
to do so.

> In DRI2 this is through the InvalidateEvent, and the lack of
> being able to send those from the driver before the Damage is sent is
> one of the reasons why the current exchange mechanism is broken.

Hrm. With the current system, except for override-redirect windows, if
the compositor is also the window manager, it should always know when
the window pixmap is going to be replaced because that only happens when
the window is resized, and the window manager is entirely responsible
for making that happen. For override-redirect windows, if the
ConfigureNotify event was delivered before the Damage event, then the
compositor could know about that as well.

I guess I'd like to know more about what is broken with the current
system for compositors...

In any case, as the underlying DMA-BUF is changing, the compositor is
going to need to know that so it can release the old pixmap back to the
application, and so it can rewire its own compositing operations to use
the new object.

It might be nice to have the compositor use persistent names for the
various DMA-BUFs that are used for a particular window. I think that
means having the compositor hold on to old DMA-BUF window pixmap
IDs. That seems tricky though. The alternative will be to have the
compositor create/destroy a pixmap ID per frame. Not intolerable, but
not optimal.

> Getting buffer exchanges working in conjunction with the external
> compositor is more or less as tricky as it gets. The notion that the
> buffer is kept busy by the compositor and so prevents the DRI3 client
> from overdrawing it is key. And that naturally leads to the compositor
> needing to release the old buffer once it is referencing the new
> post-swap buffer.

Right, an easy technique there would be to have it use NameWindowPixmap
when it got an event telling it that a new pixmap was in use for the
window, and then when it was finished with that pixmap, it could just
use FreePixmap to tell the server it was done. That would bump the
refcnt down to one in the server, at which point it could queue the
pixmap to be sent as 'idle' the next time SwapRegion was called.

> Serialisation between rendering of the common buffers
> is definitely s.e.p. I agree that should solve the compositor problem.

Ok, cool.

So, changes that I think are needed:

 1) If someone calls TextureFromPixmap on a window pixmap, we need to
    suppress the window pixmap swapping hack. Alternatively, we can have
    the compositor explicitly enable window pixmap swapping.

 2) We need to send an event when the buffer underlying a window switches.

 3) We need to be explicit about event ordering between the new window
    pixmap change notify event and any related Damage.

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