Announcement

Collapse
No announcement yet.

Digging Deeper Into AMD's UVD Code Drop

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

  • #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)
    All opinions are my own not those of my employer if you know who they are.

    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.
      Test signature

      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?
        All opinions are my own not those of my employer if you know who they are.

        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; 03 April 2013, 07:41 PM.
          Test signature

          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; 03 April 2013, 07:47 PM.

            Comment


            • #16
              Anyone knows which cards are supported exactly? Do the UVD2 cards (i think 4250 and upwards have UVD2) benefit from this?

              Comment


              • #17
                Should be rv7xx and up. Don't remember if SI is included though. The code doesn't work on rs880 HD 42xx) yet AFAIK... see Christian's post :

                Last edited by bridgman; 03 April 2013, 08:08 PM.
                Test signature

                Comment


                • #18
                  Originally posted by bridgman View Post
                  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.
                  2 last questions Bridgman, one general and 1 personally specific.

                  1) Why VDPAU? I'm not complaining mind you, it'll be nice to have access to all the other VDPAU-enabled software out there. But does this signal AMD giving up on XvBA or....?

                  2) I've got a 4000 series AMD card in my laptop using radeon, whenever i watch flash videos the temperature sky rockets and the fans drown out the audio. Assuming youtube videos are done in h.264 like I think they are, will this UVD work help to reign in the CPU / GPU usage and stop creating a fire hazard in my bedroom? =P
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    re: VDPAU, I think that was what the existing open source decode acceleration code used so we stayed with it.

                    re: flash, not sure. My recollection was that flash was moving away from decode acceleration support on Linux but I haven't really looked at it. Are you talking about an older version of flash maybe ?
                    Test signature

                    Comment


                    • #20
                      Is there any chance of integrating this somehow in the Catalyst driver? VDPAU is supported by most video players already while native xvba works only in FernetMenta's Xbmc branch AFAIK.

                      PS Better let Flash be without acceleration. They are uncapable of delivering anything that works fully.
                      I had a nvidia 8200 (VDPAU B) and i had tons of issues because of it - blue people on youtube, transparent black areas that wouldnt go away even after the browser was closed, playback speed isues (non-fullscren). Only a handful of videos were working ok-ish. I had to disable hardware support altogether to get rid of it (and i got tearing videos...).

                      Comment

                      Working...
                      X