[Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM

[Boris BREZILLON]

On Thu, 3 Jul 2014 13:49:06 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 3 Jul 2014 12:10:36 +0200
> Boris BREZILLON <boris.brezillon at free-electrons.com> wrote:
> 
> > On Thu, 3 Jul 2014 12:24:44 +0300
> > Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 
> > > On Thu, 3 Jul 2014 10:48:26 +0200
> > > Boris BREZILLON <boris.brezillon at free-electrons.com> wrote:
> > > 
> > > > Hello Giovanni,
> > > > 
> > > > I have recently been working on a DRM/KMS driver which does not support
> > > > OpenGL rendering (it only provides plane composition functionalities):
> > > > [1].
> > > > 
> > > > If I understand correctly you patch series might solve some of the
> > > > issues I am facing.
> > > > 
> > > > I'm trying to get wayland working with HW cursor and several planes,
> > > > the problem is that it depends on GBM to provides drm plane and drm
> > > > cursor support.
> > > 
> > > Which compositor? All the dependencies are in the compositors, not
> > > Wayland per se.
> > 
> > Sorry, I meant weston not wayland.
> > 
> > > 
> > > If it is Weston, have you tried --use-pixman to avoid EGL altogether?
> > > I see Weston still tries to use GBM for cursor fbs, while primary fbs
> > > are dumb buffers, but then again, I'm not sure if cursors are supposed
> > > to support dumb buffers.
> > 
> > Yes weston works fine with --use-pixman, but then I can't use HW cursor
> > and drm overlay planes (because it requires gbm).
> > 
> > > 
> > > Weston's overlay planes code however totally depends on EGL to provide
> > > hw-capable buffers from clients. A software renderer support in EGL-DRM
> > > won't help in that.
> > 
> > Okay, if I understand correctly, this means I'll have to implement an
> > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ?
> 
> Well, uhh, I suppose...
> 
> That means you need to get clients actually rendering into hw-capable
> buffers, so that usually means having a GL(ES) rendering working on
> EGL Wayland platform, too.
> 
> Or, clients could use something like libva(?) to fill the buffers and
> use Mesa's internal wl_drm protocol to pass those to the compositor. If
> the compositor is able to initialize EGL_WL_bind_wayland_display
> extension, then with Mesa, the clients will have wl_drm available.
> Still probably requires working GLESv2 rendering for the EGL DRM/GBM
> platform, because the pixman renderer cannot handle anything else than
> wl_shm buffers.
> 
> Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb
> buffers, and put those into overlays (err, did dumb buffers support
> going on overlays, or were they primary plane only?). But if you have
> like less than 10 overlays in hw, that might be a net lose in
> performance.

I have, at most, 3 overlays (it depends on the HLCDC IP version), so
this might be an acceptable solution.

ITOH, I'd like to keep the implementation as clean as possible in order
to be able to base future work on offical weston versions (and tell me
if I'm wrong, but I'm not sure the proposed solution can ever make it to
the official weston version).

> 
> Or, you might go wild and have a hack on my hacky zlinux_dmabuf support
> in weston:
> http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP
> It is missing pixman-renderer integration, and the test client is
> intel-only, but if you hack around those, you can have clients filling
> dmabufs, sending those to Weston, and Weston using GBM to import them
> to put them on overlays via DRM - unless the scenegraph forces them to
> go through pixman-renderer in which case you are in a slight pickle.
> 

That sounds interesting!
I'll take a closer look at it.

> Warning: that weston branch may get rewritten or deleted without notice.
> 
> I guess the take-away from this is that DRM overlay planes have not
> really been considered for use with server nor client software rendering
> in Weston.

Yes, I kinda realize that know.

My main goal here is to provide a video player demo application where
the primary plane (or an overlay plane) is used to display video player
controls (play, pause, ...) and another plane is used to display video
content (using gstreamer or any other alternative).

This needs to be done using overlays in order to get acceptable
performances (avoid software rendering for plane composition), and
thus should use drm overlay planes.

I thought about developing or using an existing Qt application, but
AFAIU, the problem remains the same with Qt DRM/KMS backend: it depends
on EGL/GBM.

Please let me know if you have any other ideas.

Thanks.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com