Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: AMD Is Working On A New VA-API State Tracker For Gallium3D

  1. #1
    Join Date
    Jan 2007
    Posts
    15,646

    Default AMD Is Working On A New VA-API State Tracker For Gallium3D

    Phoronix: AMD Is Working On A New VA-API State Tracker For Gallium3D

    Years ago there was a VA-API state tracker within Gallium3D for offering drivers support for the Video Acceleration API. That implementation, however, was dropped back in 2012 as it was largely unmaintained and the VDPAU state tracker proved to be more popular. Now, however, it seems AMD is working to introduce a new VA-API implementation for Gallium3D...

    http://www.phoronix.com/vr.php?view=MTc5OTE

  2. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,938

    Default

    Maybe its because VDPAU only does decode? Currently Radeon does VDPAU for decode, and OpenMAX for encode. VA-API supports encode. Maybe they want to transition to VA-API so they dont have to use two separate API's?

  3. #3
    Join Date
    Dec 2012
    Posts
    586

    Default

    Openmax does decode as well, they could implement that fully, but they probably know that nobody is targeting openmax for decode - at the least, there is no gstreamer openmax the way there is gstreamer vaapi (there is, but it is less developed and stable, for example on Arch the vaapi plugins are in the main repos and omx is stuck in the AUR).

    In the end, vdpau is Nvidia, vaapi is Intel, and if they were to all stop being babies they would all use Openmax, or at least standardize on one of the others. At least we have vaapi for vdpau and vice versa libraries. But it is perfectly understandable for the situation to be frustrating to AMD, who have no obvious answer.
    Last edited by zanny; 09-29-2014 at 12:42 AM.

  4. #4
    Join Date
    Jul 2011
    Posts
    76

    Default

    I support Ericg 's viewpoint, that's probably the main reason. OpenMax isn't widely used AFAIK, and Intel already uses VAAPI (for both video decode and encode) which is used and supported by some widely used software like XBMC, GStreamer, VLC etc.

  5. #5
    Join Date
    Feb 2008
    Posts
    1,359

    Default

    Main reason for me is: things became so stable and so boring, so it is perfect time to broke something again

    Because unified driver maybe, hmm.... OK wait, we will see what is planed in about ten days

  6. #6
    Join Date
    Jan 2009
    Posts
    1,496

    Default

    Quote Originally Posted by sandy8925 View Post
    I support Ericg 's viewpoint, that's probably the main reason. OpenMax isn't widely used AFAIK, and Intel already uses VAAPI (for both video decode and encode) which is used and supported by some widely used software like XBMC, GStreamer, VLC etc.
    My understanding is that openmax sees the majority of its use in the embedded space. However, I'd imagine that most software is using native solutions nowadays (corevideo, stagefright, etc).
    I agree with ericg that supporting vaapi makes more sense than supporting two different state trackers. Vaapi is pretty complicated (though less than openmax, from a quick perusal of the interfaces), but it provides a nice, robust platform for all your accelerated media needs, and is already widely adopted.

  7. #7
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,485

    Default

    Quote Originally Posted by zanny View Post
    In the end, vdpau is Nvidia, vaapi is Intel, and if they were to all stop being babies they would all use Openmax, or at least standardize on one of the others. At least we have vaapi for vdpau and vice versa libraries. But it is perfectly understandable for the situation to be frustrating to AMD, who have no obvious answer.
    vdpau was created by nvidia but the open source radeon drivers support it too, though I don't know what Catalyst uses. Based on my experience with the open source drivers, it works fine.

    I don't know enough on the subject to know what the pros and cons are between the 3 major APIs, but I get the impression vdpau is more widely accepted.

  8. #8
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    As long as the API's aren't prone to changes, I don't see what's the problem with all of them being supported as G3D state trackers

  9. #9
    Join Date
    Sep 2010
    Posts
    7

    Default

    There's also that VA-API supports Wayland, while VDPAU does not.

    Sure, OpenMAX can work on Wayland too, but as noted before... pretty much nobody uses OpenMAX for decode if they have other options.

  10. #10
    Join Date
    Feb 2011
    Posts
    163

    Default

    Quote Originally Posted by eternaleye View Post
    There's also that VA-API supports Wayland, while VDPAU does not.

    Sure, OpenMAX can work on Wayland too, but as noted before... pretty much nobody uses OpenMAX for decode if they have other options.
    I don't really have much fear as Christian König is involved. What he has done to VDPAU can happen again with VAAPI.

    When I look at the transfer functions, it even seems we can now have the surfaces back without RGB conversion. Let's see if VPP gets also implemented. I will remove the "Intel only" VAAPI patch from xbmc now, so that new adapters will have the chance to get the implemented API stable.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •