AMD Ports Open-Source Linux Driver To Windows Embedded

[bridgman]

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.

[Thatguy]

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.

[russofris]

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.

[DaemonFC]

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.

[bridgman]

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.

I'm not really looking to debate this, There's really nothing to debate.

[Qaridarium]

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.

[DaemonFC]

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.

[russofris]

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