Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • Originally posted by gururise View Post
    Perhaps I was unclear. I meant if we could use VDPAU apps on FGLRX. IE.. If we could run vdpau applications on our Radeon cards, it would instantly open up a whole slew of hw assisted decode video applications such as Mplayer, ffmpeg, xbmc, mythtv, and vlc media player... all of which support VDPAU and none of which support VA-API (at least in their mainline). So I am suggesting that perhaps VDPAU support for Radeon would have been better than VAAPI.
    People must maintain a clear separation between the driver API and the player API.

    They can be the same API - the so-called fast path.

    They can, however, be wrapped up in another API. And that is where Gwenole's wrappers become important.

    Gwenole's work indicates that the player that he is working on will have a VA-API render path. The player itself won't support VDPAU or XVBA. You can criss-cross to almost any API you want to. NV is extending the VDPAU player interface to allow alternate driver backends. VA-API seems to already have it.

    In the end, the winning (read:Most Popular) player API will primarily be driven by a mixture of ease of implementation, stability, richness, driver support. The driver support may come direct from the vendor - or from something like Gwenole's wrapper.

    Regards,

    Matthew

    Comment


    • Originally posted by droidhacker View Post
      @bridgman:

      Q's: What is the feasibility of doing a 100% (or near to) software-on-GPU (i.e. openCL) based video acceleration? How strong of a GPU might this need (I know, subject to implementation, etc.) for BD-level video streams? And assuming that we end up getting some kind of openCL via G3D that works for older GPUs, is it possible that something like this could work for some older (i.e. R6xx - UVD-1) chips -- which currently aren't supported either for openCL or for XvBA?
      Doing acceleration over Gallium3D (rather than acceleration -> OpenCL -> Gallium3D) still seems the most likely path. Acceleration of the most CPU-intensive tasks (motion compensation, deblocking etc.) is a good fit with Gallium3D and should take enough load off the CPU that even a moderately powerful system can handle the remaining work with a single core.

      I have been recommending that people go with one model up from the lowest cost GPUs to make sure there is some shader power available for the decode work, ie an HD2600 rather than HD2400 or HD36xx rather than HD34xx. The HD43xx and 45xx are midway between 34xx and 36xx in terms of shader power so are probably OK.

      All of these are estimates until we see more code running and have a better understanding of where the bottlenecks are likely to be -- ROP (CB/DB) throughput, memory bandwidth, texturing capacity or shader power. It may be possible to do less work (maybe just motion comp) on slower GPUs to keep everything working smoothly.
      Last edited by bridgman; 16 November 2009, 06:18 PM.
      Test signature

      Comment


      • VLC is adding VA-API support with the next major release that is v1.1 (probably in time for Ubuntu 10.04 LTS). They don't support VDPAU. That is all I need, as I am a VLC user on every platform.

        Comment


        • Why would they do that? VDPAU is a better API and the de-facto standard.

          Comment


          • Originally posted by md1032 View Post
            Why would they do that? VDPAU is a better API and the de-facto standard.
            A guess? They probably just want to support 1 API, and this will let them target the XVBA/VDPAU backends along with Intel chips all at once. Besides, once VLC includes it I would think that would become the de-facto standard. VDPAU has been out for a while, but only as experimental support. It's only just now starting to be accepted into the mainline codebases of different projects, and definitely not so far along that it wouldn't make sense to take a look at it's competition and evaluate what makes the most sense for each project to work on.

            Comment


            • IMO, AMD is again giving us the inferior solution. VDPAU is more advanced. I didn't expect any better from them though, to say the least. They seem to have accepted that NVidia offers superior solutions and now AMD just seeks to be the inferior choice as if that's what they want.

              Comment


              • Originally posted by RealNC View Post
                IMO, AMD is again giving us the inferior solution. VDPAU is more advanced. I didn't expect any better from them though, to say the least. They seem to have accepted that NVidia offers superior solutions and now AMD just seeks to be the inferior choice as if that's what they want.
                I'm starting to think you just plain enjoy trolling.

                Comment


                • No, I enjoy bashing AMD's choices with fglrx which do not give their users what they really want but instead let them feel like they own inferior cards. "You want feature X? Ah too bad, you're on ATI, sorry. Feature Y? Too bad too, you're on ATI." I'm tired of this crap.

                  But maybe *you* think that fglrx is actually superior to the nvidia drivers and the support they offer (and get offered.) However, I don't.
                  Last edited by RealNC; 17 November 2009, 06:42 AM.

                  Comment


                  • fglrx targets a workstation crowd (always has). Their xvba targets embedded systems. Linux support fglrx to the home user has been ramped up, but xvba is still mainly aimed at embedded systems - they're releasing stuff for the home user, but it's not the emphasis for it.
                    What the "users" (linux community) jumped up & down about was open source drivers. AMD delivered (more than they originally said too). fglrx drivers have improved drastically, and continue to do so for the average home user (and you can't deny that one) - the updates are incremental, not huge, with the benefit being more frequent updates.

                    Comment


                    • The updates are not only incremental, but also slow as molasses.

                      Comment

                      Working...
                      X