Page 2 of 10 FirstFirst 1234 ... LastLast
Results 11 to 20 of 96

Thread: Radeon UVD Support Going Through Code Review

  1. #11
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    941

    Default

    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.

  2. #12
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    732

    Default

    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.

  3. #13
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    in the end they release "Nothing" business as usual they also burn the open-source driver dev teams money in trying to implement a UVD solution.

    in my point of view they just dream about a closed source DRM plugin for the open source driver so they can sell the open-source driver within android stapled pcs because the catalyst is shit.

    google already dream about a copy-protection drm system in the official HTML5 standard to force all open-source people into a closed source world.

  4. #14
    Join Date
    Feb 2011
    Posts
    124

    Default

    While implementing xvba support for xbmc, we came to the following list about what is still missing:
    http://ati.cchtml.com/show_bug.cgi?id=448

    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; 03-11-2012 at 08:04 AM. Reason: typo

  5. #15
    Join Date
    Dec 2008
    Posts
    166

    Cool

    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? ;-)

  6. #16
    Join Date
    Dec 2007
    Posts
    2,272

    Default

    Quote 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.

  7. #17
    Join Date
    Dec 2008
    Posts
    166

    Exclamation

    Quote 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!

  8. #18
    Join Date
    Oct 2008
    Posts
    104

    Default

    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?

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,280

    Default

    Quote 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.

  10. #20
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    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.
    this point of view is complete Wong

    the only purpose is to disadvantage other operating systems like Linux because they know that its incompatible with the open-source mentality.

    All other purposes are just Lies and FUD !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •