Announcement

Collapse
No announcement yet.

AMD Ports Open-Source Linux Driver To Windows Embedded

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

  • AMD Ports Open-Source Linux Driver To Windows Embedded

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

    Here's something interesting or perhaps odd: AMD has been porting the open-source Radeon Linux driver to Windows Embedded Compact 7 (WEC7) as its graphics driver.

    http://www.phoronix.com/vr.php?view=16520

  • russofris
    replied
    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.....

    Leave a comment:


  • DaemonFC
    replied
    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.

    Leave a comment:


  • Qaridarium
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

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

    Leave a comment:


  • DaemonFC
    replied
    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.

    Leave a comment:


  • russofris
    replied
    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, 11:46 AM.

    Leave a comment:


  • Thatguy
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • Thatguy
    replied
    Originally posted by bridgman View Post
    OK, I see the disconnect. You're asking questions based on the assumption that the shader compiler (which produces the GPU code) is responsible for most of the performance difference between proprietary and open source drivers. As far as we know that is not the case, although there are probably some specific apps where it makes more of a difference.

    Most of the performance differences are related to code all across the driver stack. The open and closed drivers have completely different internal architectures (proprietary drivers code share across multiple OSes, open source drivers code share across multiple HW vendors) so you can't just "port over the optimizations". The proprietary driver is ~100 times the size of the open source driver and needs a proportionally larger team to maintain it. Optimizations tend to be *big*, because they are all about adding specialized code for specialized scenarios and that quickly takes you to 20x or 50x the code size.

    Since the open and proprietary driver architectures are different we would be talking about essentially an all new open source driver 50 or 100x the size of the current one, requiring 50-100x the developers to maintain it. Are you asking us to invest 50-100x the resources in Linux that we do today, noting that would be far more than we would make from the Linux market even if we had 100% market share ?

    It's reasonable to ask, but I don't think any reasonable company would say "yes".
    No, I personally think investing any resources into "linux" for a graphics design is a waste of time and money. To much API/ABI breakage, to many subsystem changes just to many problems.

    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. We can likely find a way to leverage your code. Hell many open source groups would GLADLY use your windows driver if they had the first clue how to talk to it properly !! I'd settle for a binary x86 blob with a open api document to state how to communicate and support the blob.

    Point is, your making this harder then it has to be by going down the street by making 3 lefts and then 3 rights and then 3 lefts and then 3 rights. Travel in a straight line.

    Leave a comment:

Working...
X