On Tue, Oct 8, 2013 at 1:37 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > 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. Yeah, my comment was mainly about userspace API for different driver subsystems. I'd rather add some extra parameter(s?) to drm and v4l ioctls, even if they are unused by linux userspace, vs having different ABI for android kernel vs linux kernel. We probably do however need the zero value to indicate unusued.. at least for adding new parameters to existing drm ioctls since drm_ioctl() will be zero'ing stuff out to deal w/ new userspace / old kernel, or old userspace / new kernel combos. For new ioctls (like 'atomic') we don't have this constraint. BR, -R > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
