On Wed, Jun 6, 2012 at 7:39 AM, Erik Gilling konkers@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig