James Jones <[email protected]> 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 fences. > 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. -- [email protected]
pgpofR2nqD1tE.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
