Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • #51
    I believe the current plan is to add video decode calls to Gallium3D itself, allowing the driver to either use dedicated decode hardware or shaders as appropriate.

    Not sure, but I *think* this work has already started.

    Comment


    • #52
      Originally posted by bridgman View Post
      Yes, I actually updated the technical details on that page a couple of times, although my updates were reverted because they didn't match gossip on other forums. Yay.

      As always, can't comment on unreleased features.
      -Laugh-

      Comment


      • #53
        Originally posted by smitty3268 View Post
        VAAPI isn't necessarily a bad choice here - in fact it means we now have 1 api that covers all major hardware since there is also a VDPAU backend for it.
        Last thing I've read, va api only support vdpau partly.

        Comment


        • #54
          Originally posted by Zhick View Post
          So how well does this work together with compiz/kwin desktop-effects?
          And what about tearing, with and without compositing?
          It does, though only tested in Ubuntu. Concerning the tearing, since that version only has OpenGL, you have to enable always vsync in e.g. amdcccle. There is another means to get tear-free rendering without OpenGL but this is not available in public builds.

          Comment


          • #55
            Originally posted by tmpdir View Post
            Last thing I've read, va api only support vdpau partly.
            You will have to be more specific than that. You don't provide any information here...

            Comment


            • #56
              @tmpdir

              That's correct. Lets say that vdpau-video is the best backend for vaapi but there are still some drawbacks:

              a) you can press D to deinterlace with -vo vdpau but not with -vo vaapi
              b) h264 l5.1 usually fails

              xvba-video has got some extra drawbacks:

              a) No OSD/subtitle support at all.
              b) mpeg2 is not fully supported, which is really bad as you still have to use only for that content type direct gl outout - on nvidia you can use vaapi for at least 3 content types, in theory with the dx10.1 cards even 4.

              Code:
              $ vainfo
              libva: libva version 0.31.0-sds3
              libva: va_getDriverName() returns 0
              libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
              libva: va_openDriver() returns 0
              vainfo: VA API version: 0.31
              vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA API - 0.5.1
              vainfo: Supported profile and entrypoints
                    VAProfileMPEG2Simple            : VAEntrypointIDCT
                    VAProfileMPEG2Main              : VAEntrypointIDCT
                    VAProfileH264High               : VAEntrypointVLD
                    VAProfileVC1Advanced            : VAEntrypointVLD
              I would suggest to implement VLD for MPEG2 in software and use whatever ATI provides as hw part. A similar thing NV did for VC1 and older chips.

              c) Bad clips can even crash the system - something i absolutely like
              d) Some h264 content has got the wrong colors.
              Last edited by Kano; 03 November 2009, 04:30 PM.

              Comment


              • #57
                Originally posted by Kano View Post
                b) h264 l5.1 usually fails
                Try to play with the extra "dm" option. e.g. -vo vaapi:dm=0 or 1 (whatever works) as a workaround. Something probably regressed.

                xvba-video has got some extra drawbacks:

                a) No OSD/subtitle support at all.
                Well, not in a version you can use yet. ;-)

                b) mpeg2 is not fully supported, which is really bad as you still have to use only for that content type direct gl outout - on nvidia you can use vaapi for at least 3 content types, in theory with the dx10.1 cards even 4.
                It's not an XvBA limitation but a limitation of the underlying HW. The API won't magically implement something if the underlying HW doesn't support it.

                Comment


                • #58
                  As xvba-video is a wrapper it could contain software to implement missing parts.

                  Comment


                  • #59
                    Originally posted by bridgman View Post
                    R600 doesn't have UVD. It was a pretty big chip already and it had enough shader power and bandwidth to do a fair amount of decode acceleration on the shaders.
                    Then I'm confused... according to this: http://www.amd.com/us/products/deskt...00-series.aspx
                    HD3xxx series *does* have UVD. RHD-2xxx even.

                    Or is it just fake-UVD ala shaders (aka the gallium3d plan)?
                    If it is just fake-UVD, then why the distinction between R3100 (780V chipset) and RHD3200 (780G chipset)? 3100 just not strong enough? Or is it a question of being disabled in the drivers?

                    Comment


                    • #60
                      Originally posted by Kano View Post
                      As xvba-video is a wrapper it could contain software to implement missing parts.
                      You will be duplicating code or producing inefficient code. The better thing is to support IDCT level acceleration. That's all, but not something I want to do now. That would be fine if you only had to maintain a single driver, not if you had several drivers that would need the same treatment.

                      Comment

                      Working...
                      X