Announcement

Collapse
No announcement yet.

H.265/HEVC Main 10 Decode Support Added To Radeon UVD Code

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

  • #11
    So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.

    Comment


    • #12
      Originally posted by bug77 View Post
      So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.

      amdgpu is the kernel driver, delivering hardware support all the other components build onto. radeonsi is for 3D (OpenGL).

      radeonsi is not to be confused with radeon. radeon is the 'predecessor' of amdgpu
      Last edited by juno; 09 March 2016, 07:49 AM.

      Comment


      • #13
        Originally posted by hajj_3 View Post
        of course, intel skylake supports 8bit vp9 hardware decoding, i think nvidia does too. Kaby lake will support 10bit h265 and 10bit vp9. Expect pascal and polaris to support 10bit for both of these too.
        Unfortunately, it looks like Polaris will not get any VP9 support, even 8bit. Do you have any source that says otherwise?

        Comment


        • #14
          Originally posted by bug77 View Post
          So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.
          You need to layer it out.
          There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

          kernel : radeon, amdgpu

          Mesa : r200, r300g, r600g, radeonsi

          DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)

          All info taken from here : http://xorg.freedesktop.org/wiki/RadeonFeature/
          The separation is pretty clear IMO.

          S.
          Last edited by Serafean; 09 March 2016, 08:16 AM. Reason: mention modesetting

          Comment


          • #15
            Originally posted by juno View Post


            amdgpu is the kernel driver, delivering hardware support all the other components build onto. radeonsi is for 3D (OpenGL).

            radeonsi is not to be confused with radeon. radeon is the 'predecessor' of amdgpu
            Hence the unambiguous naming
            But thanks for the explanation.

            Comment


            • #16
              Originally posted by Serafean View Post

              You need to layer it out.
              There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

              kernel : radeon, amdgpu

              Mesa : r200, r300g, r600g, radeonsi

              DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)

              All info taken from here : http://xorg.freedesktop.org/wiki/RadeonFeature/
              The separation is pretty clear IMO.

              S.
              Imo it's not that clear when you have "radeon" and "amdgpu" listed both at kernel and at DDX level.

              Comment


              • #17
                Originally posted by bug77 View Post
                Imo it's not that clear when you have "radeon" and "amdgpu" listed both at kernel and at DDX level.
                ... and Mesa, at least for radeon

                Tweaking Serafean's list a bit... AFAIK the "radeon" classic Mesa driver is still in use for R100/RV200/RN50 and related parts.

                There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

                kernel : radeon, amdgpu

                Mesa : radeon, r200, r300g, r600g, radeonsi

                DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)
                https://cgit.freedesktop.org/mesa/me...ers/dri/radeon

                There is also the "AMDGPU" back end for LLVM, but let's not go there

                It's simple if you add a qualifier, so eg you're talking about the radeon kernel driver or the radeon Mesa driver or the radeon X driver.

                I greyed out "glamor" since it is an acceleration method like EXA (with a support library so it can be used with multiple X drivers), not an X driver in its own right.
                Last edited by bridgman; 09 March 2016, 09:08 AM.

                Comment


                • #18
                  Originally posted by bridgman View Post

                  ... and Mesa, at least for radeon

                  Tweaking Serafean's list a bit... AFAIK the "radeon" classic Mesa driver is still in use for R100/RV200/RN50 and related parts.



                  https://cgit.freedesktop.org/mesa/me...ers/dri/radeon

                  There is also the "AMDGPU" back end for LLVM, but let's not go there

                  It's simple if you add a qualifier, so eg you're talking about the radeon kernel driver or the radeon Mesa driver or the radeon X driver.

                  I greyed out "glamor" since it is an acceleration method like EXA (with a support library so it can be used with multiple X drivers), not an X driver in its own right.
                  If a driver is not isolated at a specific layer, but at the same time it's not a driver that encompasses all layer, it still looks like Frankenstein's work to me. There's logic in there, no doubt about that, but it's the kind of logic that confuses whoever doesn't have some context already.

                  Comment


                  • #19
                    @bridgman: can you tell if this is supposed to be UVD 6.1 or UVD 7?

                    Comment


                    • #20
                      Originally posted by bug77 View Post

                      If a driver is not isolated at a specific layer, but at the same time it's not a driver that encompasses all layer, it still looks like Frankenstein's work to me. There's logic in there, no doubt about that, but it's the kind of logic that confuses whoever doesn't have some context already.
                      Yeah, it's kind of like looking at a shell script with stuff being piped/redirected to somewhere else.
                      Or mixing/matching different versions of hardware blocks (UVD/TrueAudio/Display Hardware/Renderer) together.
                      Usually when one starts talking about drivers and their capabilities, one does want context...

                      S.

                      Comment

                      Working...
                      X