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:[email protected]] Sent: Friday, October 18, 2013 8:49 AM To: Zhigang Gong Cc: [email protected] 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:[email protected]] > Sent: Thursday, October 17, 2013 5:58 PM > To: Lu, Guanqun > Cc: [email protected] > 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 > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/beignet _______________________________________________ Beignet mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/beignet
