Announcement

Collapse
No announcement yet.

Radeon UVD Support Going Through Code Review

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

  • Radeon UVD Support Going Through Code Review

    Phoronix: Radeon UVD Support Going Through Code Review

    If you have been desiring better video playback support on the open-source ATI/AMD Radeon Linux graphics stack, the days of being frustrated may be limited. There's some code concerning UVD -- the GPU's Unified Video Decoder engine -- that will be going through internal code review at AMD this coming week...

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

  • #2
    That's good to hear!

    Now i do wonder if it would be possible to use UVD without the catalyst driver.
    Next thing that should happen once the UVD code is released is to get a vaapi backend for UVD. That way xbmc, vlc en parhaps also mplayer all work out of the box with it

    Comment


    • #3
      "There's some code concerning UVD"
      ZZzzzz hmm, you make a lot of ass u mptions there michael, wake me up when there's finally some real working uvd ffmpeg patches to look at then ffplay and all the downstream app's xbmc, vlc, mplayer and the rest will all use it out the box on the next compile if its actually any good.
      Last edited by popper; 03-10-2012, 10:24 AM.

      Comment


      • #4
        Well, this isn't news.

        Some of AMD's employees on these forums have been saying that their only concern is people breaking their Digital Restrictions Management on Windows and ripping blu rays. (As-if that's not already happening).

        Comment


        • #5
          ROFL! Well guys what do you think I'm doing all day long?

          By the way: the goal of the code review is to find bugs, not get that stuff released to the public. I just wanted to explain why it will take a while longer to actually fix the outstanding bugs in the VDPAU state tracker.

          Writing the UVD driver is actually only the first step to figuring out how we EVENTUALLY can release any information about how the engine is programmed....

          Christian.

          Comment


          • #6
            Christian, who cares about bugs in something which will probably never get released?
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Hello Cristian,

              Wel anyway this is good news, sooner or later we will have hw acc on ati cards with vdpau and uvd.

              Take care and be well, we need you. Chers.

              Comment


              • #8
                Originally posted by Deathsimple View Post
                ROFL! Well guys what do you think I'm doing all day long?

                By the way: the goal of the code review is to find bugs, not get that stuff released to the public. I just wanted to explain why it will take a while longer to actually fix the outstanding bugs in the VDPAU state tracker.

                Writing the UVD driver is actually only the first step to figuring out how we EVENTUALLY can release any information about how the engine is programmed....

                Christian.
                You could just write the low-level UVD decoding bits in assembler (or write them in C and compile them down to assembler to release them)... that's basically not conceding anything, because we can already use an ELF disassembler on Catalyst to obtain the same level of information.

                Wouldn't be open source, probably wouldn't be accepted by mesa mainline, but it would let people use the (otherwise-open) drivers for one more thing that we've been whining about for, well, forever.

                Then again, to me it's totally useless, because the only movies I actually want hardware decoding for are stereoscopic 3d (Blu-Ray 3d), and that isn't coming to Linux in my lifetime, if ever. Plus my CPU is high-end enough that I don't see any benefit to using hardware decoding to get the same thing and maybe save a few watts of electricity.

                I'm more interested in real-time hardware encoding of video, because this would allow you to play a game while recording a compressed H.264 (or other format) video of it at the same time, given a sufficiently powerful GPU (I think the HD7970 could do it, if the software existed for it). Without hardware encoding, you have to capture the video to an uncompressed format on disk, because dumping huge amounts of uncompressed data to disk is actually faster than trying to encode the data using a compression codec in real-time on the CPU. Especially if you have a good filesystem with delayed writes that will let a few large chunks pile up in RAM before optimizing the write sequences and flushing to media.
                Last edited by allquixotic; 03-10-2012, 03:38 PM.

                Comment


                • #9
                  Originally posted by allquixotic View Post
                  I'm more interested in real-time hardware encoding of video,
                  The New Radeon Generation (HD7XXX) has for this an special ASIC (VCE, 1080p with 60FPS ). But this is an sad Story even on Windows because there are no public APIs to use them.
                  Last edited by Nille; 03-10-2012, 05:08 PM.

                  Comment


                  • #10
                    Originally posted by Nille View Post
                    The New Radeon Generation (HD7XXX) has for this an special ASIC (VCE, 1080p with 60FPS ). But this is an sad Story even on Windows because there are no public APIs to use them.
                    Yeah, because ATI/AMD can make great hardware, but then they can't be arsed to write software that actually uses it until 2 weeks before you're ready to upgrade to the next generation. It's sad, really, the unacceptable level of driver support.

                    Comment


                    • #11
                      There needs to be better modularization of the driver components so as to make it easier to isolate encumbered 3rd party code to make it easier to remove such code from the driver codebase if it is to be ever released to the public. Even obfuscating the external proprietary function names as well should also be enough to pass legal muster.

                      Comment


                      • #12
                        omg, too much Dopamine in my brain now.

                        Well, the thing is: Yes, BluRay Ripping and stuff is done. Of course it is done. Sly stuff is done. Yes. Because otherwise these things are sometimes unwatcheable.
                        So one could use that as an argument to say: c'mon just release specs and docs. (I would be happy if they did for sure.)
                        But then the content mafia could blame AMD which is a far better target than SlySoft which is located (officially) on some island somewhere between the deepest asian jungles and pacific ocean in a country that likely gives a shit about copyrights and stuff. AMD would be internationally open for attacks. AMD has enough troubles and doesn't need the MPAA or something on their ass. So I understand that they're careful with releasing this kind of code. Still, I would really embrace a real UVD/+/2/3/... functionality.

                        Comment


                        • #13
                          in the end they release "Nothing" business as usual they also burn the open-source driver dev teams money in trying to implement a UVD solution.

                          in my point of view they just dream about a closed source DRM plugin for the open source driver so they can sell the open-source driver within android stapled pcs because the catalyst is shit.

                          google already dream about a copy-protection drm system in the official HTML5 standard to force all open-source people into a closed source world.

                          Comment


                          • #14
                            While implementing xvba support for xbmc, we came to the following list about what is still missing:
                            http://ati.cchtml.com/show_bug.cgi?id=448

                            For long term xvid/mpeg-4 support would also be great, but - there is not so many features we miss in order to have a really good looking product for the htpc market.
                            Last edited by fritsch; 03-11-2012, 08:04 AM. Reason: typo

                            Comment


                            • #15
                              Well... the only interest of UVD is the W saved for battery based systems.

                              We should not forget the hardware programing manual of the discret dma engines too, except if it's decided to remove them and use "shaders with the bus aperture" for good.

                              But right now... we need GCN support in open source drivers: I want to buy an eyefinity DCE5 and GCN chip based board with enough mini-displayport connectors to fool around (HDMI is sh** since it's royalty based)... and to play some native GNU/Linux 3D games... like oil rush (and run the unigine benchmark ).

                              I read somewhere that the DCE5 displayport support was vastely improved? Magic atombios command table for displayport link training? Displayport audio? ;-)

                              Comment

                              Working...
                              X