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

[Pekka Paalanen]

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170609/823ad083/attachment.sig>