Page 1 of 10 123 ... LastLast
Results 1 to 10 of 96

Thread: Radeon UVD Support Going Through Code Review

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

    Default 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. #2
    Join Date
    Oct 2007
    Posts
    284

    Default

    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

  3. #3
    Join Date
    Jan 2007
    Posts
    459

    Default

    "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 at 10:24 AM.

  4. #4
    Join Date
    Apr 2011
    Posts
    405

    Default

    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).

  5. #5
    Join Date
    Oct 2008
    Location
    Germany
    Posts
    74

    Default

    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.

  6. #6
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    918

    Default

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

  7. #7
    Join Date
    Jul 2008
    Posts
    26

    Default

    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.

  8. #8
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote 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 at 03:38 PM.

  9. #9
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    659

    Default

    Quote 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 at 05:08 PM.

  10. #10
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote 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.

Posting Permissions

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