Announcement

Collapse
No announcement yet.

VDPAU vs. XvMC?

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

  • VDPAU vs. XvMC?

    I'm curious which direction the OSS drivers will be going regarding video acceleration. From the Radeon feature list it would appear XvMC would be implemented, but from the latest Phoronix news (VDPAU via Gallium3D) and a post on lists.freedesktop.org from mostawesomedude it would appear VDPAU would be the preferred API.



    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite



    I don't feel like digging through emails and writing point-by-point
    replies, so I'm just going to do point-by-point talking-to-myself.

    - The APIs for accelerating full decoding and not just colorspace
    conversion and scaling (Xv) are:
    -- VA-API
    -- VDPAU
    -- XvBA
    -- XvMC

    Of those, only VDPAU is worth implementing. XvMC can be done in terms of
    VDPAU if you're creative enough.

    - OpenCL would be fine for video, but stupid and slow, just like
    OpenGL-based video decoding.

    - The current plan is to *not* add any more video decoding to any DDX,
    but to do it in Gallium using a state tracker. Expand g3dvl to be a true
    pipeline, let drivers fill in the pipeline with whatever they can
    accelerate, and then expose VDPAU and XvMC to userspace. Of course, only
    radeon (me, MrCooper) and nouveau (marcheu, ymanton) have actually
    agreed that this is a good idea, but the intel devs will probably keep
    maintaining their XvMC and VA-API implementation either way.

    - It's not done because we've been working on other things. If it makes
    you feel better, 3D support *is* required for this kind of work, since
    we don't have documentation on the dedicated video decoders onboard most
    GPUs, and we haven't reverse-engineered them, so we'll have to use 3D
    shaders instead.

  • #2
    That's the latest news as far as I know.

    The bottom line is that anything above mpeg-2 mc on XvMC is kind of a hack.

    The Intel driver guys have created VAAPI, but it hasn't shown much adoption.

    NVIDIA has created VDPAU, which is supposed to work quite well, and NVIDIA is really pushing for wide adoption of the API.

    ATI has something called XvBA, but they're not willing to say anything about it yet.

    Open-source drivers haven't had much in the way of video-decode accel implemented (except for Intel), because devs have been busy getting 3D and gallium stuff working.

    Comment


    • #3
      Originally posted by TechMage89 View Post
      Open-source drivers haven't had much in the way of video-decode accel implemented (except for Intel), because devs have been busy getting 3D and gallium stuff working.
      This is a good thing, IMHO. The radeon driver didn't even have the occlusion query support before today. Modern CPUs use so little percent of their power to decode video anyway, so I hope video hardware acceleration does not become a high priority before we get more basic things like OpenGL 2.0 (at minimum).

      Don't get me wrong, hardware x264 decoding would be cool, but there are more important things I would rather have. My box has no trouble at all running a HD adult movie on both of my monitors at the same time, but a few of kwin's more fancy effects simply do not work at this point (most do, however) and I hope that gets higher priority.

      Comment


      • #4
        Modern CPUs use so little percent of their power to decode video anyway
        Full HD stuff can still clog up a full core of a really powerful processor.

        Multi-threading helps there, but it's still not a small percentage of processor power being used.

        It's a shame to have dedicated hardware that can decode the stuff faster, with 100x less power and CPU load, and not being able to use it.

        But yeah, I also find power saving and reasonable 3D to be far more important at this point.

        Comment


        • #5
          Oh I think 3D and power management are more important as well. I was curious whether XvMC or VDPAU was the API to be implemented. It would seem to be a waste of time implementing XvMC.

          This is a good thing, IMHO. The radeon driver didn't even have the occlusion query support before today. Modern CPUs use so little percent of their power to decode vidteo anyway, so I hope video hardware acceleration does not become a high priority before we get more basic things like OpenGL 2.0 (at minimum).

          Don't get me wrong, hardware x264 decoding would be cool, but there are more important things I would rather have. My box has no trouble at all running a HD adult movie on both of my monitors at the same time, but a few of kwin's more fancy effects simply do not work at this point (most do, however) and I hope that gets higher priority.
          Erm... not everyone is using their video card for desktop effects. I have a quad core (Q6600) box running MythTV as my DVR (Firewire capture --> Myth --> 1080p LCD panel). I'm using a RV620 video card and there are issues rendering HD video to a 1080p panel using proprietary AMD driver. RV620 should be sufficient for clean HD rendering. I will probably give the OSS drivers a try sometime within the next week.

          Comment


          • #6
            Originally posted by pingufunkybeat View Post
            Full HD stuff can still clog up a full core of a really powerful processor.

            Multi-threading helps there, but it's still not a small percentage of processor power being used.

            It's a shame to have dedicated hardware that can decode the stuff faster, with 100x less power and CPU load, and not being able to use it.

            But yeah, I also find power saving and reasonable 3D to be far more important at this point.
            Agreed up to the last point. I don't care about 3D at all, but I watch videos pretty often on my laptop, and it's annoying that the CPU heats up and makes the fan spinup louder due to the load. Power saving would be good too, but it still strikes me that more computer users watch videos than play games. And ultimately it's about efficiency; if I can offload a bunch of processing to the GPU that keeps the CPU free to be 100% responsive to do other things. How can you possibly not want that?

            Comment


            • #7
              Just to clear this up: Of course I want it.

              It's just that it's not as big a deal on my quad-core desktop computer as it would be on a laptop.

              So for me, powersaving and 3D are more important. I'm not much of a gamer, but I can watch HD videos right now, and I can't use all of the 3D capability of my card.

              Comment


              • #8
                This is one of those cases where desired priorities don't make much difference -- the development sequence is based on architectural hierarchy :

                - dynamic power management will be built on top of kernel modesetting, and decode acceleration will be built on top of Gallium3D drivers.

                - Gallium3D drivers, in turn, depend on DRI2 and can leverage most of the code (and nearly all of the painful lessons) from the 3D work done on the classic Mesa 3D drivers

                - DRI2 depends on memory management, and the memory management work was driven primarily by kernel modesetting

                Completion of new functionality pretty much *has* to follow that dependency tree, no matter what order the work is started. Resistance is futile.

                I updated the chart at the end of the RadeonFeature page to make this a bit more clear :

                http://www.x.org/wiki/RadeonFeature
                Last edited by bridgman; 29 October 2009, 06:24 PM.
                Test signature

                Comment


                • #9
                  and then we have that pesky LONG Standing lack of 'UVD ASIC Video decoder' documentation delivery problem OC bridgeman...

                  that lack of delivery solution would, and still does as always sit above all the others in the architectural hierarchy.

                  just thought id pop that in, looking at todays date ,review time questions and all that soon

                  incase others are wondering what thats all about, your average AMD/ATI chip today, and for a very long time now, has had that fully working and powered UVD ASIC hardware decoding chip intigrated onboard (its the eq of , but we are told better than the Nvidia ASIC HW VDPAU Decoder).

                  but you cant use it, as noone in the OSS development fields across the world knows how to program this 'UVD' or make and so submit patches for its use in FFmpeg/x264 Decoding/Encoding etc, Yet... if ever.
                  Last edited by popper; 29 October 2009, 09:03 PM.

                  Comment


                  • #10
                    Powerplay 'mostly'?

                    Does.. . does that mean I can try the free driver without being killed by the fan on my 3870?

                    Comment

                    Working...
                    X