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

[Boris BREZILLON]

Hello Giovanni,

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

I'm just curious: what are you using this dri_kms_swrast implementation
for ?

Okay, my real question here is: Is there other people trying to do what
I'm doing or do you need it for another use case :-) ?

Best Regards,

Boris



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