Hi, On 26 April 2016 at 21:48, Greg Hackmann <ghackmann@xxxxxxxxxx> 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: >>> 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 ;-) > > 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. Right, and when using implicit fencing, this comes as a plane property, by virtue of plane -> fb -> buffer -> fence. > 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. Can you please elaborate? > 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. As Ville says, I don't want to go down the path of scheduling CRTC updates separately, because that breaks MST pretty badly. If you don't want your updates to display atomically, then don't schedule them atomically ... ? That's the only reason I can see for making fencing per-CRTC, rather than just a pile of unassociated fences appended to the request. Per-CRTC fences also forces userspace to merge fences before submission when using multiple planes per CRTC, which is pretty punitive. I think having it semantically attached to the plane is a little bit nicer for tracing (why was this request delayed? -> a fence -> which buffer was that fence for?) at a glance. Also the 'pile of appended fences' model is a bit awkward for more generic userspace, which creates a libdrm request and builds it (add a plane, try it out, wind back) incrementally. Using properties makes that really easy, but without properties, we'd have to add separate codepaths - and thus separate ABI, which complicates distribution - to libdrm to account for a separate plane array which shares a cursor with the properties. So for that reason if none other, I'd really prefer not to go down that route. Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
