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

Pekka Paalanen ppaalanen at gmail.com
Thu Jul 3 03:49:06 PDT 2014


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.

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.

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.


Thanks,
pq


More information about the mesa-dev mailing list