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
<mailto: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
<https://summerofcode.withgoogle.com/projects/#4737166321123328>
[2]
https://github.com/gpalsingh/mesa/blob/gsoc-dev/src/gallium/state_trackers/omx_tizonia/h264dprc.c#L205
<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 <mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
<https://lists.freedesktop.org/mailman/listinfo/mesa-dev>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
