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

[Boris BREZILLON]

On Thu, 3 Jul 2014 15:46:14 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 3 Jul 2014 14:15:34 +0200
> Boris BREZILLON <boris.brezillon at free-electrons.com> wrote:
> 
> > 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:
> > > > > 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.
> 
> Note, that the protocol there does not address the problem of
> compatibility at all, and the implementation does not even advertise any
> pixel formats. It is all based on luck and clairvoyance, that the client
> just happens to create exactly the right kind of dmabufs that the
> compositor can use. If you fail that, the client gets kicked or you
> get a mess on the screen. Obviously not upstreamable material. ;-)
> 
> > > 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.
> 
> Oh, a video player! How do you get the video frames? Do you have
> hardware decoding? Can you perhaps decode straight into dmabufs? If
> yes, then you could use zlinux_dmabuf to throw those video frames to
> Weston zero-copy. Then the tricky part is to make Weston cope with those
> video frame buffers, as if they even attempt to go through the
> pixman-renderer, Weston will... hm, not sure what it does, but it won't
> work. So you have to somehow guarantee, that the surface which those
> buffers are targeting will *always* be assigned to an overlay.

Some SoCs have an HW decoder and yes I had dmabuf in mind to provide
zero copy from video decoder to DRM device ;-).

But I'm not even sure this video decoder is supported in mainline and
I'd like to get software decoding working first :-).

> 
> That may be a fair amount of hacking. Good luck! :-)

Yes that's what I'm realizing now. I thought the kernel driver would
be the most complicated part, but now that I'm working on user space
support I'd say developing the driver was quite easy :-).

Thanks for your support.

Boris

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