lkml.org 
[lkml]   [2016]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] drm: introduce share plane
From
Date
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@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
>
>

--
Mark Yao


\
 
 \ /
  Last update: 2016-07-26 12:41    [W:0.060 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site