Announcement

Collapse
No announcement yet.

Radeon UVD Support Going Through Code Review

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

  • #11
    There needs to be better modularization of the driver components so as to make it easier to isolate encumbered 3rd party code to make it easier to remove such code from the driver codebase if it is to be ever released to the public. Even obfuscating the external proprietary function names as well should also be enough to pass legal muster.

    Comment


    • #12
      omg, too much Dopamine in my brain now.

      Well, the thing is: Yes, BluRay Ripping and stuff is done. Of course it is done. Sly stuff is done. Yes. Because otherwise these things are sometimes unwatcheable.
      So one could use that as an argument to say: c'mon just release specs and docs. (I would be happy if they did for sure.)
      But then the content mafia could blame AMD which is a far better target than SlySoft which is located (officially) on some island somewhere between the deepest asian jungles and pacific ocean in a country that likely gives a shit about copyrights and stuff. AMD would be internationally open for attacks. AMD has enough troubles and doesn't need the MPAA or something on their ass. So I understand that they're careful with releasing this kind of code. Still, I would really embrace a real UVD/+/2/3/... functionality.
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #13
        While implementing xvba support for xbmc, we came to the following list about what is still missing:


        For long term xvid/mpeg-4 support would also be great, but - there is not so many features we miss in order to have a really good looking product for the htpc market.
        Last edited by fritsch; 11 March 2012, 08:04 AM. Reason: typo

        Comment


        • #14
          Well... the only interest of UVD is the W saved for battery based systems.

          We should not forget the hardware programing manual of the discret dma engines too, except if it's decided to remove them and use "shaders with the bus aperture" for good.

          But right now... we need GCN support in open source drivers: I want to buy an eyefinity DCE5 and GCN chip based board with enough mini-displayport connectors to fool around (HDMI is sh** since it's royalty based)... and to play some native GNU/Linux 3D games... like oil rush (and run the unigine benchmark ).

          I read somewhere that the DCE5 displayport support was vastely improved? Magic atombios command table for displayport link training? Displayport audio? ;-)

          Comment


          • #15
            Originally posted by sylware View Post
            I read somewhere that the DCE5 displayport support was vastely improved?
            All the Northern Islands chips are DCE5. See the "Radeon Display Hardware" section of this page (http://wiki.x.org/wiki/RadeonFeature) for more on DCE5 features.

            Comment


            • #16
              Originally posted by agd5f View Post
              All the Northern Islands chips are DCE5...
              oops... if I recall well, it was about the DCE of the southern islands chips. I cannot find the www page again!

              Comment


              • #17
                2 points:
                1.Releasing the UVD as a binary blob or anything obfuscated wont happen because any blob that small would be too easy to reverse engineer
                2.Its not about DRM as such, its about the fact that if AMD documents this hardware, Microsoft will revoke their "protected content can play on this hardware" approval (block the digital signatures of the drivers or whatever) because getting that approval means the hardware has to be undocumented to prevent hackers hacking it.

                Anyone know what the situation is regarding Intel cards? Do they have dedicated silicon for decoding video? Is the driver support open source on Linux? If so, what has Intel done differently that makes it possible to open-source their support?

                Comment


                • #18
                  Originally posted by jonwil View Post
                  ....because getting that approval means the hardware has to be undocumented to prevent hackers hacking it.
                  Not really... it just means that hackers shouldn't be able to hack it, ie certification requires a certain level of robustness. Depending on the hardware specifics, that might allow documentation or might not.
                  Test signature

                  Comment


                  • #19
                    The fact that you see malice behind something doesn't change what the agreements say, and doesn't make what I posted Wong.
                    Test signature

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      The fact that you see malice behind something doesn't change what the agreements say, and doesn't make what I posted Wong.
                      Digital Restrictions Malware only is, was, or ever will be malicious software meant to attack the end user and strip them of their rights.

                      It's unfortunate that hardware vendors partner with malicious companies to join in on this attack.

                      Blu Ray DRM has never been very robust. Funny things like showing the device a forged revocation list with the version number maxed out so it never accepts another real one does not make that component robust.
                      Last edited by DaemonFC; 16 March 2012, 01:19 PM.

                      Comment

                      Working...
                      X