Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
> On 20 April 2016 at 03:52, Rob Herring wrote: >> On Tue, Apr 19, 2016 at 8:03 PM, Emil Velikov >> wrote: >>> Looking at this patch and Varad's work >>> there a hunk missing here [1]. Did you not come across the issue in >>> question ? >> >> I don't think it is a real issue. I traced the code for >> createNewDrawable and it only saves dri2_surf ptr, but never >> references the contents of it. And I didn't find any problems when >> reverting it and testing, so I dropped that patch. >> > Fair enough. Varad can you confirm if you've seen any actual uses for > [1] or was it based upon code observation ? > We never reference dri2_surf in the createNewDrawable path, so I guess it was just a precautionary measure at the time. We can do away with the patch. Thanks, Varad >>> >>> Apologies that I'm the bearer of bad news and thank you for working on this. >> >> Apologies for pretending I know what I'm doing. :) >> > Not a problem. It's not like you've done any of it with ill intent. > Plus I'm happy to share as much knowledge I have in the area. > > -Emil > > [1] > https://github.com/varadgautam/mesa/commit/96c533fd62db4bb21f0a778ad16848da2df24fd6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On 20 April 2016 at 03:52, Rob Herring wrote:
> On Tue, Apr 19, 2016 at 8:03 PM, Emil Velikov
> wrote:
>> Hi Rob,
>>
>> Please bear in mind that there's a fair bit of comments, but before
>> all don't mix refactoring and new code. Please ?
>
> Okay.
>
Thanks.
>> On 15 April 2016 at 17:03, Rob Herring wrote:
>>> Add support for creating images from Android native buffers with dma-buf
>>> fd. As dma-buf support also requires DRI image loader extension, add
>>> that as well.
>>>
>>> This is based on several originally patches written by Varad Gautam.
>>> I've collapsed them down to one and done a bit of reformatting. dma-bufs
>>> and GEM handles are now both supported instead of being compile time
>>> selection.
>> How did you test this ? Afaict making this (at least in current shape)
>> isn't possible to be a runtime decision.
>
> For the GEM handle case, I just tried not to change things. I think
> the android-x86 folks have tested a similar version of this and they
> would use the GEM handle case.
>
Last time I've looked things did differ a fair bit wrt this patch. Not
a big deal though.
> What exactly determines libEGL and dri module are dmabuf capable? The
> image loader extension?
>
From the loader side: presence of the image_loader extension +
detection of the module's image extension. And the opposite from the
module side - exposes image extension + uses the image_loader one.
>>
>>> + EGLint attr_list[14];
>>> + attr_list[0] = EGL_WIDTH;
>>> + attr_list[1] = buf->width;
>>> + attr_list[2] = EGL_HEIGHT;
>>> + attr_list[3] = buf->height;
>>> + attr_list[4] = EGL_LINUX_DRM_FOURCC_EXT;
>>> + attr_list[5] = get_fourcc(get_format(buf->format));
>>> + attr_list[6] = EGL_DMA_BUF_PLANE0_FD_EXT;
>>> + attr_list[7] = fd;
>>> + attr_list[8] = EGL_DMA_BUF_PLANE0_PITCH_EXT;
>>> + attr_list[9] = buf->stride * get_format_bpp(buf->format);
>>> + attr_list[10] = EGL_DMA_BUF_PLANE0_OFFSET_EXT;
>>> + attr_list[11] = 0;
>>> + attr_list[12] = EGL_NONE;
>>> +
>> Just throw these directly into a const attr_list[].
>
> How can it be const when most of the values are variables?
>
Something like below. It is a valid C, right ?
const EGLint attr_list[14] = {
EGL_WIDTH, buf->width,
EGL_HEIGHT, .
};
>
> So dri2_loader and image loader are mutually exclusive?
>
Sadly there are there more than these two, but yes. If you have (start
using one) you cannot opt for the other at a later stage.
>> Looking at the other backends - wayland does a related thing:
>> - Open a node
>> - Am I render node ? No, add the dri2_loader extension to the list.
>
> Okay. Could I key off of that for dma-buf support as well?
>
Cannot really parse that. Please elaborate.
If you're asking "can I use the wayland approach/heuristics" - yes you
can. Search for drmGetNodeTypeFromFd.
> I'm not really a fan of adding yet another thing to Android device
> config that has to be set correctly or things fall over. There are
> enough already. Surely, the code can be smart enough to do the right
> thing based on which node or drv PRIME support.
>
Indeed it can if one uses the wayland approach. Namely: determine
"render/dmabuf or gem" based on the node type and populate libEGL
extension list appropriately.
>> Looking at this patch and Varad's work
>> there a hunk missing here [1]. Did you not come across the issue in
>> question ?
>
> I don't think it is a real issue. I traced the code for
> createNewDrawable and it only saves dri2_surf ptr, but never
> references the contents of it. And I didn't find any problems when
> reverting it and testing, so I dropped that patch.
>
Fair enough. Varad can you confirm if you've seen any actual uses for
[1] or was it based upon code observation ?
>>
>> Apologies that I'm the bearer of bad news and thank you for working on this.
>
> Apologies for pretending I know what I'm doing. :)
>
Not a problem. It's not like you've done any of it with ill intent.
Plus I'm happy to share as much knowledge I have in the area.
-Emil
[1]
https://github.com/varadgautam/mesa/commit/96c533fd62db4bb21f0a778ad16848da2df24fd6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On Tue, Apr 19, 2016 at 11:02 PM, Rob Herring wrote: >> It would ofc be good to make sure we don't break things for >> android-x86, but I think they would stick on dri2 + pre-atomic state >> w/ compile time build decisions until enough of the desktop gpu's >> support atomic.. although maybe it helps to switch them over to >> prime+render without switching to gbm_gralloc and kms hwc stuff yet? > > I'm not sure that will work without a lot of work to drm_gralloc to > support using both the render and card nodes and prime support for > each gpu. > > gbm_gralloc and non-atomic kms in hwc seems like the quickest path to > me, but I may be missing something. hmm, yeah, I guess if it was straightforward to add pageflip support in kms hwc, that sounds like a good option, since all the drivers that android-x86 cares about should support prime+render BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On Tue, Apr 19, 2016 at 8:43 PM, Rob Clark wrote: > On Tue, Apr 19, 2016 at 9:03 PM, Emil Velikov > wrote: >> Hi Rob, >> >> Please bear in mind that there's a fair bit of comments, but before >> all don't mix refactoring and new code. Please ? >> >> On 15 April 2016 at 17:03, Rob Herring wrote: >>> Add support for creating images from Android native buffers with dma-buf >>> fd. As dma-buf support also requires DRI image loader extension, add >>> that as well. >>> >>> This is based on several originally patches written by Varad Gautam. >>> I've collapsed them down to one and done a bit of reformatting. dma-bufs >>> and GEM handles are now both supported instead of being compile time >>> selection. >> How did you test this ? Afaict making this (at least in current shape) >> isn't possible to be a runtime decision. > > Just a drive-by comment, but seems like most of the main drivers (x86 > and arm, minus perhaps the x86 server gpus, which are probably not > interesting in this context) support DRIVER_PRIME + DRIVER_RENDER.. > > So possibly we don't need to keep support for a runtime decision.. and > almost certainly all the drivers that support atomic (which I think is > required for what Rob is working on) support prime+render, so in the > worst case we could have a compile time decision between "old world" > and "new world"? It was I guess. But we could have a mixture on android-x86. In theory, Intel should work with new world (though there are issues to debug). Radeon/Nouveau/vmwgfx are not there yet due to no atomic support. > It would ofc be good to make sure we don't break things for > android-x86, but I think they would stick on dri2 + pre-atomic state > w/ compile time build decisions until enough of the desktop gpu's > support atomic.. although maybe it helps to switch them over to > prime+render without switching to gbm_gralloc and kms hwc stuff yet? I'm not sure that will work without a lot of work to drm_gralloc to support using both the render and card nodes and prime support for each gpu. gbm_gralloc and non-atomic kms in hwc seems like the quickest path to me, but I may be missing something. Rob ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On Tue, Apr 19, 2016 at 8:03 PM, Emil Velikov wrote:
> Hi Rob,
>
> Please bear in mind that there's a fair bit of comments, but before
> all don't mix refactoring and new code. Please ?
Okay.
> On 15 April 2016 at 17:03, Rob Herring wrote:
>> Add support for creating images from Android native buffers with dma-buf
>> fd. As dma-buf support also requires DRI image loader extension, add
>> that as well.
>>
>> This is based on several originally patches written by Varad Gautam.
>> I've collapsed them down to one and done a bit of reformatting. dma-bufs
>> and GEM handles are now both supported instead of being compile time
>> selection.
> How did you test this ? Afaict making this (at least in current shape)
> isn't possible to be a runtime decision.
For the GEM handle case, I just tried not to change things. I think
the android-x86 folks have tested a similar version of this and they
would use the GEM handle case.
[...]
>> + fd = get_native_buffer_fd(dri2_surf->buffer);
>> + if (fd >= 0) {
> As we're missing the dri2_loader extension during init, this should
> always be. If it's not ... things have gone horribly wrong.
>
>> + int stride = dri2_surf->buffer->stride *
>> + get_format_bpp(dri2_surf->buffer->format);
>> + dri2_surf->dri_image =
>> + dri2_dpy->image->createImageFromFds(dri2_dpy->dri_screen,
>> + dri2_surf->base.Width,
>> + dri2_surf->base.Height,
>> + get_fourcc(format),
>> + &fd,
>> + 1,
>> + &stride,
>> + &offset,
>> + dri2_surf);
>> + return 0;
>> + }
> With the above said all that follows here should be nuked imho. Adding
> dri2 fallbacks in image/dri3 code does not sound like a good idea.
Okay, I'm not sure why Varad added it then.
>> + name = get_native_buffer_name(dri2_surf->buffer);
>> + if (name) {
>> + dri2_surf->dri_image =
>> + dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen,
>> + dri2_surf->base.Width,
>> + dri2_surf->base.Height,
>> + format,
>> + name,
>> + dri2_surf->buffer->stride,
>> + dri2_surf);
>> + return 0;
>> + }
>> + return -1;
>> +}
>> +
>> +static int
>> +droid_image_get_buffers(__DRIdrawable *driDrawable,
>> + unsigned int format,
>> + uint32_t *stamp,
>> + void *loaderPrivate,
>> + uint32_t buffer_mask,
>> + struct __DRIimageList *images)
>> +{
>> + struct dri2_egl_surface *dri2_surf = loaderPrivate;
>> +
>> + if (get_back_bo(dri2_surf) < 0)
>> + return 0;
>> +
>> + images->image_mask = __DRI_IMAGE_BUFFER_BACK;
>> + images->back = dri2_surf->dri_image;
>> +
>> + return 1;
>> +}
>> +
>> static EGLBoolean
>> droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw)
>> {
>> @@ -325,13 +443,14 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
>> _EGLSurface *draw)
>> }
>>
>> static _EGLImage *
>> -dri2_create_image_android_native_buffer(_EGLDisplay *disp, _EGLContext *ctx,
>> +dri2_create_image_android_native_buffer(_EGLDriver *drv, _EGLDisplay *disp,
>> +_EGLContext *ctx,
>> struct ANativeWindowBuffer *buf)
>> {
>> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> struct dri2_egl_image *dri2_img;
>> - int name;
>> - EGLint format;
>> + __DRIimage *dri_image;
>> + int name, fd;
>>
>> if (ctx != NULL) {
>>/* From the EGL_ANDROID_image_native_buffer spec:
>> @@ -351,59 +470,54 @@ dri2_create_image_android_native_buffer(_EGLDisplay
>> *disp, _EGLContext *ctx,
>>return NULL;
>> }
>>
>> + fd = get_native_buffer_fd(buf);
>> + if (fd >= 0) {
> Replying on get_native_buffer_fd feels strange. Imagine the following:
>
> - libEGL capable of image/dri3/dmabuf
> - dri module also capable.
> - gralloc implementation not capable.
> - libEGL and dri attempt to work with image/dri3... and suddenly
> gralloc forces them into dri2. Then again not (m)any things are done
> with it, plus both sides of the equation (predominantly the dri
> module) has no idea that it has to fall back.
What exactly determines libEGL and dri module are dmabuf capable? The
image loader extension?
>
>> + EGLint attr_list[14];
>> + attr_list[0] = EGL_WIDTH;
>> + attr_list[1] = buf->width;
>> + attr_list[2] = EGL_HEIGHT;
>> + attr
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On Tue, Apr 19, 2016 at 9:03 PM, Emil Velikov wrote:
> Hi Rob,
>
> Please bear in mind that there's a fair bit of comments, but before
> all don't mix refactoring and new code. Please ?
>
> On 15 April 2016 at 17:03, Rob Herring wrote:
>> Add support for creating images from Android native buffers with dma-buf
>> fd. As dma-buf support also requires DRI image loader extension, add
>> that as well.
>>
>> This is based on several originally patches written by Varad Gautam.
>> I've collapsed them down to one and done a bit of reformatting. dma-bufs
>> and GEM handles are now both supported instead of being compile time
>> selection.
> How did you test this ? Afaict making this (at least in current shape)
> isn't possible to be a runtime decision.
Just a drive-by comment, but seems like most of the main drivers (x86
and arm, minus perhaps the x86 server gpus, which are probably not
interesting in this context) support DRIVER_PRIME + DRIVER_RENDER..
So possibly we don't need to keep support for a runtime decision.. and
almost certainly all the drivers that support atomic (which I think is
required for what Rob is working on) support prime+render, so in the
worst case we could have a compile time decision between "old world"
and "new world"?
It would ofc be good to make sure we don't break things for
android-x86, but I think they would stick on dri2 + pre-atomic state
w/ compile time build decisions until enough of the desktop gpu's
support atomic.. although maybe it helps to switch them over to
prime+render without switching to gbm_gralloc and kms hwc stuff yet?
Not sure.. but at least seems like a possibility if it makes things
easier on the mesa side..
BR,
-R
>> The dma-buf support is also re-written to use common
>> dri2_create_image_dma_buf function in egl_dri2.c.
>>
>> Cc: Varad Gautam
>> Cc: Rob Clark
>> Cc: Emil Velikov
>> Signed-off-by: Rob Herring
>> ---
>> src/egl/drivers/dri2/egl_dri2.h | 1 +
>> src/egl/drivers/dri2/platform_android.c | 206
>> +---
>> 2 files changed, 165 insertions(+), 42 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.h
>> b/src/egl/drivers/dri2/egl_dri2.h
>> index ef79939..a0fbe6f 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.h
>> +++ b/src/egl/drivers/dri2/egl_dri2.h
>> @@ -285,6 +285,7 @@ struct dri2_egl_surface
>> #ifdef HAVE_ANDROID_PLATFORM
>> struct ANativeWindow *window;
>> struct ANativeWindowBuffer *buffer;
>> + __DRIimage *dri_image;
>>
>> /* EGL-owned buffers */
>> __DRIbuffer *local_buffers[__DRI_BUFFER_COUNT];
>> diff --git a/src/egl/drivers/dri2/platform_android.c
>> b/src/egl/drivers/dri2/platform_android.c
>> index 41840aa..233a829 100644
>> --- a/src/egl/drivers/dri2/platform_android.c
>> +++ b/src/egl/drivers/dri2/platform_android.c
>> @@ -64,6 +64,45 @@ get_format_bpp(int native)
>> return bpp;
>> }
>>
>> +/* createImageFromFds requires fourcc format */
>> +static int get_fourcc(int format)
>> +{
>> + switch(format) {
>> + case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
>> + case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
>> + case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
>> + case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
>> + case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
>> + }
>> + return -1;
>> +}
>> +
>> +static int get_format(int format)
>> +{
>> + switch (format) {
>> + case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FORMAT_ARGB;
>> + case HAL_PIXEL_FORMAT_RGB_565: return __DRI_IMAGE_FORMAT_RGB565;
>> + case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FORMAT_ABGR;
>> + case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
>> + case HAL_PIXEL_FORMAT_RGB_888:
>> + /* unsupported */
>> + default:
>> + _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x",
>> format);
>> + }
>> + return -1;
>> +}
>> +static int
>> +get_native_buffer_fd(struct ANativeWindowBuffer *buf)
>> +{
>> + native_handle_t *handle = (native_handle_t *)buf->handle;
>> + /*
>> +* Various gralloc implementations exist, but the dma-buf fd tends
>> +* to be first. Access it directly to avoid a dependency on specific
>> +* gralloc versions.
>> +*/
>> + return (handle && handle->numFds) ? handle->data[0] : -1;
>> +}
>> +
>> static int
>> get_native_buffer_name(struct ANativeWindowBuffer *buf)
>> {
>> @@ -297,6 +336,85 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay
>> *disp, _EGLSurface *surf)
>> return EGL_TRUE;
>> }
>>
>> +
>> +static int
>> +get_back_bo(struct dri2_egl_surface *dri2_surf)
>> +{
>> + struct dri2_egl_display *dri2_dpy =
>> + dri2_egl_display(dri2_surf->base.Resource.Display);
>> + int format;
>> + int offset = 0, fd;
>> + int name;
>> +
>> + if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
>> + /* try to dequeue the next ba
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
Hi Rob,
Please bear in mind that there's a fair bit of comments, but before
all don't mix refactoring and new code. Please ?
On 15 April 2016 at 17:03, Rob Herring wrote:
> Add support for creating images from Android native buffers with dma-buf
> fd. As dma-buf support also requires DRI image loader extension, add
> that as well.
>
> This is based on several originally patches written by Varad Gautam.
> I've collapsed them down to one and done a bit of reformatting. dma-bufs
> and GEM handles are now both supported instead of being compile time
> selection.
How did you test this ? Afaict making this (at least in current shape)
isn't possible to be a runtime decision.
> The dma-buf support is also re-written to use common
> dri2_create_image_dma_buf function in egl_dri2.c.
>
> Cc: Varad Gautam
> Cc: Rob Clark
> Cc: Emil Velikov
> Signed-off-by: Rob Herring
> ---
> src/egl/drivers/dri2/egl_dri2.h | 1 +
> src/egl/drivers/dri2/platform_android.c | 206
> +---
> 2 files changed, 165 insertions(+), 42 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index ef79939..a0fbe6f 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -285,6 +285,7 @@ struct dri2_egl_surface
> #ifdef HAVE_ANDROID_PLATFORM
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> + __DRIimage *dri_image;
>
> /* EGL-owned buffers */
> __DRIbuffer *local_buffers[__DRI_BUFFER_COUNT];
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_android.c
> index 41840aa..233a829 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -64,6 +64,45 @@ get_format_bpp(int native)
> return bpp;
> }
>
> +/* createImageFromFds requires fourcc format */
> +static int get_fourcc(int format)
> +{
> + switch(format) {
> + case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
> + case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
> + case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
> + case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
> + case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
> + }
> + return -1;
> +}
> +
> +static int get_format(int format)
> +{
> + switch (format) {
> + case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FORMAT_ARGB;
> + case HAL_PIXEL_FORMAT_RGB_565: return __DRI_IMAGE_FORMAT_RGB565;
> + case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FORMAT_ABGR;
> + case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
> + case HAL_PIXEL_FORMAT_RGB_888:
> + /* unsupported */
> + default:
> + _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
> + }
> + return -1;
> +}
> +static int
> +get_native_buffer_fd(struct ANativeWindowBuffer *buf)
> +{
> + native_handle_t *handle = (native_handle_t *)buf->handle;
> + /*
> +* Various gralloc implementations exist, but the dma-buf fd tends
> +* to be first. Access it directly to avoid a dependency on specific
> +* gralloc versions.
> +*/
> + return (handle && handle->numFds) ? handle->data[0] : -1;
> +}
> +
> static int
> get_native_buffer_name(struct ANativeWindowBuffer *buf)
> {
> @@ -297,6 +336,85 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf)
> return EGL_TRUE;
> }
>
> +
> +static int
> +get_back_bo(struct dri2_egl_surface *dri2_surf)
> +{
> + struct dri2_egl_display *dri2_dpy =
> + dri2_egl_display(dri2_surf->base.Resource.Display);
> + int format;
> + int offset = 0, fd;
> + int name;
> +
> + if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
> + /* try to dequeue the next back buffer */
> + if (!dri2_surf->buffer && !droid_window_dequeue_buffer(dri2_surf))
> + return -1;
> +
> + /* free outdated buffers and update the surface size */
> + if (dri2_surf->base.Width != dri2_surf->buffer->width ||
> + dri2_surf->base.Height != dri2_surf->buffer->height) {
> + droid_free_local_buffers(dri2_surf);
> + dri2_surf->base.Width = dri2_surf->buffer->width;
> + dri2_surf->base.Height = dri2_surf->buffer->height;
> + }
> + }
> +
Might want to flesh this out into separate function. The same hunk is
in droid_get_buffers_with_format() already.
> + if(dri2_surf->buffer == NULL)
> + return -1;
> +
> + format = get_format(dri2_surf->buffer->format);
> +
> + fd = get_native_buffer_fd(dri2_surf->buffer);
> + if (fd >= 0) {
As we're missing the dri2_loader extension during init, this should
always be. If it's not ... things have gone horribly wrong.
> + int stride = dri2_surf->buffer->stride *
> + get_format_bpp(dri2_surf->buffer->format);
> + dri2_surf->dri_image =
> + dri2_dpy->image->c
[Mesa-dev] [PATCH] egl: android: add dma-buf fd support
Add support for creating images from Android native buffers with dma-buf
fd. As dma-buf support also requires DRI image loader extension, add
that as well.
This is based on several originally patches written by Varad Gautam.
I've collapsed them down to one and done a bit of reformatting. dma-bufs
and GEM handles are now both supported instead of being compile time
selection. The dma-buf support is also re-written to use common
dri2_create_image_dma_buf function in egl_dri2.c.
Cc: Varad Gautam
Cc: Rob Clark
Cc: Emil Velikov
Signed-off-by: Rob Herring
---
src/egl/drivers/dri2/egl_dri2.h | 1 +
src/egl/drivers/dri2/platform_android.c | 206 +---
2 files changed, 165 insertions(+), 42 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index ef79939..a0fbe6f 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -285,6 +285,7 @@ struct dri2_egl_surface
#ifdef HAVE_ANDROID_PLATFORM
struct ANativeWindow *window;
struct ANativeWindowBuffer *buffer;
+ __DRIimage *dri_image;
/* EGL-owned buffers */
__DRIbuffer *local_buffers[__DRI_BUFFER_COUNT];
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 41840aa..233a829 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -64,6 +64,45 @@ get_format_bpp(int native)
return bpp;
}
+/* createImageFromFds requires fourcc format */
+static int get_fourcc(int format)
+{
+ switch(format) {
+ case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
+ case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
+ case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
+ case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
+ case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
+ }
+ return -1;
+}
+
+static int get_format(int format)
+{
+ switch (format) {
+ case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FORMAT_ARGB;
+ case HAL_PIXEL_FORMAT_RGB_565: return __DRI_IMAGE_FORMAT_RGB565;
+ case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FORMAT_ABGR;
+ case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
+ case HAL_PIXEL_FORMAT_RGB_888:
+ /* unsupported */
+ default:
+ _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
+ }
+ return -1;
+}
+static int
+get_native_buffer_fd(struct ANativeWindowBuffer *buf)
+{
+ native_handle_t *handle = (native_handle_t *)buf->handle;
+ /*
+* Various gralloc implementations exist, but the dma-buf fd tends
+* to be first. Access it directly to avoid a dependency on specific
+* gralloc versions.
+*/
+ return (handle && handle->numFds) ? handle->data[0] : -1;
+}
+
static int
get_native_buffer_name(struct ANativeWindowBuffer *buf)
{
@@ -297,6 +336,85 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *surf)
return EGL_TRUE;
}
+
+static int
+get_back_bo(struct dri2_egl_surface *dri2_surf)
+{
+ struct dri2_egl_display *dri2_dpy =
+ dri2_egl_display(dri2_surf->base.Resource.Display);
+ int format;
+ int offset = 0, fd;
+ int name;
+
+ if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
+ /* try to dequeue the next back buffer */
+ if (!dri2_surf->buffer && !droid_window_dequeue_buffer(dri2_surf))
+ return -1;
+
+ /* free outdated buffers and update the surface size */
+ if (dri2_surf->base.Width != dri2_surf->buffer->width ||
+ dri2_surf->base.Height != dri2_surf->buffer->height) {
+ droid_free_local_buffers(dri2_surf);
+ dri2_surf->base.Width = dri2_surf->buffer->width;
+ dri2_surf->base.Height = dri2_surf->buffer->height;
+ }
+ }
+
+ if(dri2_surf->buffer == NULL)
+ return -1;
+
+ format = get_format(dri2_surf->buffer->format);
+
+ fd = get_native_buffer_fd(dri2_surf->buffer);
+ if (fd >= 0) {
+ int stride = dri2_surf->buffer->stride *
+ get_format_bpp(dri2_surf->buffer->format);
+ dri2_surf->dri_image =
+ dri2_dpy->image->createImageFromFds(dri2_dpy->dri_screen,
+ dri2_surf->base.Width,
+ dri2_surf->base.Height,
+ get_fourcc(format),
+ &fd,
+ 1,
+ &stride,
+ &offset,
+ dri2_surf);
+ return 0;
+ }
+ name = get_native_buffer_name(dri2_surf->buffer);
+ if (name) {
+ dri2_surf->dri_image =
+ dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen,
+ dri2_surf->base.Width
