AMD Continues Updating Its R500 Documentation

[bridgman]

In the specific area of UVD, the impact of DRM is still a problem and I expect it to remain that way for quite a while. There's a chance we may be able to open up the current implementations but I'm still telling everyone to assume that will *not* happen for now.

For the rest of the GPU, I guess it averages out to "no problem". It's not getting any easier and (so far) I'm not seeing any hard roadblocks, in the sense that the technical complexity is going up every year but so far we're dealing with it.

I wish the new products didn't come along as quickly though

[V!NCENT]

@Bridgeman,

How severe is the impact of DRM hindering the release of documentation? And now that FLOSS is taken into considderation on the drawing board, how do you see this impact changin on the horizon? Do you think it will reach a point of being unmanageable any time soon?

I am not asking for the technical details, although I would like to know of course, but a simple bad, not bad, good or no problem will do

[bridgman]

I do so much miss the ability to edit

The blurb above explains why DRM and decode have to be tightly connected, but it's obviously not the whole story.

In principle there is no reason why the two blocks can't be designed so that the programming functions for decode and DRM are completely separated, allowing programing info for decode to be released for use in open source drivers without putting the DRM implementation in other drivers at risk. In practice, however, separating the blocks tends to incur penalties, either in terms of larger die size and product cost, or in terms of more complex programming and higher CPU utilization.

Historically the degree of programming interdependence has been "luck of the draw", since the ability to use the hardware in an open source driver was not one of the requirements fed into the front of the design process. The good news is that we are now including open source support as a consideration - the bad news is that things like decoding blocks are not redesigned very often, just tweaked, and separating the two functions requires more than just a tweak.

[bridgman]

There are two largely distinct connections :

1. In general, we need to make sure that our hardware/software does not become the easiest way (or one of the easier ways) to capture and duplicate protected content.

2. In order to sell our products into most markets we need to comply with agreements which require a certain degree of "robustness" in our decode paths to ensure that protected video content can not be intercepted while being processed in our hardware/software stack, which implies that protected video content remain protected (ie encrypted) all through the stack. This requirement is independent of (1), ie even if there are much easier ways to pirate the content (eg ripping directly off a BD disk) that does not have any impact on our obligations or on the consequences of not meeting those requirements.

That sucks, but it's the price that all hardware vendors pay in order to be able to ship "legal" BD playback solutions, which in turn are a pre-requisite for selling into most new PC markets.

[Melf]

Well, I think I dont understand how DRM and real time video deconding is related.

IMHO, when someone wants to pirate a BD for example, they just rip the video directly from the disk without any (real time) decoding taking place.

[V!NCENT]

Windows' marketshare keep declining at an ever growin pace and Apple is going to seriously harm the PC manufacturors. See dual AMD+Intel CPU Macbooks comming? 'Cus I don't.

On the long run DRM OS's and hardware will die and Linux will take over of what is going to be left of the PC market.

So whether you like it or not, AMD, if ypu want to be part of the future then you will have to seperate at some point, or move it to a shader software based solution.

But as long as you keep releasing docs it's AMD all the way for me.

[bridgman]

And, of course, you can neither comment on future products nor on DRM issues, so we won't know whether you succeeded until some UVD14-docs start appearing on amd.com, right?

Pretty much. We are starting to look into the implications of exposing more information about existing UVD implementations, but it's a very time-consuming process and I obviously don't know what the outcome will be until we finish.

[deanjo]

Unfortunately its not readily available in Denmark yet.. And I also wanted kickass 3D performance!

You will be waiting for quite a while then.

[rohcQaH]

And, of course, you can neither comment on future products nor on DRM issues, so we won't know whether you succeeded until some UVD14-docs start appearing on amd.com, right?

[bridgman]

If ATi keeps their promise and separates the DRM bits out in later hardware, then there is hope for the future, but the existing hardware will likely have to rely on shader-based solutions.

For clarity, we didn't promise to separate out DRM from decode, just to make sure the issue of useability with open source drivers *was* on the table with future designs and that we did proceed *if* the impact on cost & performance was not prohitive.

In other words we promised to *try*, no more.