Initial DRI3000 protocol specs available
keithp at keithp.com
Tue Apr 2 16:34:33 PDT 2013
James Jones <jajones at nvidia.com> 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 intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg-devel