Implement vaExportSurfaceHandle()

[fhvwy]

Intel driver implementation for https://github.com/01org/libva/pull/125 .

[chivakker]

This looks good to me along with the API changes. Tested it with mpv. (compiling mpv is not trivial and it requires a lot of side devel packages to run basic vaapi decoding). Also there's a linkage problem in mpv with libvpx where it won't pkg_config it at all.

Nonetheless, once it is compiling I am getting vaapi decoding with VO vaapi [NV12].a

mpv can handle if AcquireBufferHandle is not working and will default to vaapi-copy (vaDeriveImage for rendering?)

@fhvwy is mpv going to switch to libva-2.0 at some point?

[fhvwy]

@chivakker I think mpv will support both versions for a while - support for libva2 will land soon but libva1 won't be removed. (Like ffmpeg, it currently works back to libva1.2 for distribution compatibility.)

[xhaihao]

@fhvwy could please update the dependency on libdrm? I got the following error with an old version of libdrm:

i965_drv_video.c: In function 'drm_format_of_separate_plane':
i965_drv_video.c:6449:20: error: 'DRM_FORMAT_R8' undeclared (first use in this function)
return DRM_FORMAT_R8;

[xhaihao]

@uartie could you help to check whether libdrm on CI machine supports DRM_FORMAT_xxx?

[fhvwy]

@xhaihao This would be a jump to libdrm 2.4.82 to support R16 and GR1616 (for P010/I010) - that's somewhat more recent than I was expecting (only three months ago, so unlikely to be in current distributions). Is that still ok to do? The alternative is to not support some formats with old libdrm by adding #ifdefs.

[xhaihao]

I also don't think libdrm 2.4.82 is available on current distribution, e.g. the latest ubuntu 14.04 uses libdrm 2.4.67, and DRM_FORMAT_R8 is not defined in libdrm 2.4.67

Requested 'libdrm >= 2.4.82' but version of libdrm is 2.4.67

how about to remove the support for new drm formats and keep the dependency on libdrm unchanged?

[fhvwy]

For YUV that would remove all 10-bit support, and support for separate layers (i.e. EGL import) with 8-bit. RGB would all stay, but that's probably removing a bit too much for it to be useful.

As an alternative, since we know these are fixed (they are in the kernel user API), we could just take the relevant fragments from the libdrm header and define the missing formats locally with something like:

#ifndef DRM_FORMAT_RG1616
#define DRM_FORMAT_RG1616       fourcc_code('R', 'G', '3', '2')
#endif

[uartie]

@xhaihao the CI uses the distro provided libdrm-dev packages in the build containers for each OS target. For the OS's we currently cover, the following are the libdrm versions available:

Ubuntu Trusty (14.04) - libdrm-dev 2.4.67
Ubuntu Xenial (16.04) - libdrm-dev 2.4.76
Ubuntu Zesty (17.04) - libdrm-dev 2.4.76
Fedora 25 - libdrm-devel 2.4.82
Fedora 26 - libdrm-devel 2.4.82

Fedora has sufficient libdrm version... Ubuntu libdrm versions are too old.

If we increase the libdrm version requirement, then we'll need to compile/install newer libdrm (and possibly mesa, too) inside our baseline Ubuntu build containers. This would be a one-shot thing so not a big deal. However, requiring a newer libdrm version not provided by a distro package has wider audience implications beyond the CI.

I'm OK with #ifndef DRM_FORMAT_RG1616 solution if you don't forsee any issues with that.

[xhaihao]

@fhvwy @uartie I'm OK with Mark's new solution.

[fhvwy]

I've added checks for the four DRM_FORMAT values not present in libdrm 2.4.52 (and left the dependency alone).