Hi Christian,
Thx for the suggestion. Actually I thought about dmabuf (ref project
proposal), but not about opening the EGL so using an internal mesa
function. Also eglExportDMABUFImageMESA is still tagged 'MESA'
(EGL_MESA_image_dma_buf_export). Compared to EGL_*EXT*_image_dma_buf_import
.
This need more thought so I will see later.
Also for dmabuf, 'ideally' the spec should just be improved to pass the fd
directly to OMX_UseBuffer. Some board went ahead and exposed that as a
vendor omx extension.
But so far st_omx_pipe_texture_from_eglimage_v1 mentioned in previous email
works fine (color issue is fixed now). So we will keep it like this for now.
Thx
Julien
On 13 July 2017 at 16:39, Christian König <deathsim...@vodafone.de> wrote:
> Hi Julien,
>
> sorry, totally missed that question.
>
> I think the cleanest approach would be that the OpenMAX state tracker
> dlopen()s the EGL and tries to export the eglImage into a dma_buf handle.
>
> No idea how to do this, but I'm pretty sure somebody on the mailing list
> should know the details how this can be solved.
>
> Regards,
> Christian.
>
>
> Am 13.07.2017 um 14:26 schrieb Julien Isorce:
>
> Hi,
>
> With Gurkirpal we have been blocked on this problem last week and that
> would be great to get some input.
> It is not really urgent because Gurkirpal switched to the encoder work for
> the time being.
>
> So the goal is from src/gallium/state_trackers/omx, to find a way to
> retrieve the underlying struct pipe_texture given we have an EGLDisplay and
> an EGLImage as inputs. So then we can tell the decoder to use it directly.
>
> In order to help Gurkirpal, I had another go more recently and here are 2
> solutions that seems to work but not sure if this is 100 % valid (build
> deps, safe). It builds and does not crash but some feedback would be great.
> By "it works", I just mean that I can print the pipe_texture->width0 and
> height0 and values are correct. I have not tried to use the pipe_texture,
> this will be Gurkirpal's job :) and because I am not sure this is the right
> way. Note that the 2 following functions return the same pointer.
>
>
> #include "dri_screen.h"
> #include "egl_dri2.h"
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v1(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
> _EGLDisplay *disp = egldisplay;
> struct dri2_egl_display *dri2_egl_dpy = disp->DriverData;
> __DRIscreen *_dri_screen = dri2_egl_dpy->dri_screen;
> struct dri_screen *st_dri_screen = dri_screen(_dri_screen);
> __DRIimage *_dri_image = st_dri_screen->lookup_egl_image(st_dri_screen,
> eglimage);
>
> return _dri_image->texture;
> }
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v2(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
> _EGLImage *img = eglimage;
> struct dri2_egl_image *dri2_egl_img = (struct dri2_egl_image*)img;
> __DRIimage *_dri_image = dri2_egl_img->dri_image;
>
> return _dri_image->texture;
> }
>
> And in the Makefile.am it is required to have:
>
> AM_CFLAGS = \
> + -I$(top_srcdir)/include \
> + -I$(top_srcdir)/src/mapi \
> + -I$(top_srcdir)/src/mesa \
> + -I$(top_builddir)/src/mesa/drivers/dri/common \
> + -I$(top_srcdir)/src/mesa/drivers/dri/common \
> + -I$(top_srcdir)/src/egl/drivers/dri2 \
> + -I$(top_srcdir)/src/egl/main \
> + -I$(top_srcdir)/src/gbm/main \
> + -I$(top_srcdir)/src/loader \
> + -I$(top_srcdir)/src/gbm/backends/dri \
> + -I$(top_srcdir)/src/gallium/state_trackers/dri \
> $(GALLIUM_CFLAGS) \
> + $(LIBDRM_CFLAGS) \
> $(VISIBILITY_CFLAGS) \
> $(VL_CFLAGS) \
> $(XCB_DRI3_CFLAGS) \
>
> So I wonder if this is the right approach or this should be hook up in
> vl_screen or pipe_context somehow.
> It looks to me the v1 is safer because it calls lookup_egl_image which
> seems to go all the way down and internally calls _eglCheckResource so it
> does some validity check on the input pointers.
> The v2 looks simpler but it does not even use the egldisplay pointer.
> Also I wonder if there is a way to avoid using dri2_egl_display/dri2_egl_
> image.
>
> Thx
> Julien
>
>
> On 8 July 2017 at 22:38, Gurkirpal Singh <gurkirpal...@gmail.com> wrote:
>
>> Hi,
>>
>> As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
>> support in gallium/st/omx.
>>
>> I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in
>> the H.264 decoder component. I'm looking some sort of method to get mesa
>> pipe screen pointer (or some other pipe structure) from the egl_display and
>> from which I can get struct pipe_surface and eglimage pointer/id.
>>
>> [1] https://summerofcode.withgoogle.com/projects/#4737166321123328
>> [2] https://github.com/gpalsingh/mesa/blob/gsoc-dev/src/
>> gallium/state_trackers/omx_tizonia/h264dprc.c#L205
>>
>> Thanks,
>> Gurkirpal
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>
>
> _______________________________________________
> mesa-dev mailing
> listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
