Re: [Mesa-dev] How to write using EGLImage?

2017-08-17 Thread Emil Velikov
Hi Julien,

On 15 August 2017 at 12:39, Julien Isorce  wrote:

> Also eglExportDMABUFImageMESA is still tagged 'MESA'
> (EGL_MESA_image_dma_buf_export). Compared to EGL_EXT_image_dma_buf_import .

The extensions are completely different and the MESA (vendor) tag is
since only one vendor has seen value/implemented it.
IIRC Khronos has ways to promoting extensions to EXT or KHR but I
don't know the details.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] How to write using EGLImage?

2017-08-15 Thread Julien Isorce
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  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  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
>> 

Re: [Mesa-dev] How to write using EGLImage?

2017-07-13 Thread Christian König

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 > 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 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


Re: [Mesa-dev] How to write using EGLImage?

2017-07-13 Thread Christian König

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 > 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 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


Re: [Mesa-dev] How to write using EGLImage?

2017-07-13 Thread 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  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 list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] How to write using EGLImage?

2017-07-08 Thread Gurkirpal Singh
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