Announcement

Collapse
No announcement yet.

Fedora 28 Planning For VA-API 1.0 Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora 28 Planning For VA-API 1.0 Support

    Phoronix: Fedora 28 Planning For VA-API 1.0 Support

    The latest work by Fedora developers on feature work for Fedora 28 is shipping with VA-API 1.0 support for updated capabilities around the Video Acceleration API...

    http://www.phoronix.com/scan.php?pag...-28-VA-API-1.0

  • #2
    Hope it's a bit more mature than it was in Ubuntu 17.10 which also shipped with Wayland and VA-API as defaults. Seemed to work on several of my Intel laptops, but video playback on my AMD powered desktop (Ryzen+Fury) was not working at all without either switching back to x.org (which works but has video glitches) or using mpv with very specific settings, or using software decoding.

    https://bugs.launchpad.net/ubuntu/+s...i/+bug/1720820
    Last edited by Brisse; 01-30-2018, 07:23 AM.

    Comment


    • #3
      Originally posted by Brisse View Post
      Hope it's a bit more mature than it was in Ubuntu 17.10 which also shipped with Wayland and VA-API as defaults. Seemed to work on several of my Intel laptops, but video playback on my AMD powered desktop (Ryzen+Fury) was not working at all without either switching back to x.org (which works but has video glitches) or using mpv with very specific settings, or using software decoding.

      https://bugs.launchpad.net/ubuntu/+s...i/+bug/1720820
      I feel like that is a known issue with the Radeon (and other gpu) VAAPI support in gallium on top of EGL-based presentation layers, but I don't have a bug report or patch link handy. I believe that Arch was shipping a fixed mesa via a user package repository at one point.

      Comment


      • #4
        The problem with vaapi on anything other than Intel is EGL interop. There are two interfaces in libva to achieve it. The first one is vaAcquireBufferHandle(), it's been in libva for years now. However, it makes assumptions about how hardware works, so it only works on Intel.

        The second interface is vaExportSurfaceHandle(). This one is more flexible and so allows EGL interop also on AMD. But there's a problem, it's only available in libva-git. Also, the code to use it in mesa is deactivated with an #if 0.

        The situation with the second interface is due to Intel's absolutely brilliant release management. It looked like the interface will make libva-2.0 and so be part of VAAPI 1.0 (why the API version and the library version are different is also something only the brilliant minds at Intel know), but then Intel went "oh hey, we had a feature freeze weeks ago but forgot to tell anyone, oops". See here for all the details: https://github.com/intel/libva/pull/125. If Intel had been more flexible there, AMD users could already enjoy vaapi/egl interop.

        So, because of Intel, if you want egl interop on AMD, you're in for some patching. First you need libva-git, but you need to bump the API version to 1.1.0, here's the patch for that:
        Code:
        diff --git a/configure.ac b/configure.ac
        index ad53d0a..0f0a52d 100644
        --- a/configure.ac
        +++ b/configure.ac
        @@ -27,7 +27,7 @@
         # - reset micro version to zero when minor version is incremented
         # - reset minor version to zero when major version is incremented
         m4_define([va_api_major_version], [1])
        -m4_define([va_api_minor_version], [0])
        +m4_define([va_api_minor_version], [1])
         m4_define([va_api_micro_version], [0])
        
         m4_define([va_api_version],
        Then you need mesa-git, compiled with this patch:
        Code:
        diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c
        index 78e1f19ab7..c4abe77cf7 100644
        --- a/src/gallium/state_trackers/va/context.c
        +++ b/src/gallium/state_trackers/va/context.c
        @@ -89,7 +89,13 @@ static struct VADriverVTable vtable =
            &vlVaQuerySurfaceAttributes,
            &vlVaAcquireBufferHandle,
            &vlVaReleaseBufferHandle,
        -#if 0
        +#if VA_CHECK_VERSION(1, 1, 0)
        +   NULL, /* vaCreateMFContext */
        +   NULL, /* vaMFAddContext */
        +   NULL, /* vaMFReleaseContext */
        +   NULL, /* vaMFSubmit */
        +   NULL, /* vaCreateBuffer2 */
        +   NULL, /* vaQueryProcessingRate */
            &vlVaExportSurfaceHandle,
         #endif
         };
        diff --git a/src/gallium/state_trackers/va/surface.c b/src/gallium/state_trackers/va/surface.c
        index 636505b720..f9412ce52e 100644
        --- a/src/gallium/state_trackers/va/surface.c
        +++ b/src/gallium/state_trackers/va/surface.c
        @@ -923,7 +923,7 @@ vlVaQueryVideoProcPipelineCaps(VADriverContextP ctx, VAContextID context,
            return VA_STATUS_SUCCESS;
         }
         
        -#if 0
        +#if VA_CHECK_VERSION(1, 1, 0)
         VAStatus
         vlVaExportSurfaceHandle(VADriverContextP ctx,
                                 VASurfaceID surface_id,
        Once you have that, compile ffmpeg-git with --enable-vaapi and finally compile mpv-git. I'm not aware of any player other than mpv that supports this new interface. To use it, do --hwdec=vaapi --vo=gpu --gpu-context=x11egl. That's for X, obviously. For Wayland it's --gpu-context=wayland. And directly at the console without either X or Wayland, --gpu-context=drm
        Last edited by Gusar; 01-30-2018, 11:26 AM.

        Comment


        • #5
          They broke Civilization V for me

          Comment


          • #6
            Originally posted by Azpegath View Post
            They broke Civilization V for me
            Please be more specific.

            Comment

            Working...
            X