On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling <konkers@xxxxxxxxxxx> wrote: > On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst > <maarten.lankhorst@xxxxxxxxxxxxx> wrote: >> Depending on feedback I'll try reflashing my nexus 7 to stock android, and work on trying to convert android >> syncpoints to dma-fence, which I'll probably rename to syncpoints. > > I thought the plan decided at plumbers was to investigate backing > dma_buf with the android sync solution not the other way around. It > doesn't make sense to me to take a working, tested, end-to-end > solution with a released compositing system built around it, throw it > out, and replace it with new un-tested code to > support a system which is not yet built. Hey Erik, Thanks for the clarifying points in your email, your insights and feedback are critical, and I think having you and Maarten continue to work out the details here will make this productive. My recollection from the discussion was that Rob was ok with trying to pipe the sync arguments through the various interfaces in order to support the explicit sync, but I think he did suggest having it backed by the dma-buf fences underneath. I know this can be frustrating to watch things be reimplemented when you have a pre-baked solution, but some compromise will be needed to get things merged (and Maarten is taking the initiative here), but its important to keep discussing this so the *right* compromises are made that don't hurt performance, etc. My hope is Maarten's approach of getting the dma-fence core integrated, and then moving the existing Android sync interface over to the shared back-end, will allow for proper apples-to-apples comparisons of the same interface. And if the functionality isn't sufficient we can hold off on merging the sync interface conversion until that gets resolved. Does that sound reasonable? thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
