3D Optimizations and UVD... AMD_hal.so!

[bridgman]

However what I DONT agree with is that Linux MUST except a closed source DRM implementation. That is bullshit.I hate to be so blunt but it's true. If that is what we need then Blueray can go suck on an apple whole.. Besides I totally disagree witrh you. Not only can we live successfully without DRM, we can still develop the means to play back restricted content without interference from you.

You might be surprised to find that I agree with you. I'm just saying that the technology isn't really there to make an open source, license-compliant DRM implementation, so in the short term living without a closed-source DRM implementation means living without a legal-in-all-markets BD solution, which in turn means less OEM preloads and probably slower market share growth as a result. Going that route would be a perfectly reasonable decision.

Not sure what you mean by "interference from us" though. The worst we will do is hold back information which puts us at risk, and the riskiest of the information is around the DRM paths (which is a problem for UVD).

Whether the generic DRM mechanisms get cracked or not is irrelevent; we just don't want it to be OUR FAULT

We also need to make sure that we don't release information (or raise the starting point for reverse-engineering which results in someone else releasing information) which would allow our DRM implementation to be cracked but not our competitors. That is the biggest risk associated with supporting open source development, and is what makes supporting open source expensive and risky rather than the "cheap, easy and good for you" exercise everyone on the outside assumes.

The point is that DRM will be cracked. With oyu, or without you. How can you use ATi as an excuse to hinder development of open source blueray playback when you know full well that it is inevitable. If ATi never even existed open source blueray playback would still have been inevitable. It's going to happen.

Same "I don't understand" as above; how are we hindering development other than by holding back the highest-risk information ?

[Kano]

I guess DRM in Linux context was a bad name as DRM in other context is something completely different Aren't you interested how Intel wants to implement VDPAU? I guess that's something ATI/AMD could do too. If ATI wants to use something else, then why did not invent it BEFORE the others. Before VDPAU was introduced it seemed everybody (especially ATI+Intel) waited for the rest to do something like changeing ABI for XvMC. Intel introduced VA-API, but as the supported hardware is really hard to get and the driver seems to suck badly so there is only one working implementation for accellerated H.264 left. Without users/testers it is very unlikely that a new ABI will be successful. So jump on the train and develop something compatible.

[bridgman]

Yeah, the Good DRM / Evil DRM thing is the bane of my existence

I didn't get the impression that Intel had decided on VDPAU, just that it was on the list of APIs they were looking at. I haven't had a chance to watch the video of Eric's talk all the way through yet, but people who attended his talk said that there didn't seem to be any kind of decision yet.

The other issue is that VDPAU seems to have been designed for direct-rendering only, not server-side implementation, and AFAIK the current DRI/DRM implementations don't actually handle multiple clients very well today (whereas implementing in the X server would bypass that problem). VAAPI seems to have been designed for server-side implementation while VDPAU was not -- I suspect that's the main reason we don't have that decision yet.

[Kano]

I guess some wider range of support would not hurt. Also those ABIs seem to be relatively similar as you could see from that VDPAU->VA-API wrapping lib - I would have expected it the other way around because there is not only mplayer but even xine with vdpau support. Maybe somebody will do this too

[duby229]

You might be surprised to find that I agree with you. I'm just saying that the technology isn't really there to make an open source, license-compliant DRM implementation, so in the short term living without a closed-source DRM implementation means living without a legal-in-all-markets BD solution, which in turn means less OEM preloads and probably slower market share growth as a result. Going that route would be a perfectly reasonable decision.

Not sure what you mean by "interference from us" though. The worst we will do is hold back information which puts us at risk, and the riskiest of the information is around the DRM paths (which is a problem for UVD).

Whether DRM gets cracked or not is irrelevent; we just don't want it to be OUR FAULT



Same "I don't understand" as above; how are we hindering development ?

I can see why your confused, so I'll just quote what you said instead...

2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet.

Of course this isnt the whole thing, its just the part that I have issues with. The only thing that I mean is that whether ATi was contributing to the Linux Market or not DRM would still be cracked eventually. The only thing ATi needs to do is: Dont release documentaiton that puts you at risk. You dont need a closed source DRM stack to do that. The final open source projects that facilitate open source playback of restricted content may not be in there final development just yet. But I assure you that competent people are working on the basic principles that these later open source projects will rely on.. The fundemental principles behind HDCP and AACS are already well understood. Blueray movies are already being hacked. You can already download full quality Blueray titles illegally right now. Most blueray titles are already available for download. For video playback all we need right now is a realtime decrypter. Your not being blamed for the work that is ongoing right now, so why on earth would you assume that you would be blamed for the future open source projects that will be based on this existing work: Of which you arent being blamed for anyways????

[bridgman]

Ahh, I get it. I think my initial comment might have been a bit ambiguous.

I was not trying to say "you must accept a closed source DRM solution", just "without a legal-in-all-markets BD solution, which today implies a closed source stack, you're going to have a tough time getting OEMs to aggressively market systems with preloaded Linux -- and without OEM preloads the *visible* Linux market share is probably not going to grow as quickly as some folks would like".

Sorry about the lack of clarity there.

[amirel]

That one company has been able to dictate to the PC industry for a long time, long before DRM was a factor. That said, I don't believe that the DRM issues are driven by any company in the PC industry. The companies which create and own the content (aka "Hollywood") dictate how their IP will be protected, and any OS developer who wants to offer legal playback of that content in their major markets needs to follow the rules established by the content owners.

Sorry again, bridgman. I understand your position --- I guess, it coincides with AMD official position. What was my question actually about: does the AMD have any plans to get rid of this "one company" dictate? Simply speaking, can we expect brighter future or not?

[RealNC]

Sorry again, bridgman. I understand your position --- I guess, it coincides with AMD official position. What was my question actually about: does the AMD have any plans to get rid of this "one company" dictate? Simply speaking, can we expect brighter future or not?

I don't think AMD can play any role here. It's up to companies like CyberLink to release Linux versions of their players.

[rbmorse]

http://shop.canonical.com/product_info.php?products_id=243&osCsid=8a539e3a1931f32cf073009a56c8e4df

[RealNC]

Hey, that's great. And it seems it has been offered for quite some time. So I guess the argument of not being able to legally play protected content on Linux doesn't really apply anymore?