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

[Zhigang Gong]

I'm convinced that this new extension will only be called from the Libva's
intel-driver layer. Right?
Will push this patchset soon. Thanks for the contribution.

-----Original Message-----
From: Lu, Guanqun [mailto:guanqun.lu at intel.com] 
Sent: Friday, October 18, 2013 8:49 AM
To: Zhigang Gong
Cc: beignet at lists.freedesktop.org
Subject: RE: [Beignet] [PATCH v3 0/2] Integration with libva

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