[Mesa-dev] [PATCH 0/8] Native GBM backends and map/unmap support
Jammy Zhou
jammy.zhou at gmail.com
Thu Apr 10 06:38:11 PDT 2014
2014-03-24 19:55 GMT+08:00 Ander Conselvan de Oliveira <conselvan2 at gmail.com
>:
> 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.
Shouldn't EGL related logic be handled by different GBM backends (i.e, DRI
backend and Gallium backend)? And the GBM main library can be decoupled
cleanly, although it should be used together with EGL. Besides, I think the
split is also beneficial for binary EGL/ES2.0 drivers, which are quite
popular on ARM platforms.
>
>
> - 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140410/93365149/attachment-0001.html>
More information about the mesa-dev
mailing list