Page 7 of 7 FirstFirst ... 567
Results 61 to 68 of 68

Thread: AMD Ports Open-Source Linux Driver To Windows Embedded

  1. #61
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,441

    Default

    Quote Originally Posted by Thatguy View Post
    I am asking AMD to open source the entire internal driver and let everyone who wants to support it do so on whatever project they are working on.Just let us in.
    Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

    Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.

  2. #62
    Join Date
    Jan 2011
    Posts
    219

    Default

    Quote Originally Posted by bridgman View Post
    Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

    Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.
    I and many other people in the OSS community likely wouldn't care how we get a 3d accelerated driver. In fact IMHO a wrapped makes a ton of sense if you have good internal API/ABI stability. I realize there is tons of drm code, I assume this is mostly for UVD ? If so OSS can implement uvd in shader language. Plenty of knowledge out there to do this.

    Can you ask your superiors about maybe working with opensource groups about wrapping the driver ? It would make more sense and from a maintenance standpoint would sure be much easier for many small OS groups to keep it working.

    Sorry for busting your balls so much. Just trying to get you guys to think about other ways the OSS community can get 3d accel.

    Send me a pm. I know a few guys dying to put 3d driver in a OSS and they aren't always opposed to writing wrappers to do so.

  3. #63
    Join Date
    Jan 2009
    Posts
    464

    Default

    Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes,
    I would argue that, if the DRM can be broken via the source release sans key, then it is not "robust". Your obligation is to protect the PK that was licensed to ATI by the MPEG-LA and or DCP LLC. It's akin to saying that Apache cannot release their mod_ssl source because it may compromise the PKs of their customers' implementations.

    I'm not really looking to debate this, There's really nothing to debate. I'm just pointing out that the entire rationale for withholding (any) source code is built on a mountain of bullcrap.

    Last note: It also hinders the development of better, "more robust" competing DRM standards. That's what the DCP LLC is really trying to prevent.
    Last edited by russofris; 10-31-2011 at 11:46 AM.

  4. #64
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote Originally Posted by bridgman View Post
    Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

    Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.
    With your AMD hat on I know you can't reply to this.

    By robust DRM, you actually mean that it fails to protect one single Blu Ray disc (as evidenced by all the Blu Ray pirate rips), and all it actually manages to do is maliciously disrupt open source software and be a pain in the ass to people who actually bought a disc that won't play.

  5. #65
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,441

    Default

    Quote Originally Posted by russofris View Post
    Your obligation is to protect the PK that was licensed to ATI by the MPEG-LA and or DCP LLC.
    Nope, not even close. Our obligation is to robustly implement specific technical measures which help others to protect the keys they were issued.

    Quote Originally Posted by russofris View Post
    I'm not really looking to debate this, There's really nothing to debate.

  6. #66
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    a shader based acceleration is better because its more flexible this means WebM support is easy by shaders.

    all the FUD around the UVD unit is just a joke its a crap technique with bullshit.

    open up the UVD crap? it makes no sense for opensource users because UVD1-3 can not handle any opensource video format.

  7. #67
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote Originally Posted by Qaridarium View Post
    a shader based acceleration is better because its more flexible this means WebM support is easy by shaders.

    all the FUD around the UVD unit is just a joke its a crap technique with bullshit.

    open up the UVD crap? it makes no sense for opensource users because UVD1-3 can not handle any opensource video format.
    You're incorrect. There are plenty of open source codecs that implement patent-encumbered media formats.

    You mean to say they only chose to support MPEG Patent Troll Authority formats when they could have used unencumbered ones instead or in addition to.

  8. #68
    Join Date
    Jan 2009
    Posts
    464

    Default

    open up the UVD crap? it makes no sense for opensource users because UVD1-3 can not handle any opensource video format.
    chicken/egg

    You're incorrect. There are plenty of open source codecs that implement patent-encumbered media formats.
    open media formats (theora, webm) != Opensource implementation of an encumbered media format.

    Our obligation is to robustly implement specific technical measures which help others to protect the keys they were issued
    Much like openssl implements specific technical measures which help others to protect the keys they were issued. Not that SSL is a utopia of unexploitable secure communications.....

Posting Permissions

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