Announcement

Collapse
No announcement yet.

VDPAU vs. XvMC?

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

  • #11
    Originally posted by popper View Post
    and then we have that pesky LONG Standing lack of 'UVD ASIC Video decoder' documentation delivery problem OC bridgeman..
    One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

    I have committed to investigate whether UVD can be added to the plan once we have finished the planned work. That's it.
    Last edited by bridgman; 29 October 2009, 09:43 PM.
    Test signature

    Comment


    • #12
      Thanks for the updated picture of the driver stack. Resistance is futile, indeed.

      Comment


      • #13
        Originally posted by bridgman View Post
        One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

        I have committed to investigate whether UVD can be added to the plan once we have finished the planned work. That's it.
        This indicates that the secret AMD total plan for AMD World Order is flawed.

        That the AMD apparently does NOT want me or my family to have access to the UVD programming information is a serious problem, I have the technology yet I can not use it. It is apparent that this is a problem and the AMD fails to deliver; thus, it does seem that we indeed have the Delivery Problem. Please urge your superiors to add the UVD information to the Total open source graphics Plan.

        I realize that the AMD plan is already better than the non-existant NVIDIA plan, but the Intel are making far more git commits and the AMD really should do more where they can.

        Comment


        • #14
          xiando, Bridgman explained it in the past SEVERAL TIMES why documenting UVD is hard and will probably never done.
          Before you continue your whining, why don't you read the archives first?
          (little hint: it is about not enabling people to circumvent DRM on Windows and some hefty fines).

          Why do you think it is AMD's choice?
          Last edited by energyman; 30 October 2009, 07:22 AM.

          Comment


          • #15
            Originally posted by energyman View Post
            Powerplay 'mostly'?

            Does.. . does that mean I can try the free driver without being killed by the fan on my 3870?
            Drivers should now come with a warning - caution: use of this driver may cause physical injury, or video card sprouting wings and trying to be an aeroplane.

            Comment


            • #16
              seriously, with the open drivers the fan on my card is on max. (and the system needs 60W more). The fan is loud. Really, really, really loud.

              Comment


              • #17
                What makes you think that UVD is even required for comfortable video decode?

                I have a few points to make regarding this point;
                1) If you remember back many years, you could get an "MPEG CARD" to playback MPEG videos (1 or 2? Both? I don't quite remember). This was necessary at a time when CPUs weren't powerful enough to drive SD videos, so they accelerated SD video decoding. Anyway, point is that NOBODY is interested in acceleration when dealing with SD MPEG 1/2 now since the CPU usage in decoding those is negligible -- we only accelerate the down/up scaling and similar transformation using Xv.
                2) Modern CPUs are basically *borderline* in handling modern HD videos on a single core. Older CPUs are borderline when using MULTIPLE cores. That means that the total acceleration doesn't really need to be *that much* in order to get a reliable playback.
                3) WELL DOCUMENTED GPU features can be used for partial video-decode acceleration. As bridgman has pointed out in other threads, this partial video decode acceleration is actually *MOST* of the video decode process. To me that suggests that rather than sucking up most of my older multi-core CPU running at full speed, video decoding might drop down to, for example, half of a single core at half speed, which is low enough that I don't worry about it, even on a laptop since the CPU will be in a power-saving low-frequency mode.

                Could it be better? Sure, we could make full use of UVD, BUT, it is not *so critically important* that we can't live without it.

                My opinion: GPU hardware video decode acceleration is a product of bad-DRM. Without bad-DRM, video decode acceleration would most likely be done using standard GPU features for equivalent video playback performance at slightly higher CPU usage. I.e., the proposed video-decode-over-gallium. Putting video decode into a dedicated chip makes it harder to reverse engineer since DRM-infested bad goes in to hardware, and clear video (w/HDCP) comes out the HDMI port on the other side of it. I.e., it enables the "magic black box" feature.

                Originally posted by xiando View Post
                This indicates that the secret AMD total plan for AMD World Order is flawed.

                That the AMD apparently does NOT want me or my family to have access to the UVD programming information is a serious problem, I have the technology yet I can not use it. It is apparent that this is a problem and the AMD fails to deliver; thus, it does seem that we indeed have the Delivery Problem. Please urge your superiors to add the UVD information to the Total open source graphics Plan.

                I realize that the AMD plan is already better than the non-existant NVIDIA plan, but the Intel are making far more git commits and the AMD really should do more where they can.

                Comment


                • #18
                  Video accelleration for h264/vc1 is certainly nice to have. As ATI does not provide a similar feature as Nvidia with VDPAU those cards are only 2nd choice for systems which should decode full hd. The curious thing about that is XvBA was here even before VDPAU was introduced, but only same privileged people could use it (some famous OEMs...). That's the wrong way as video accelleration has got lots of issues usually when it is introduced and without testers the quality will never be good. vdpau with bad content used crashed the Xserver too in the beginning. The drivers needed to improve over time. Even when you get accelleration via XvBA tomorrow there still would be lots of errors which are no more in VDPAU. ATI really missed the best time to introduce it - now the best they could do is implementing vdpau and forget their own lib.

                  Comment


                  • #19
                    Originally posted by Kano View Post
                    Video accelleration for h264/vc1 is certainly nice to have. As ATI does not provide a similar feature as Nvidia with VDPAU those cards are only 2nd choice for systems which should decode full hd. The curious thing about that is XvBA was here even before VDPAU was introduced, but only same privileged people could use it (some famous OEMs...). That's the wrong way as video accelleration has got lots of issues usually when it is introduced and without testers the quality will never be good. vdpau with bad content used crashed the Xserver too in the beginning. The drivers needed to improve over time. Even when you get accelleration via XvBA tomorrow there still would be lots of errors which are no more in VDPAU. ATI really missed the best time to introduce it - now the best they could do is implementing vdpau and forget their own lib.
                    Absolutely agree. I am one of the part time Linux users that was discussed in one of the previous threads on the same topic who probably don't count towards the Linux stats that ATI counts, however I can say one thing quite honestly. Had I read these threads (and I do intend to publicize this as this information is not available very easily - at least people on forums like slashdot seem to think that ATI is a better bet on Linux due to companies support for Linux), I would have bought an Nvidia card instead of an ATI one. What AMD/ATI probably doesn't realise is that lack of UVD support on Linux actually affects their share of Windows market share as well. I think as an end user, I can only vote with my wallet.

                    To be fair, an average end user doesn't care about the ideology behind open source vs. closed source as long as we can get a working driver that delivers the advertised features. So can we please get something that works and have a open source vs. closed source DRM debate on the side?
                    Last edited by arbitrabbit; 30 October 2009, 08:01 PM.

                    Comment


                    • #20
                      Personally, Open Source drivers are FAR more important than UVD.

                      AMD is doing a good thing (tm) by supporting free drivers. UVD would be nice, but there's no way in hell that I'd be buying nVidia for some cooler video playback at this time

                      To be fair, an average end user doesn't care about the ideology behind open source vs. closed source
                      The average Windows user doesn't.

                      Comment

                      Working...
                      X