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

[Boris BREZILLON]

On Thu, 3 Jul 2014 11:14:48 +0200
Giovanni Campagna <scampa.giovanni at gmail.com> wrote:

> 2014-07-03 10:48 GMT+02:00 Boris BREZILLON <boris.brezillon at free-electrons.com>:
> > 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.
> 
> It might get your working EGL, but it's not a complete solution,
> because buffer management is limited to linear CPU-addressable "dumb"
> buffers, which is probably not the most efficient choice (altough how
> much slower it gets depends on the driver and on the HWl).

I'm only providing DUMB ioctls (through the CMA GEM implementation), so
it should be enough for me, isn't it.

> 
> > 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.
> >
> > I tried to get EGL working with my DRM device and it always ask for an
> > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this
> > point).
> >
> > First of all, am I mistaken in thinking this series could solve my
> > issue ?
> 
> Indeed, using my patch stack (patches 2 and 3) you will have a working
> GBM device that will allocate GPU memory using the "dumb" interface.
> If your driver is then able to upload this buffers to the plane HW (or
> directly capable of allocating in GPU memory), that may be good enough
> for you.
> OTOH, this will not provide the wayland clients with the ability to
> render directly to the plane buffers, because the "dumb" interface
> does not provide global names that can be shared between processes,
> therefore clients will have to render into a shared memory location,
> that then the wayland compositor (weston, I assume) will have to
> memcpy into a GBM allocated buffer.

Indeed, I'm using weston (just forgot to mention it).

> If you want to avoid that, you will need to design an ioctl interface
> for your driver to allocate buffers, then write a "winsys" for the
> userspace side that uses those ioctls (directly or through libdrm) -
> first it allocates the buffer with your driver specific ioctl and then
> calls GEM_FLINK to get the global name, which can be passed to weston
> and in there to gbm_bo_import().
> If your HW is uncapable of GL rendering (and thus you want to use SW
> rendering always) is quite likely that your driver will not be that
> different from
> dri_kms_swrast, except that will be able to share buffers (patch 3)
> using GEM names.

Okay, thanks for these enlightenment. I'll try to get the
dri_kms_swrast first and then see if I need performance
improvements ;-).

> 
> > If not, could you tell me on which branch (or which tag) you based
> > your work ?
> >
> > I'm asking this because I tried to apply your patches on top of the
> > master branch (a few days ago), and after fixing some conflict I got a
> > segfault (sorry, I don't have the backtrace anymore :-(, but this was
> > related to negative stride value which was implying faulty memory
> > access).
> 
> The patches were made against an old version of mesa, and the build
> system was updated meanwhile. Emil said he will rebase them, and that
> will happen in a couple days. You should just wait until they land.

Perfect!
Emil, could you add me in Cc of this future submission ?

Thanks for taking the time to answer to my questions.

Best Regards,

Boris

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