[Beignet] [PATCH v3 0/2] Integration with libva

[Lu, Guanqun]

Hi Zhigang,

This idea is considered at the beginning of this integration when we're trying to come up with the APIs. This sounds good at first, but it has several drawback:

a) There are so many formats of libva surfaces. If only surface id is used during the interpolation, there would be duplicate codes in our libcl side which interprets the format. And I think it's easier and better to be done in libva side.

b) Another reason is cl buffer and libva surface is not a one-one relation. Take NV12 surface format as an example, we have to create 2 cl buffers (cl images actually, one for Y plane, and one for UV plane). Taken this into consideration, there's no way our API would mimic the gl-cl interpolation APIs. We could return two cl_buffers, but that only complicates the API even more, I'm afraid.

It's not a perfect solution to this integration that we use a dri bo name to pass things around. But that makes the minimal changes and give full controls for applications using this API.

--guanqun

> -----Original Message-----
> From: Zhigang Gong [mailto:zhigang.gong at linux.intel.com]
> Sent: Thursday, October 17, 2013 5:58 PM
> To: Lu, Guanqun
> Cc: beignet at lists.freedesktop.org
> Subject: Re: [Beignet] [PATCH v3 0/2] Integration with libva
> 
> I just took a look at the new API and get one question in mind.
> 
> I prefer the following style to share cl buffer/image with other library such as
> GL/libva.
> 
> cl buffer/cl api   <---->    gl texture/ libva surface
>    |                                   |
>    |                                   |
> cl driver layer    <---->    dri driver/ libva driver layer
> 
> At the CL API layer, we will only accept higher layer abstract data type such as
> gl texture or libva surface. We will not touch the driver layer data directly at
> that level.
> 
> Then only at the CL driver layer, we will call driver specific API, or maybe egl
> extension or libva extension to query hardware specific information such as the
> buffer name, the image layout which are required to create correct cl buffer or
> image.
> 
> IMO, this way, we can make our interface more platform portable. And make
> this CL extension comply with other CL extension better.
> 
> And I believe, if we follow this guide, the libva buffer sharing spec will be very
> similar to the GL buffer sharing. Maybe pass in a libva related context is
> necessary, considering there are more than one libva application. Just my
> guessing.
> 
> Any thoughts?
> 
> On Thu, Oct 17, 2013 at 01:10:53PM +0800, Lu Guanqun wrote:
> > This patchset implements the opencl side of APIs needed by this integration.
> >
> > v3:
> >     1) sent the wrong patch which still has the slice_pitch argument, fixed
> in
> >        this patch.
> >
> > v2:
> >
> >     1) change the API's name, the new API follow our naming convention.
> >     2) make it discoverable by extensions.
> >     3) remove the slice_pitch argument, as we're only using 2D image.
> >
> > ---
> >
> > Lu Guanqun (2):
> >       add clCreateBufferFromLibvaIntel() api
> >       add clCreateImageFromLibvaIntel() api
> >
> >
> >  include/CL/cl_intel.h    |   32 ++++++++++++++++++
> >  src/cl_api.c             |   44 +++++++++++++++++++++++++
> >  src/cl_command_queue.c   |    2 +
> >  src/cl_driver.h          |    7 ++++
> >  src/cl_driver_defs.c     |    2 +
> >  src/cl_mem.c             |   81
> ++++++++++++++++++++++++++++++++++++++++++++++
> >  src/cl_mem.h             |   13 +++++++
> >  src/intel/intel_driver.c |   37 +++++++++++++++++++--
> >  src/intel/intel_gpgpu.c  |   10 +++---
> >  9 files changed, 219 insertions(+), 9 deletions(-)
> >
> > --
> > guanqun
> > _______________________________________________
> > Beignet mailing list
> > Beignet at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/beignet