[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Clark, Rob]

On Wed, Jun 6, 2012 at 7:39 AM, Erik Gilling <konkers at android.com> wrote:
> Tom,
>    Is there more planned for KDS?  It seems to be lacking some
> important features to be useful across many SoCs and graphics cards
> and features needed by Android.  Here's some general feedback on those
> gaps.

fwiw, features can always be added over time..  at this point I think
the most important thing is to come up with something that doesn't
paint us into a corner wrt. features that we'd like to add later (such
as the hw sync'ing you mention below)

> There is no way to share information between a buffer provider and a
> buffer consumer.  This is important for architectures such as Tegra
> which have several hardware blocks that share common hardware
> synchronization.

yeah, this is a limit.  I think probably a simpler fence type scheme
might be easier to deal w/ for hw synchronization.

> There's no userspace API.  There are several reasons this is
> necessary.  First, some userspace code (such as GL libs) might need to
> get at the private data of the sync primitive in order to generate
> command lists for a piece of hardware.

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.  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)

BR,
-R

> Second is does not let
> userspace have control or even visibility into the graphics pipeline.
> The direction we are moving in Android is to put more control over
> synchronization into the compositor and move it out of being
> implemented "behind the scenes" by every vendor. Third, there's no way
> for a userspace process to wait on a sync primitive.
>
> There's no debugging or timing information tracked with the sync
> primitives.  During development on new platforms and new OS versions
> we often have cases where the graphics pipeline stops making forward
> progress because one of the pieces (GPU, display, camera, dsp,
> userspace) has, itself, stopped making forward progress.  Finding the
> root cause of the often hard to reproduce cases is difficult when you
> have to instrument every single driver.
>
> It's unclear how you would attach a dependency on a EGL fence to a
> dma_buf.  Maybe this would be an EGL extension where you pass in the
> fence and the dma_buf.
>
> At Android we've been working on our own approach to this problem.
> I'll post those patches for discussion.
>
> Cheers,
>    Erik
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig