Revenge On Reverse Engineering

[rapsure]

r300 - r400 opengl stuff

I myself am not too concerned about hardware accelerated video decoding right now. Someday it would be nice, but my AMD X2 4200 can handle most of the video out there right now. However I would love to see enough documentation to finish up the opengl 1.3 that is currently in the driver for smoothline, and a few other miscellaneous incomplete implementations that are being covered by the low impact fall back. I would also see enough documentation to finish up to at least opengl 2.0 or 2.1 so that the latest games will work with the opensource driver. After those opengl extensions were implemented then the driver could be optimized to be the fastest open driver however it is not easy reverse engineering. It takes a lot of patience (I've tried before) a little intuition to see how the device behaves with certain commands. Many more hours tweaking trying, and so having the information would allow the driver to be completed a lot quicker than it is currently being worked on. Also reverse engineering can require a considerable amount of resources since passing a bad command can let the smoke out. Most of the time these devices are engineered so that letting the smoke out is not likely to happen, but not every case can be tested and engineers are still human.

I'd really love smoothline and a better way to get the command buffer to play nicely so that Google Earth will play more nicely with the open driver. fglrx is fast, but unstable and has a few bugs that the open driver does not have. The open driver is stable except it isn't complete.

[fhuberts]

The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.

well, if you could release information on how to setup the block for unencrypted streams you would not be in violation of anything while still allowing the open source driver the benefit of the UVD :-)

[bridgman]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.

[Kano]

Well broadcasting a vga signal is always a security flaw when the display could show "interesting" infos. But lets compare that to HDCP. Just for the sake of hardware vendors you have to use a vga card and monitor/tv with HDCP. You absolutely gain nothing over pure DVI. And the only thing you could avoid is that you could not record the signal with a hd capable recorder. As the protection of hd dvd/blueray is already broken and could be even removed on the fly with a commericial tool a standard DVI connector would be enough. So what would you buy...?

[agd5f]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

*rant*

This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

*rant off*

If that pisses you off, get this: the new wireless connectivity standard for DVD players and TVs is limited to a range of a few feet due to MPAA pressure so that your neighbors won't be able to pick up what movie you're watching:

http://www.cnn.com/2008/TECH/01/03/wirelesshigh.def.ap/index.html

[bitnick]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

*rant*

This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

*rant off*

[bridgman]

Yes, DRM like digital rights management.

Video decoding isn't the greatest fit with the kind of work stream processors can do, or at least nobody has figured out how to find sufficient parallelism in the decoding workload to take real advantage of the shader power. Having said that, there's a big difference between inefficient and impossible.

The biggest issue, I think, is that we do use the shaders pretty heavily for the rendering part of the playback pipeline so I'm not sure how much shader horespower is left on the 2400/2600 anyways.

Good question though...

[duby229]

So hold on, let me get this straight... We are talking about DRM (Digital Restrictions Management) not DRM (Direct Rendering Manager).... Is that correct?

If so why cant you just bypass the frontend altogether and just let all those stream processors handle HD decoding directly through something like CTM? Or maybe through an abstraction layer like GLSL or something similar?

[jc87]

We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it

Funny thing how DRM in the end only screws the costumer ;-)

[givemesugarr]

Why can't we have true HD acceleration of non-DRM'd content?

because releasing specs for the free hd video acceleration would let reverse engineering reveal how the drm works in a matter of no time and because usually the hd content (until now) was protected by drm, which is on its last moments of life after sony, the last drm sustainer, has declared that would abandon drm for some of its content - the news is on linux journal breaking news (http://www.linuxjournal.com/node/1006011 ) while the article to which it refers is available directly on business week: http://www.businessweek.com/technolo...013_398775.htm .
so for example if amd would reveal how udv works for the free part
on monday someone would have commit a patch to the radeon for the
drm part. at least that's what i've understood from john's explanation on the matter.