Chris Wilson <ch...@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.pack...@intel.com
pgpPa4RQRqoRJ.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel