On 12/03/18 17:40, Rostislav Pehlivanov wrote: > On 12 March 2018 at 00:23, Mark Thompson <s...@jkqxz.net> wrote: > >> On 12/03/18 00:01, Rostislav Pehlivanov wrote: >>> On 11 March 2018 at 22:41, Mark Thompson <s...@jkqxz.net> wrote: >>> >>>> The old vaAcquireBufferHandle() API works in fewer cases and provides >>>> less information than the current vaExportSurfaceHandle(), but it exists >>>> on older versions and is already used by the OpenCL code. This probably >>>> doesn't have much use directly, but it will be used to replace the >> ad-hoc >>>> OpenCL code in a following patch. >>>> --- >>>> libavutil/hwcontext_vaapi.c | 191 ++++++++++++++++++++++++++++++ >>>> +++++++++++--- >>>> 1 file changed, 179 insertions(+), 12 deletions(-) >>>> >>>> ... >>> >>> Why? libva 1.1.0 is 6 years old now. It doesn't make sense to have 2 >> pieces >>> of code to do the same thing. >> >> VAAPI 1.1.0 != libva 1.1.0. VAAPI 1.1.0 is in libva 2.1.0, released last >> month. >> >> (This is not confusing at all.) >> > > ABH seems pretty much worse than ESH, and considering you can't get the > format modifiers makes it useless for Vulkan. I don't see why we need to > support it in addition to ESH.
It's what it currently used by the Beignet/OpenCL interop (since it was the only thing which existed when that was written, and the format modifier isn't needed), and I don't want to break that. Since it was only released a few weeks ago it will probably be a while before it lands in all distributions, and it isn't implemented at all by the Intel ex-blob driver yet. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
