[FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search
sw at jkqxz.net
Tue Apr 2 00:57:17 EEST 2019
On 28/03/2019 05:17, Song, Ruiling wrote:
>>>> Neo is the successor to Beignet, correct?
>>> Yes, that's the truth.
>>> Currently we simply checking against the specific header file of OpenCL,
>>> which is in-fact not accurate.
>>> I am not sure whether you would like to use Neo together with
>>> intel-media-driver, which is the most targeted opencl usage in FFmpeg.
>>> If that's the case, I think it may be hard to find a matching
>>> intel-media-driver to work with Neo release package.
>>> Because Neo release version depends on a very outdated libva revision.
>>> I just sent a patch to Neo to update libva revision dependency. Once they
>>> accept the patch and new Neo release package comes out,
>>> I think we can change to check against Neo package. People would not need
>>> to build Neo themselves then.
>>>> Enabling similar functionality for Neo should allow for the same feature
>>>> support for these not using Beignet.
>> Indeed, I'd want to use Neo + intel-media-driver.
>> Judging by the (relatively low) development activity on Beignet of late,
>> its' considered ready to deprecate in place of Neo, applicable on anything
>> newer than Kabylake.
> I think Mark don't have plan to deprecate Beignet now, and me too.
> FFmpeg-OpenCL currently use direct buffer sharing between OpenCL and vaapi driver.
> One obvious limitation I didn't notice before is 10bit or 12bit buffer sharing is not supported by Neo.
> I pinged the author of cl_intel_va_api_media_sharing, but got no response.
> Maybe I will take some effort to update the extension spec and implement them in Neo myself.
> I am not sure any other Neo limitation that Mark wants to add?
For my point of view, the ideal thing to happen would be for Intel and AMD to work together to create a DRM object (kernel dma-buf) sharing extension for OpenCL which works on all of their platforms (especially the new ones, AMD ROCm and Intel NEO).
I don't think a VAAPI-specific extension is really the right way forward - as far as I can tell there is no good reason to tie it to that specific API (or, even worse, particular driver implementations thereof). Compare Vulkan, which already does all of the interop on Linux via DRM object fds (and which therefore supports clean interop with Beignet, as well as with the Mesa and Intel VAAPI drivers themselves).
More information about the ffmpeg-devel