On Wed, Jun 6, 2012 at 12:17 PM, Clark, Rob rob@ti.com wrote:
well, to be fair this doesn't need to be a userspace API.. or rather it doesn't need to be a standard API added to some new chrdev, since your GL lib is already got it's own interface to the kernel which it could query whatever it needs about a fence / syncobj / syncpoint / whatever.
If the sync primitives are backed by file descriptors (or attached to dma_bufs) you don't need an extra char dev either.
The bigger issue is the previous point about how to deal with cases where the CPU doesn't really need to get involved as an intermediary.
CPU fallback access to the buffer is the only legit case where we need a standardized API to userspace (since CPU access isn't already associated w/ some other kernel device file where some extra ioctl can be added)
The CPU case will still need to wait on an arbitrarily backed sync primitive. It shouldn't need to know if it's backed by the gpu, camera, or dsp.
Having a standard API is also really useful for debugging and performance tracing. Having timestamps of when each piece signals in the pipeline of getting a frame on the screen helps track down bottlenecks.
-Erik