Page 1 of 13 12311 ... LastLast
Results 1 to 10 of 123

Thread: Digging Deeper Into AMD's UVD Code Drop

  1. #1
    Join Date
    Jan 2007
    Posts
    15,186

    Default Digging Deeper Into AMD's UVD Code Drop

    Phoronix: Digging Deeper Into AMD's UVD Code Drop

    Yesterday it was exclusively announced on Phoronix that AMD was releasing open-source UVD code so that their open-source Linux graphics driver can finally benefit from GPU hardware-accelerated video playback. Here's some more details...

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

  2. #2
    Join Date
    Dec 2011
    Posts
    2,124

    Default Great but

    This is really great and makes AMD more attractive to me to!

    But they need to get better at publishing changelogs, and support the latest X.Org Server releases.

    It really bothers me a lot that it takes months for AMD to get a driver to support the latest X.Org Server release, every time!

    It really bothers me that they are holding back progress by forcing distributions to ship old X.Org releases.

  3. #3
    Join Date
    Jul 2007
    Posts
    256

    Default

    Quote Originally Posted by uid313 View Post
    This is really great and makes AMD more attractive to me to!

    But they need to get better at publishing changelogs, and support the latest X.Org Server releases.

    It really bothers me a lot that it takes months for AMD to get a driver to support the latest X.Org Server release, every time!

    It really bothers me that they are holding back progress by forcing distributions to ship old X.Org releases.
    Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by r1348 View Post
    Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?
    makes them more attractive to me because I don't feel like I have to use proprietary driver now. though better pm will shift me even further

  5. #5
    Join Date
    Dec 2011
    Posts
    2,124

    Default

    Quote Originally Posted by r1348 View Post
    Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?
    Because I like having options.
    I am currently on a Nvidia card and for a long time I've used the proprietary driver, but lately I've been using the open source driver which works great for me, and it even works for the old game I play, however for newer games it doesn't work so well. So if I were to go play some new games, I can go back to the proprietary driver.

    So if I was on AMD card, I would first try go with the open source driver, but it if wasn't good, I would like the option to use the proprietary driver.

  6. #6
    Join Date
    Sep 2010
    Posts
    705

    Default

    This is good news for all FLOSS driver users. Its no-good news for all Catalyst users :| as apps now will double down on VDPAU (not as if Catalyst alternative was good, but..)

    And we may not see Catalyst adopting VDPAU

  7. #7

    Default To blob or not to blob, that is the question

    I am not afraid to admit that the totality of what has happened in the last two days is not totally 100% clear to me.

    This UVD code drop, how open is open? Yesterday's announcement made it seem as if UVD is now out in the open once and for all. But here today, Michael is talking about microblobs.

    Don't get me wrong, I think this is all great and I have nothing but love for what AMD has done, I'm just curious as to what these microblobs are for if UVD is now indeed open source material. Is that nothing more than the remaining Digital Rights Management garbage?

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,516

    Default

    Pretty much all modern hardware uses microcode to implement complex logic. Some vendors store the microcode permanently on the chip, some store most of it on-chip but include a writeable CAM for patching (eg Intel/AMD CPUs), and some store the entire microcode image in writeable RAM.

    ATI/AMD GPUs fall into the last category, where the driver has to load microcode images for blocks like the memory controller state machine, the gfx command processor that reads commands from a DMA ring buffer, a few other blocks (PFP and RLC, think I'm missing one) and now the UVD block in order for the hardware to operate correctly.

    Those microcode images are being described as "blobs" in the article, which is potentially confusing because "blob" is also used to describe precompiled binary code running on the CPU (eg a binary graphics driver).

    All of the code running on the CPU is open source.
    Last edited by bridgman; 04-03-2013 at 06:44 PM.

  9. #9
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by bridgman View Post
    Pretty much all modern hardware uses microcode to implement complex logic. Some vendors store the microcode permanently on the chip, some store most of it on-chip but include a writeable CAM for patching (eg Intel/AMD CPUs), and some store the entire microcode image in writeable RAM.

    ATI/AMD GPUs fall into the last category, where the driver has to load microcode images for blocks like the memory controller state machine, the gfx command processor that reads commands from a DMA ring buffer, a few other blocks (PFP and RLC, think I'm missing one) and now the UVD block in order for the hardware to operate correctly.

    Those microcode images are being described as "blobs" in the article, which is potentially confusing because "blob" is also used to describe precompiled binary code running on the CPU (eg a binary graphics driver).

    All of the code running on the CPU is open source.
    Hold up Bridgman, just to clarify. Is the firmware that is loaded open source or no? Michael made a comment about it "At least working with future kernels..." which made it sound like the firmware is closed source but the accessor functions that control it and direct it are open source and can therefore be patched and changed as the kernel goes.

    Was there really any way for the open source developers to code for UVD and try to get it functional without this code drop? Or was it a complete blackbox with literally zero way of figuring it out via reverse engineering and the only people who could write the code worked at AMD cuz they knew what it actually needed?

  10. #10
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,516

    Default

    Quote Originally Posted by Ericg View Post
    Hold up Bridgman, just to clarify. Is the firmware that is loaded open source or no? Michael made a comment about it "At least working with future kernels..." which made it sound like the firmware is closed source but the accessor functions that control it and direct it are open source and can therefore be patched and changed as the kernel goes.

    Was there really any way for the open source developers to code for UVD and try to get it functional without this code drop? Or was it a complete blackbox with literally zero way of figuring it out via reverse engineering and the only people who could write the code worked at AMD cuz they knew what it actually needed?
    Unfortunately Linux puts microcode in a folder called "firmware", which makes things confusing right from the start. The microcode that gets loaded into the chip is a binary image, just like the microcode that is permanently burned into devices. It's part of the hardware block design.

    All of the driver code (ie everything that runs on the CPU) is open source. This is the same model as the rest of the graphics drivers.

Posting Permissions

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