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

                    Working...
                    X