Announcement

Collapse
No announcement yet.

Digging Deeper Into AMD's UVD Code Drop

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

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

    Comment


    • #3
      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?

      Comment


      • #4
        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

        Comment


        • #5
          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.

          Comment


          • #6
            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

            Comment


            • #7
              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?

              Comment


              • #8
                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, 06:44 PM.

                Comment


                • #9
                  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?

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Originally posted by bridgman View Post
                      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.
                      Okay so everything that can be open sourced IS open sourced. Is the performance of the UVD controlled more by the microcode or by the driver? Meaning: will Catalyst and Radeon have equal decoding / encoding performance for the simple fact they both use the same microcode and the driver is just saying "Hey! Decode this!" and throwing video at UVD. Or does the driver actually have a hand in the decoding / encoding and its performance?

                      (Asking as much for myself as others, figured this would be a good way to hit up questions others might have)

                      Comment


                      • #12
                        Good question. The UVD microcode is the same as Linux Catalyst uses and decode performance should be identical, although I expect system-level performance should be better with radeon because the memory manager is more capable. IIRC the driver passes slices to the UVD hardware and gets back decoded images in NV12 format.

                        All that said, there will probably be issues found as the code gets more widely used and some of those issues could be performance related, but the informal testing done so far suggests that the decode acceleration works pretty well.

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          Good question. The UVD microcode is identical and decode performance should be identical, although I expect system-level performance should be better with radeon because the memory manager is more capable. IIRC the driver passes slices to the UVD hardware and gets back decoded images in NV12 format.

                          All that said, there will probably be issues found as the code gets more widely used and some of those issues could be performance related, but the informal testing done so far suggests that the decode acceleration works pretty well.
                          Okay, whats the possibility of adding more decode / encode targets? Release announcement specified the MPEG formats, h.264 and something else (forget what).

                          Does the microcode decide what can be decoded / encoded, with very specific hardware functions that can only do MPEG, h.264 and whatever the last one was? Or does the driver decide what can be decoded / encoded and UVD is basically just a separate, dedicated, processor to not block the 3D engine and use up shaders?

                          Comment


                          • #14
                            It's really the hardware that determines which formats can be decoded. If there's a tiny change to a video standard then occasionally a microcode update can support it by taking advantage of unused logic in the decode hardware blocks, but that's about it.

                            You can't add VP8 support to existing UVD hardware, for example.

                            The main benefit of a dedicated decode acceleration block is offloading the entropy decode step, which is both complex and inherently serial (so not a great fit for shaders). The remaining offload steps (IDCT, filtering etc..) are nice-to-have because it can be done with lower power consumption on dedicated hardware than on CPU or shader core but it's the entropy decode where you get the real benefits of fixed-function hardware.
                            Last edited by bridgman; 04-03-2013, 07:41 PM.

                            Comment


                            • #15
                              Wah, just wish one had direct access to such entropy de(and maybe en)coding units. Could be useful for some other stuff too.

                              They will be hardwired I guess? Would be funky if it was possible to mess with the context model. OK, enough dreaming...
                              Last edited by log0; 04-03-2013, 07:47 PM.

                              Comment

                              Working...
                              X