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

[Pekka Paalanen]

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.

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


Thanks,
pq