Initial DRI3000 protocol specs available

Keith Packard keithp at
Tue Apr 2 16:34:33 PDT 2013

James Jones <jajones at> writes:

> There's some work going on to get something very much like fence sync 
> objects into the Linux kernel as well, I think starting with something 
> from the Android kernel trees, and with input from some people working 
> on fence objects usable to synchronize access to dmabuf objects.

I'll see if I can't find out what they're up to.

> It might make sense to use these primitives rather than shared
> memory+pthreads to share the syncs between direct rendering clients
> and the X server.

I can start prototyping with shared memory and the current DRI kernel
drivers as that will not require any updates to the kernel -- as DRI
provides serialization guarantees across multiple applications, I can
perform all of the fence operations strictly from user-mode and have
things work correctly on DRI-based hardware. As such, that clearly means
that these would be 'DRI' fences, and not some more general DMA-BUF

> At the very least, it would be nice to have an 
> abstraction where the implementation details of the sync objects weren't 
> directly exposed by the API.

I think we can use your existing X Sync fence stuff, or something quite
similar, for an X API. The DRM APIs hide underneath the DRM libraries
(vdpau, vaapi, opengl), and so how that extension works isn't directly
visible to applications.

> I like the sound of the overall direction.  Looking forward to what you 
> come up with.

I'm typing; the current short-term goal is client-side buffer
allocation, shared memory fences and using CopyArea for the presentation
portion of the work. That neatly divides the design into the DRM half
and the presentation/swap-buffers half.

keith.packard at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the xorg-devel mailing list