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

[Giovanni Campagna]

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 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.
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.

> 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.

Giovanni