On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote: > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > >On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > >>On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote: > >>>On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: > >>>But really the reason for per-plane is hw composer from > >>>Android. I don't see any point in designing an api that's needlessly > >>>different from what the main user expects (even if it may be silly). > >> > >>What are they doing that can't stuff the fences into an array > >>instead of props? > > > >The hw composer interface is one in-fence per plane. That's really the > >major reason why the kernel interface is built to match. And I really > >don't think we should diverge just because we have a slight different > >color preference ;-) > > > >As long as you end up with a pile of fences somehow it'll work. > >-Daniel > > > > The relationship between layers and fences is only fuzzy and indirect > though. The relationship is really between the buffer you're displaying on > that layer, and the fence representing the work done to render into that > buffer. SurfaceFlinger just happens to bundle them together inside the same > struct hwc_layer_1 as an API convenience. > > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > between layers and DRM planes. But that's not always the case. > > A (per-CRTC?) array of fences would be more flexible. And even in the cases > where you could make a 1-to-1 mapping between planes and fences, it's not > that much more work for userspace to assemble those fences into an array > anyway. I'm ok with an array too if that's what you folks prefer (it's meant to be used by you after all). I just don't want just 1 fence for the entire op, forcing userspace to first merge them all together. That seems silly. One side-effect of that is that we'd also have to rework all the internal bits and move fences around in atomic. Which means change a pile of drivers. Not sure that's worth it, but I'd be ok either way really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel