Initial DRI3000 protocol specs available

[Keith Packard]

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

> What is the serialization for multiple clients using BufferFromPixmap?

Once they've got a handle to the object, it's really up to them to
serialize among themselves. We don't have any control of the underlying
direct rendering infrastructure.

> (In particular, with a compositor reading from a DRI3 client controlled
> PixmapFromBuffer.)

This case is half supported by the Swap semantics -- the pixmap is
handed from glxgears to the server with PixmapFromBuffer, then used in a
SwapRegion operation. Once given to that, that pixmap is 'busy' until
the server releases it back to the client in a future reply to
SwapRegion.

When the compositor then does a BufferFromPixmap on the same object, we
want that pixmap to remain busy until the compositor is done using
it. Would it suffice to require that the compositor call FreePixmap to
signal that it was done using it?

And that leads to another question here -- if we're swapping pixmaps
between back buffer and window buffer, how the heck does the compositor
learn that the underlying graphics object has changed? Ideally, we'd be
able to re-use the same BufferFromPixmap result across multiple frames,
but that would mean the compositor would need to be provided new window
pixmap IDs.

I wonder if we need a Swap events to send new pixmap IDs when the
swap happened? That would be pretty easy at least. Those would need to
be delivered before any related Damage events so that the compositor
would see the new Pixmap ID before it responded to the damage.

> Do we need an Invalidate for when the GEM object is
> exchanged for the Pixmap following a Swap (or other external
> modifications)?

I'm afraid I don't understand this question. Are you thinking that
pixmap IDs will end up changing which GEM objects they point at?

> Are all operations still implicitly flushed to the GPU
> before any reply to the Client?

Not necessarily flushed to the GPU, of course, but there definitely
needs to be some serialization mechanism that multiple DRI clients
sharing the same DRI buffer are using, and the X server needs to
participate in that serialization mechanism as appropriate for the
underlying hardware.

That's really up to the specific DRI infrastructure though.

We should make this explicit in the DRI3 spec though so that DRI
implementations aren't surprised by the requirement again.

> Extending this protocol to supersede MIT-SHM would also be useful if it
> makes the serialization explicit.

I've hacked up MIT-SHM to use FD passing already. It's nice to have
something that can pass *arbitrary* memory mappings instead of just DMA-BUFs.

> And for Render, along with passing blobs.

Yeah, I can easily imagine doing a PictureFromBuffer as well. Let's
focus on Pixmaps for now and get Mesa fixed up.

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