On 2016?07?26? 16:26, Daniel Vetter wrote: > On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote: >> >What is share plane: >> >Plane hardware only be used when the display scanout run into plane active >> >scanout, that means we can reuse the plane hardware resources on plane >> >non-active scanout. >> > >> > -------------------------------------------------- >> > | scanout | >> > | ------------------ | >> > | | parent plane | | >> > | | active scanout | | >> > | | | ----------------- | >> > | ------------------ | share plane 1 | | >> > | ----------------- |active scanout | | >> > | | share plane 0 | | | | >> > | |active scanout | ----------------- | >> > | | | | >> > | ----------------- | >> > -------------------------------------------------- >> >One plane hardware can be reuse for multi-planes, we assume the first >> >plane is parent plane, other planes share the resource with first one. >> > parent plane >> > |---share plane 0 >> > |---share plane 1 >> > ... >> > >> >Because resource share, There are some limit on share plane: one group >> >of share planes need use same zpos, can not overlap, etc. >> > >> >We assume share plane is a universal plane with some limit flags. >> >people who use the share plane need know the limit, should call the ioctl >> >DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it. >> > >> >A group of share planes would has same shard id, so userspace can >> >group them, judge share plane's limit. >> > >> >Signed-off-by: Mark Yao<mark.yao at rock-chips.com> > This seems extremely hw specific, why exactly do we need to add a new > relationship on planes? What does this buy on_other_ drivers? Yes, now it's plane hardware specific, maybe others have same design, because this design would save hardware resource to support multi-planes. > Imo this should be solved by virtualizing planes in the driver. Start out > by assigning planes, and if you can reuse one for sharing then do that, > otherwise allocate a new one. If there's not enough real planes, fail the > atomic_check. I think that is too complex, trying with atomic_check I think it's not a good idea, userspace try planes every commit would be a heavy work. Userspace need know all planes relationship, group them, some display windows can put together, some can't, too many permutation and combination, I think can't just commit with try. example: userspace: windows 1: pos(0, 0) size(1024, 100) windows 2: pos(0, 50) size(400, 500) windows 3: pos(0, 200) size(800, 300) drm plane resources: plane 0 and plane 1 is a group of share planes plane 2 is common plane. if userspace know the relationship, then they can assign windows 1 and window 3 to plane0 and plane 1. that would be success. but if they don't know, assign window 1/2 to plane 0/1, failed, assign window 2/3 to plane 0/1, failed. mostly would get failed. > > This seems way to hw specific to be useful as a generic concept. We want to change the drm_mode_getplane_res behavior, if userspace call DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware limit, then we return full planes support to userspace, if don't, just make a group of share planes as one plane. this work is on generic place. > -Daniel > > -- ?ark Yao
