Announcement

Collapse
No announcement yet.

AMD Releases UVD Video Decode Support For R600 GPUs

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

  • Thanks. Just wonder, however, if wikipedia datas are correct. In this post it was implied some data may be wrong.

    Comment


    • Originally posted by oibaf View Post
      So, about R300-R500 is there some help we can provide? Which cards could support it, only RV515 or others? I have a RV530 and could do some tests.
      As far as I know the RV515 is the only R5xx card with UVD.

      Comment


      • Originally posted by chrisr View Post
        You seem to be implying that "--vo=vdpau" doesn't use field-based output, but I assure you that this mode was equally broken before the Mesa patch was applied. I was expecting "--vo=vdpau" to work properly regardless.
        The driver tells the state tracker what mode it supports (field vs. frame) and which should be used by default. The VDPAU state tracker can deal with both, but NV_vdpau_interop can't.

        My expectation was actually that it crashes or that the output is somewhat distorted, but It just looks like that the NV_vdpau_interop code does the next best thing and uses the single frame for both the top and bottom field. That's still not correct, but at least looks quite good on first glance.

        Comment


        • AFAIK the HD 2300 was the only pre-rv6xx chip with UVD, with very limited sales (the DX10 rv6xx mobile parts replaced it pretty quickly).

          Not 100% sure it was RV515 but whatever it was, there's a bad assumption floating around -- the part was basically <regular chip plus UVD>, so it got described as just <regular chip>, which might make you think that all <regular chip> had UVD which is not the case. Hopefully that made sense, need more coffee. What I'm trying to say is that X2300 and HD2300 tended to get lumped together, but only the HD2300 had UVD.
          Last edited by bridgman; 01 September 2014, 10:45 AM.
          Test signature

          Comment


          • OK, found the IDs - not 100% sure this is right but it seems reasonable :

            7210 RV550/M71 [Mobility Radeon HD 2300]
            7211 RV550/M71 [Mobility Radeon X2300 HD]

            I don't remember ever hearing the term "X2300 HD" internally, not sure if we sold any of those. Anyways, I think these two DIDs would be the only 5xx parts with UVD, and AFAIK they are pretty rare birds.

            Originally posted by Deathsimple View Post
            As far as I know the RV515 is the only R5xx card with UVD.
            I think it was RV550 not RV515. The potentially confusing part is that the gfx core in RV550 is the same as RV515/516.
            Test signature

            Comment


            • Originally posted by bridgman View Post
              OK, found the IDs - not 100% sure this is right but it seems reasonable :

              7210 RV550/M71 [Mobility Radeon HD 2300]
              7211 RV550/M71 [Mobility Radeon X2300 HD]

              I don't remember ever hearing the term "X2300 HD" internally, not sure if we sold any of those. Anyways, I think these two DIDs would be the only 5xx parts with UVD, and AFAIK they are pretty rare birds.
              Look: http://www.notebookcheck.com/ATI-Mob...00.2923.0.html

              Mobility Radeon X2300 HD (M71-M 7210)
              Mobility Radeon X2300 HD (M71-S 7211)

              Nur die HD Versionen unterst?tzen ATIs UVD Technologie (Hardware Beschleunigung von HD-DVD, Blu-Ray (VC-1, H.264, MPEG-2)

              So at least notebookcheck has same IDs.

              Comment


              • Does someone Test this now with xbmc? and if its not working, did someone test it with the va-api wrapper for vdpau?

                Comment


                • Originally posted by Nille View Post
                  Does someone Test this now with xbmc? and if its not working, did someone test it with the va-api wrapper for vdpau?

                  Xbmc wont work. Those chips dont support GL interop and are much too slow for the pixmap path. Which was removed earlier cause violating glx spec, which we were told by an AMD oss dev when we implemented OSS vdpau support together.

                  Vaapi wrapper also wont work in xbmc anymore as we blacklist everything but Intel for vaapi. Cause unmaintained, crashprone wrappers for fglrx and others.

                  Comment


                  • Thats sad, i had the hope to replace 2 windows installations with openelec.

                    About the wrappers, why don't turn it default off, if its not a Intel adapter, instead of blacklist?

                    Comment


                    • Originally posted by Nille View Post
                      Thats sad, i had the hope to replace 2 windows installations with openelec.

                      About the wrappers, why don't turn it default off, if its not a Intel adapter, instead of blacklist?
                      Yeah. For the first point we also feel sad, you can run xbmc v12 with those new drivers to see that issue concerning performance not talking about the spec violation ...

                      Concerning vaapi: i will remove the blacklist if any working wrapper appears, e.g. one that can run our helix vaapi,vpp arch without segfaulting. I could not find one,yet.

                      Comment

                      Working...
                      X