How to configure/use/assign hardware pipeline/plane for specific application?

[Vikas Patil]

Thanks Pekka for explaining it. May be I will have a look once Daniel
shares the latest branch details.

On Fri, Jun 9, 2017 at 5:10 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 9 Jun 2017 15:02:03 +0530
> Vikas Patil <vikasmpatil at gmail.com> wrote:
>
>> On Fri, Jun 9, 2017 at 1:16 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> >
>> > On Fri, 9 Jun 2017 12:31:22 +0530
>> > Vikas Patil <vikasmpatil at gmail.com> wrote:
>> >
>> > > Dear All,
>> > >
>> > > I am using wayland/weston 1.11.0 (with ivi-shell and drm-backend) with
>> > > DRA7xx (TI's automotive SoC) and Linux  4.4. I am investigating on how
>> > > could wayalnd based application can be assigned to use particular pipeline.
>> > >
>> > > Use-case details:
>> > > As TI's DRA7xx SoC provides 1 graphics and 3 video pipeline (also refereed
>> > > as plane).  For example I would like to assign GFX pipeline to GUI
>> > > application, VID1 pipeline to video player, VID2
>> > > pipeline to camera application and VID3 for some other application.
>> > >
>> > > I can see currently weston uses only GFX pipeline.  Is there a way to do
>> > > this using wayland/weston? What needs to be done to achieve this?
>> >
>> > Hi,
>> >
>> > the proper solution is to get the atomic modesetting patch series by
>> > Daniel Stone reviewed, finalized, and merged. This is the foundation
>> > for how weston could use additional DRM planes at all.
>> >
>> > Once that is done, the window manager needs to ensure that the
>> > scenegraph is always compatible with putting the surfaces you want on
>> > the DRM planes you want. With ivi-shell that is very possible as you
>> > have unique identification for every application surface. Then, there
>> > might be tweaks needed in the libweston DRM-backend to achieve the
>> > correct automatic surface/plane associations.
>> >
>> > The major point here is that one does not explicitly configure a
>> > surface for a DRM plane in Weston or via protocol. The DRM planes will
>> > be used automatically for any surfaces that might fit.
>>
>> Thanks a lot for your quick comments.
>>
>> What are the fitting criteria for mapping surfaces to plane
>> automatically? What happens if number of surfaces are more than
>> available planes, which surface gets the plane (in case some specific
>> application desire to use plane not the other apps)? We have a use
>> case where we want multiple applications to use the particular plane
>> only?
>>
>> How the other h/w features for planes (z-order, global alpha, rotation
>> ) are handled with this? Is there any way to utilize this also?
>
> Hi,
>
> the scenegraph is essentially a stack of views (surfaces). A simple
> algorithm is to start from the top and check view by view:
>
> - is the buffer compatible with any available DRM planes
> - does the view fit on a plane
> - given what is laid above this view in the scenegraph, is it even
>   possible to promote the view onto a plane or would it violate
>   z-ordering, transparency/blending, etc.
> - ...
>
> The difficult part is to find the optimal view/plane assignment, and
> the above greedy algorithm is not guaranteed to find that optimal
> solution.
>
> z-order, alpha, rotation, all that comes from the scenegraph and is
> taken into account when assigning planes. After all, the visual result
> must be according to Weston's scenegraph. Using scenegraph features
> that cannot be realized with DRM planes is a sure way to prevent the
> view from ever going on a plane.
>
> Any views that were not assigned to overlay planes will be flattened by
> the renderer onto the primary DRM plane.
>
> That would be the starting point. A more sophisticated example would be
> Android's HWC2 (hardware composer).
>
>> > Weston's  architecture currently in master (let alone in something as old as
>> > 1.11) does not support interactions between the shell
>> > plugin and the backend plugin to explicitly and permanently configure
>> > the DRM plane assignments. It's not inconceivable to add the necessary
>> > infrastructure, but I would see if the implicit approach works first.
>> >
>>
>> > If you want to give the patch series a go, I believe Daniel can point
>> > you to the latest branches.
>> >
>> I could give a try but not sure if the kernel from TI BSP (4.4.23)
>> supports atomic mode setting (generic and TI SoC specific if any). How
>> to to check if atomic mode setting is supported or not in kernel? Do I
>> also need to update the wayland/weston to latest version or I can
>> apply the patches to 1.11.0? I also need to know how to test then if
>> able to apply the patches and run the weston? Which version of
>> Wayland-ivi-extension I need to use with these patches or first need
>> to tested with desktop-shell?
>>
>> I found the patches at https://phabricator.freedesktop.org/T7595 but
>> it would be helpful to get the branch details. I see this patches are
>> tested again intel and rockchip hw. Are they generic and supposed to
>> work on other SoCs (DRA7XX TI) or some feature required to be
>> supported in kernel/bsp to utilize this?
>
> Daniel could answer those questions much better than I.
>
> The patches in Phabricator are probably not even near the latest. We've
> been doing review on the mailing list, but it has been a long while
> since the last post, so I think there are even more recent branches.
>
> As for wayland-ivi-extension, I don't think any of us has any idea, but
> OTOH, you should not need anything new from it. Applications will not
> be aware of any of this at all. Also your window manager does not need
> any new interfaces, it only needs to make the window ordering and
> positioning "fruitful". Fruitful depends on the quality of the plane
> assigment in Weston's DRM-backend.
>
> That's one benefit of automatic plane assignment: you don't need any
> new protocols or interfaces anywhere from or above the compositor. At
> least if your applications are already providing buffers that are
> scanout-capable.
>

Regards,
Vikash