[Mesa-dev] [PATCH 0/8] Native GBM backends and map/unmap support

[Ander Conselvan de Oliveira]

On 03/17/2014 11:05 AM, Jammy Zhou wrote:
> Hi Ander,
>
> Some comments inline.
>
> And I have some further thinking about current GBM support, which is
> tied to specific implementation closely, although the GBM APIs are quite
> independent from mesa. I have some idea below to make GBM a generic
> solution. I'm not sure if anybody else in the community raised this
> before. What's your opinion?

Even though the APIs are independent from mesa, they were designed with 
the idea that GBM would be bundled with an EGL implementation. The logic 
for allocating buffers for a gbm_surface is in the EGL platform by the 
design. If GBM were to be split, that API would have to be changed, but 
in a way that would still let the EGL platform to be in control of the 
buffer allocation for surfaces.

> - Decouple the GBM main library as standard API from mesa, and a
> separate repository can be maintained for this library, which defines
> callbacks for backend to implement. It can be packaged separately from
> mesa by distros.
> - Build the DRI backend as a separate library (i.e, gbm_dri.so) just as
> the gallium backend, and it should still be part of mesa.
> - New native backend can be implemented (i.e, gbm_intel.so), and the GBM
> backend can be specified in some configuration file (i.e, /etc/gbm.conf)
> if several backends can be used.

Choosing the backend automatically would be better, but otherwise that 
would be a reasonable approach if a split were to be made.


> 2014-03-13 22:02 GMT+08:00 Ander Conselvan de Oliveira
> <conselvan2 at gmail.com <mailto:conselvan2 at gmail.com>>:
>
>     From: Ander Conselvan de Oliveira
>     <ander.conselvan.de.oliveira at intel.com
>     <mailto:ander.conselvan.de.oliveira at intel.com>>
>
>     Hi,
>
>     This patch series implements an API for mapping an unapping GBM buffer
>     objects. The native intel backend was implemented so that the map and
>     unmap functionality wouldn't have to be implemented in the DRI image
>
>
> Can you elaborate more about why the map/unmap functionality cannot be
> implemented in the DRI image extension?

There is no technical limitation, but that functionality falls out of 
the scope of the extension, which is to allow the implementation of 
EGLimage and associated extensions and some level of buffer sharing. It 
has grown quite a bit lately and, IMHO, a bit out of control too.

>
>     extension. A new EGL platform is necessary, since platform_drm.c
>     assumes it is run on top of a gbm device with the dri backend.
>
>
> The new gbm platform is quite similar as the existing drm platform, why
> not improve the drm platform to satisfy the new requirements? For
> example, some abstraction can be done to decouple gbm_dri backend
> dependency.

My approach was to duplicate first. You're right that there are code we 
can share between them, but I rather try to find the proper abstraction 
later and leave this out of the way for now.

Thanks,
Ander


>     This new platform is written so that it could support other native
>     backends, not only intel.
>
>     Comments are really welcome.
>
>     Thanks,
>     Ander
>
>     Ander Conselvan de Oliveira (8):
>        egl/drm: Rename dri2_egl_surface field gbm_surf to gbm_dri_surf
>        egl: Protect use of gbm_dri with ifdef HAVE_DRM_PLATFORM
>        gbm: Add a native intel backend
>        gbm_drm: Keep a reference to drm native objects
>        dri, i965: Add an extension for sharing the drm bufmgr
>        dri, i965: Add entry point for creating image from native handle
>        egl/dri: Add gbm platform
>        gbm: Add entry points for mapping and unmapping bos
>
>     configure.ac <http://configure.ac>                              |   7 +-
>       include/GL/internal/dri_interface.h       |  24 +-
>       src/egl/drivers/dri2/Makefile.am          |   5 +
>       src/egl/drivers/dri2/egl_dri2.c           |   8 +
>       src/egl/drivers/dri2/egl_dri2.h           |  16 +-
>       src/egl/drivers/dri2/platform_drm.c       |   6 +-
>       src/egl/drivers/dri2/platform_gbm.c       | 486
>     ++++++++++++++++++++++++++++++
>       src/egl/main/Makefile.am                  |   5 +
>       src/egl/main/egldisplay.c                 |   3 +-
>       src/egl/main/egldisplay.h                 |   1 +
>       src/gbm/Makefile.am                       |  14 +-
>       src/gbm/backends/dri/gbm_dri.c            |   3 +
>       src/gbm/backends/intel/gbm_intel.c        | 270 +++++++++++++++++
>       src/gbm/backends/intel/gbm_intel.h        |  76 +++++
>       src/gbm/main/backend.c                    |   2 +
>       src/gbm/main/common_drm.h                 |  13 +
>       src/gbm/main/gbm.c                        |  25 ++
>       src/gbm/main/gbm.h                        |  10 +
>       src/gbm/main/gbmint.h                     |   4 +
>       src/mesa/drivers/dri/common/dri_util.c    |   2 +
>       src/mesa/drivers/dri/common/dri_util.h    |   1 +
>       src/mesa/drivers/dri/i965/intel_regions.c |  50 +--
>       src/mesa/drivers/dri/i965/intel_regions.h |   6 +
>       src/mesa/drivers/dri/i965/intel_screen.c  |  46 ++-
>       24 files changed, 1044 insertions(+), 39 deletions(-)
>       create mode 100644 src/egl/drivers/dri2/platform_gbm.c
>       create mode 100644 src/gbm/backends/intel/gbm_intel.c
>       create mode 100644 src/gbm/backends/intel/gbm_intel.h
>
>     --
>     1.8.3.2
>
>     _______________________________________________
>     mesa-dev mailing list
>     mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>