Announcement

Collapse
No announcement yet.

UVD/hw acceleration If, when?

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

  • UVD/hw acceleration If, when?

    Hi,

    I moved from FGLRX to the open source stack... and honestly, I guess I'm never going back. Colour-correct XV without flickering, smooth composite for KWin and KMS...

    As I don't do any gaming, I really have no need for OpenGL > 2.0. I'm more insterested in hardware acceleration of h.264 and VC1 video. I've already tried out the FGLRX solution (9.10 and 9.12 hotfix) on my Radeon HD 3450 (which, odly enough, reports UVD2) and it worked fine. I liked being able to play _some_ 1080p videos smoothly.. However, the implementation is far from complete, most clips have blocky video, most have incorrect colours and most of all: the bloody flickering of FGLRX's mplayer GL output kills the whole experience.

    So, will UVD support in the open-source stack ever happen? I've heard that there is some legal stuff to sort out: i.e. whether or not releasing specs for UVD will but AMD's DRM tech at risk.

    I'd like to ask the following questions to the AMD staff which roam this forum:
    1. What is the status of the legal review? Has it already started?
    2. If the legal review clears UVD docs to release, what technical requirements will need to be implemented first before UVD is implemented in the driver with a VA-API/VD-PAU/XVBA/whatever-api interface? How much work will that be, in other word: how long would it take for someone skillfull to implement these specs (any guesswork would do )?
    3. If the legal review doesn't clear UVD (which would be a terrible shame), are there any plans of implementing h.264/VC1 acceleration through shaders? What would be the technical requirements (I guess working radeon galium backend) and how much work would that be?

  • #2
    Hi,

    UVD for the 3xxx is unlikely due to the DRM issue. AMD makes an effort to decouple DRM from UVD, but that cannot be done on finished architectures, it's something for their new developments. Remember that GPU architectures take a few years from planning to release.

    But UVD only decodes parts of the video, a lot is decoded using shaders. Shader docs are available. Video acceleration for 3xxx could have been done for months or years, but nobody stepped up to do it, and ATI themselves won't do it (yet?) because they have different priorities.

    Gallium3D could be the answer, a generic state tracker for video decoding would be usable by all G3D drivers, not just ATI, so it's much more likely for someone to step up and do it (and IIRC some work has already been done).
    Noone really knows (or tells) when G3D will be ready for end-users though or when a r500 g3d driver will be available.
    It's the best bet for GPU accelerated video, but without an ETA.


    For now, there are multithreading-patches for some video software. If you're running a dual-core, try those. From what I've heard, many 1080p videos will run smoothly on a halfway decent dual-core CPU.

    Comment


    • #3
      Dual core is a must.
      ffmpeg-mt is sortof-ok-ish, but it still a bit lacking.
      CoreAVC, which is a windoze software decoder, works fine. There are patches for mplayer to use coreavc, and there is a wrapper for running coreavc on linux.

      Comment


      • #4
        Originally posted by droidhacker View Post
        Dual core is a must.
        ffmpeg-mt is sortof-ok-ish, but it still a bit lacking.
        CoreAVC, which is a windoze software decoder, works fine. There are patches for mplayer to use coreavc, and there is a wrapper for running coreavc on linux.
        Yea, I know. I'm already running mplayer with the mt patches.
        The thing is: I've got a hw-acceleration capable graphics card. I should be doing this in hardware, not software. With the HTML5 push, HD content will be even more widespread.

        Comment


        • #5
          I'm not suggesting otherwise.
          Just adding on a little to what was said by rohcQaH.

          As far as hardware accelerated video decode, its coming one day to open source, just not today. It is also not yet clear what form this video decode acceleration will take... be it through the UVD stuff, or just straight on the shaders (i.e. generic decode acceleration using gallium3d).

          There are a few key issues that need to be worked through before we can have the decode acceleration for Radeon parts;
          1) For UVD, we would need some kind of usable specifications for the UVD components in order to actually make use of it.
          2) For gallium3d, we would first obviously require a gallium3d driver applicable for the hardware we are using.

          We don't have ANY of this yet, so decode accel is still a ways out. Until we actually have this, we really have no alternative but to make do with software decoding.

          As for your other questions regarding state of legal review, sorry, but you will definitely need to get someone like bridgman to answer those. I definitely don't have that information, and honestly, I don't expect that even he will be able to give you any kind of concrete numbers.

          Comment


          • #6
            Originally posted by rohcQaH View Post
            But UVD only decodes parts of the video, a lot is decoded using shaders.
            From what I understood, decoding is all UVD. However, it's possible post-processing is done with shaders, not sure about that. What's been said is that shaders can do some parts of the decode well, others probably not so well. Nothing beats dedicated hardware though.

            Comment


            • #7
              Originally posted by Kjella View Post
              Nothing beats dedicated hardware though.
              ..except beating a dead horse.

              Comment


              • #8
                The first part of the playback stack is dedicated hardware, the rest is done on shaders. It's probably correct to say that all the *decode* acceleration is done on dedicated hardware and all of the *render* (aka presentation) acceleration is done on shaders.

                IP review for UVD has not started yet. There are some licensing issues we need to figure out as well.
                Last edited by bridgman; 01-27-2010, 04:15 PM.

                Comment


                • #9
                  Originally posted by bridgman View Post
                  IP review for UVD has not started yet. There are some licensing issues we need to figure out as well.
                  at least it's queued up so it'll appear somewhere in the future

                  that would be amazing ! opensource driver with decent functionality, speed including "native" UVD / video hardware acceleration

                  Comment


                  • #10
                    "Quote:
                    Originally Posted by bridgman
                    IP review for UVD has not started yet. There are some licensing issues we need to figure out as well."


                    Originally posted by kernelOfTruth View Post
                    at least it's queued up so it'll appear somewhere in the future

                    that would be amazing ! opensource driver with decent functionality, speed including "native" UVD / video hardware acceleration
                    now kernelOfTruth, be fair it's ONLY BEEN 387 DAYS since the UVD IP review was mentioned Right here on the board, you cant expect a Generic Industry standard AMD/ATI UVD Hardware ASIC IP Review to be Authorised, signed off, and started, let alone done and dusted so quickly; Next you will be asking other unreasonable questions like were are the closed source linux beta UVD HW Decode drivers and/or were are the pass this to play/use with the supplyed beta UVD ffmpeg/x264 patchs comment or two on the dev blog URLs, dont be silly you know the ATI executive want you to want and perhaps even Spend yet More of your hard earned cash to get a Nvidia HW assisted HD video decoder asic with full AVC HD decoder capabilitys from their CHEAP boards, and full docs available for it TODAY anyway... and stop being so bothersome to the AMD Executives up there in their tower

                    http://www.phoronix.com/scan.php?pag...u_mobile&num=1
                    "....We have benchmarked VDPAU and found it to perform very well in that under Linux it's possible to play HD videos with a $20 CPU and $30 GPU thanks to this video acceleration method. VDPAU is the best video acceleration / decoding API on Linux and is widely adopted by various multimedia applications, which is all in contrast to AMD's XvBA and their troubled implementation....."
                    Last edited by popper; 01-27-2010, 11:32 PM.

                    Comment


                    • #11
                      Originally posted by popper View Post
                      now kernelOfTruth, be fair it's ONLY BEEN 387 DAYS since the UVD IP review was mentioned Right here on the board, you cant expect a Generic Industry standard AMD/ATI UVD Hardware ASIC IP Review to be Authorised, signed off, and started, let alone done and dusted so quickly;
                      I think it's been more than 387 days, hasn't it ? I thought the discussion came up relatively early in the project. I said we would tack UVD onto the *end* of the current plan, not that we would bump other existing commitments to make room for it.

                      Originally posted by popper View Post
                      Next you will be asking other unreasonable questions like were are the closed source linux beta UVD HW Decode drivers and/or were are the pass this to play/use with the supplyed beta UVD ffmpeg/x264 patchs comment or two on the dev blog URLs
                      The beta drivers went out to the beta users, and the same functionality has been in the released drivers for a few months now. Not sure if it has moved from development to "official feature" yet, but checking.

                      IIRC the "mention" of patches was that we would probably *not* be making them available.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        I think it's been more than 387 days, hasn't it ? I thought the discussion came up relatively early in the project. I said we would tack UVD onto the *end* of the current plan, not that we would bump other existing commitments to make room for it.
                        And what's the current plan? I presume Evergreen is the priority right now, followed by? Old-mesa 3d or Gallium 3d? I'm just curious whether or not hw/acceleration, with the "A OK" from the IP review, can somehow bubbleup to the top of the list in the next, I don't know, 18 months?

                        I know that I'm pulling your tongue a bit here Don't get me wrong, I'm grateful for the AMD approach to the open source stack (open specs etc), and I have to say the open source drivers rock, especially when you take into consideration the timespan they reached they're current state. I'm just curious

                        IIRC the "mention" of patches was that we would probably *not* be making them available.
                        What patches, could you elaborate a bit? Are you talking about patches for XvBA support in mplayer/vlc/xine, whatever, or UVD patches for the open source drivers?

                        Comment


                        • #13
                          The list is getting pretty short - Evergreen, resolving some power management problems the devs are running into, HDMI audio for newer GPUs... there's probably something else I won't remember until the second cup of coffee kicks in. I've already started looking at UVD in terms of putting together a plan, and that's where the licensing issues came up -- specifically whether the license which allows us to ship the hardware and software for a decoder as a set will cover enabling third party software to use our hardware. I think it will be OK but it's one more thing we need to investigate.

                          Comment


                          • #14
                            (&^%$#&^%$*&%@!! only one minute to edit, stinkin' spammers)

                            Remember that our commitment is to investigate, not to provide an A-OK. The answer might be "NO".

                            The patches were internal development changes to exercise XvBA on a few different players. The patches have to stay internal unless/until we have a decision on releasing a public API.

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              I've already started looking at UVD in terms of putting together a plan, and that's where the licensing issues came up -- specifically whether the license which allows us to ship the hardware and software for a decoder as a set will cover enabling third party software to use our hardware. I think it will be OK but it's one more thing we need to investigate.
                              Originally posted by bridgman View Post
                              Remember that our commitment is to investigate, not to provide an A-OK. The answer might be "NO".
                              The patches were internal development changes to exercise XvBA on a few different players. The patches have to stay internal unless/until we have a decision on releasing a public API.
                              Ok, so this is a licensing issue: you're not sure whether or not you can provide an API which will allow, third-party players (e.g. mplayer or xine), which are potentially not under the license, to use the hardware and software you've got that's under the license. Am I right?

                              So, I understand this impacts the FGLRX driver... with it you control the HW specs and would only provide a XvBA API... and the issue here is exactly what you stated: you don't know whether or not the publix XvBA API/binding would violate the licensing.

                              Where does the open-source effort kick in?
                              The easiest way to do that would be for AMD to release HW specs for open source coders to implement. I recall someone, somewhere mentioning that you're not sure whether that is possible without compromising HDCP, because the DRM stuff is tied up to the acceleration stuff. Is that right?
                              If that were true, would it mean that there would never be an open-source UVD code? Or could the open-source UVD code be implemented by someone under NDA, with some voodoo "put this here, and read from register there"?

                              Comment

                              Working...
                              X