You are viewing airlied

airlied
airlied
:.:..:.

July 2014
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

airlied [userpic]
AMD annoucement of open drivers...

So the news is out that AMD have committed to opening up specifications and providing some driver code to the open source community!!!

Alex Deucher and I have been working with AMD on this for about 3 months now and it's great to see it finally go public with their plans going forward. The initial code from Novell/SuSE will be appearing around XDS time, and AMD will also be attending.

Initially it will be a 2D modesetting driver, and hopefully a 3D driver will follow later. They are not stopping work on fglrx and will not be releasing any code from fglrx.

They will also be providing us with some access to engineering staff for information on older cards that we hadn't access to before, so we can properly support the current radeon driver (mainly BIOS parsing and workarounds..)

AMD, myself and Red Hat are also working through clearing me from my NDA issues so I can work on the r5xx cards.

So its all very positive and hopefully it we can all work together going forward to produce a top-notch open source driver...

If anyone has any questions on this feel free to post them here and I'll try and answer them if I can...

Comments
Re: Hooks for binary only parts?

We don't know. They might. It depends.

The obvious example is copy protection. The MPAA is under this hilarious delusion that they can protect the bits all the way from the DVD to the screen. Part of that is setting up HDCP on the video cable. ATI probably can't tell us how that works, because if they did, we could just turn it off, and then OMG PIRACY. So what will likely happen there is the driver will just not do HDCP normally, and if you want to sell a fully licensed DVD player that runs linux, you'll just add that as a plugin.

You can either do this by maintaining the hooks in the open code, or by maintaining your own internal branch of the code that you only give to people who pay for it (ie, people building an appliance). Or maintain that in fglrx, I suppose. And, yeah, if the open source community decides they don't want that kind of closed hook in the open code, there's not a lot AMD can do about that, so option 1 might not be an option at all.

Again, the intention here is not to cripple the open drivers, or to require some magic closed blob to make things 30% faster. That doesn't help anyone, AMD included. They really do want to enable as much as they can in the open drivers to make their hardware look good. And, let's face it, copy protection makes their hardware - any hardware - look bad.

(Anonymous)
Re: Hooks for binary only parts?

A very thorough answer complete with an example. You even covered the case I was wondering about - might closed hooks be chipped away? From what you are saying it sounds like if someone influential did the chipping wouldn't be anything that AMD could do (assuming the hooks are there in the first place)...

Again don't reply if you can't but do you think xorg driver level hooks are less likely to be chipped away? Does a xorg driver level hook even make sense or is that a nonsense question?

Re: Hooks for binary only parts?

I suspect, at least for the case of copy protection, that it'd be much easier (and probably more performant) to implement the "HDCP-aware" bits as a direct-rendering driver, parallel to what we already have for GL and similar to how XvMC works. If you put it in the 2D driver you have to work out the network protocol to get the encrypted bits into the driver which is a lot of work for nothing. (Although, the whole discussion of copy protection is a lot of work for nothing...)

I guess to answer the question: it doesn't really matter where closed blob hooks go, the reaction will be about the same. But again, we have no indication they even want to do that yet.

Re: Hooks for binary only parts?

> ...and if you want to sell a fully licensed DVD player that runs linux, you'll just add that as a plugin.

You mean that will be done in user space? Or will the plugins come as kernel modules? Or is it too early to ask this?

cheers,
wjl

(Anonymous)
We don't need HDCP

The thing here is, we don't need HDCP. HDCP only works in an end-to-end encrypted chain. But as they say, "a chain is only as strong as it's weakest link." The weakest link here is the HD-DVD "protection", called AACS. It's already broken. It's already possible to decrypt the disc and once you have the decrypted data, mplayer will display it, even without HDCP.
Tools exist that decrypt movie data on-the-fly and then dump it to stdout, which you then simply pipe into mplayer. It's not as straight-forward or user-friendly as with dvds yet, but it will get there someday.


As for GPU-assisted video decoding, you don't need to deal with any DRM either. Just make sure that the GPU can receive a standards compliant VC-1 or h264 bitstream and then decode it (or parts of it), like it's done for mpeg2 with XvMC. The dvd-backup community will make sure that said bitstream will be available, through something similar to libdvdread and libdvdcss.