<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-24 19:55 GMT+08:00 Ander Conselvan de Oliveira <<a href="mailto:conselvan2@gmail.com" target="_blank">conselvan2@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 03/17/2014 11:05 AM, Jammy Zhou wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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? </blockquote> </div> 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.</blockquote> <div> </div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - 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. </blockquote> </div> Choosing the backend automatically would be better, but otherwise that would be a reasonable approach if a split were to be made. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""> 2014-03-13 22:02 GMT+08:00 Ander Conselvan de Oliveira </div> <<a href="mailto:conselvan2@gmail.com" target="_blank">conselvan2@gmail.com</a> <mailto:<a href="mailto:conselvan2@gmail.com" target="_blank">conselvan2@gmail.com</a>>>:<div class=""> From: Ander Conselvan de Oliveira <<a href="mailto:ander.conselvan.de.oliveira@intel.com" target="_blank">ander.conselvan.de.oliveira@intel.com</a> </div> <mailto:<a href="mailto:ander.conselvan.de.oliveira@intel.com" target="_blank">ander.conselvan.de.oliveira@intel.com</a>>><div class=""> 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? </div></blockquote> 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.<div class=""> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> </div> 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 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""> 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 </div> <a href="http://configure.ac" target="_blank">configure.ac</a> <<a href="http://configure.ac" target="_blank">http://configure.ac</a>> | 7 +-<div><div class="h5"> 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 </div></div> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> </blockquote></div> </div></div>