AMD Releases Open-Source UVD Video Support

[duby229]

I didnt mean any offense of course. I was just stating the obvious. You of all people know better then just about anyone else that some people will complain no matter what. Personally I think the driver is kicking ass. I'm very happy with it. But power management was more important than the priority it was given. I'd like to think that if it was implemented earlier there would have been a lot fewer complaints. There would have been complaints about this that or the other, but I don't think it would have been equal to the volume of complaints about power management.

EDIT: And I'm not assigning blame. It isnt your fault of course. I don't think anybody could have anticipated this situation wthout prior experience. In addition the legal review process is obviously flawed and that isnt any of the developers fault either.

[bridgman]

But power management was more important than the priority it was given.

Again, what did we prioritize before this round of power management that we shouldn't have ? Your choices are basically display and 3D. Remember that we started the review efforts on PM before we started work on UVD and well over a year before starting things like DMA.

I'd like to think that if it was implemented earlier there would have been a lot fewer complaints. There would have been complaints about this that or the other, but I don't think it would have been equal to the volume of complaints about power management.

This is probably true, although our governments provide a pretty good lesson that choosing decisions which minimize complaints at each step does not usually lead to the best overall decisions. It is possible that we should have sequenced power management before doing much with 3D acceleration on 6xx and higher, although there's a *really* good chance the program would have been declared a failure and shut down if we had gone with that approach. Hard to say.

EDIT: And I'm not assigning blame. It isnt your fault of course. I don't think anybody could have anticipated this situation wthout prior experience.

It actually is my fault, in the sense that I managed the team, I set the priorities, and I didn't push our developers to improve the driver-based PM (with full knowledge that it was dead-end work). That was really the only option we didn't take, but remember that Alex had already done quite a bit of work on power management to get it to its current state.

It certainly would have been nice if we had started this round of PM hardware review in 2010 rather than 2011, but we only had two developers and part of my time so given all the other things going on I don't see how we could have done that without dropping something bigger in the process.

In addition the legal review process is obviously flawed and that isnt any of the developers fault either.

I'm not sure the legal review process is flawed (and for the bazillionth time it's primarily a technical review ) as much as it accurately reveals the current state of things... AFAIK no SOC vendor really designs their hardware to be fully open source compatible from the start, so it takes a lot of years (and sometimes some HW redesign) before all of the major blocks can be exposed.

We started supporting open source drivers early (back in '99 IIRC) but stopped when we acquired FireGL and their proprietary Linux driver, and didn't re-start the effort until 2007. That may seem like a long time to you, but vendors which have been working with open source drivers for a lot longer only finished exposing their major blocks in the last couple of years and if anything we're moving a bit faster than our competitors there. I know that doesn't help, but it probably is worth understanding anyways.

[smitty3268]

Again, what did we prioritize before this round of power management that we shouldn't have ?

I think the real issue here is that it's hard to understand why PM is so hard to release. I think most people understand that DRM issues complicate things when it comes to UVD, or HDMI/audio stuff, even if they don't like the fact that it does.

But PM seems so basic/simple. Especially when we've had developers on here who've seen the code or specs under NDA and tell us that there's absolutely nothing in them that every other hardware vendor isn't already doing.

That said, I'm sure there are a lot of issues holding it up. It's just not obvious what they would be to the average user, hence the frustration.

Thanks again for the great work in getting UVD out. I'm now convinced that AMD's open source effort will work out in the long run, and it's just going to get better from here.

[hal2k1]

I think the real issue here is that it's hard to understand why PM is so hard to release. I think most people understand that DRM issues complicate things when it comes to UVD, or HDMI/audio stuff, even if they don't like the fact that it does.

But PM seems so basic/simple. Especially when we've had developers on here who've seen the code or specs under NDA and tell us that there's absolutely nothing in them that every other hardware vendor isn't already doing.

That said, I'm sure there are a lot of issues holding it up. It's just not obvious what they would be to the average user, hence the frustration.

Thanks again for the great work in getting UVD out. I'm now convinced that AMD's open source effort will work out in the long run, and it's just going to get better from here.

I guess this was what I was trying to say, but expressed far better.

I would just like to re-iterate here on the last paragraph above. I managed to express my frustration that the seemingly simple feature (in terms of sensitivity to revealing IP anway) of power management seems to have been an extraordinarily long time in coming, but I failed to mention appreciation for and the congratulations due to the AMD team for getting UVD out, which I would have thought would have been the far more problematic area.

It was very remiss of me, so once again let me say great work on the UVD front. Let us all hope that the power management work can follow not too far behind, as that release would be a win-win for all concerned.

[Guest]

Yes! Finally! Awesome job AMD!

This is awesome news! Video acceleration through the dedicated hardware video decoders on the graphics card exposed in the open source drivers through VDPAU. What I've dreamed about for a pretty long time. Keep up the good work AMD, I'm glad that you are providing documentation and development effort for improving the open source driver.

[Hugh]

The obvious issue here is that programming specifications can never be totally separated from IP, unless the hardware was designed with some kind of isolation layer to separate the programming from the operation, so effectively the community *is* asking AMD to release IP. This was the case for all hardware blocks... power management is no different.



Header files and hardware design are sufficiently different that I don't think you can apply a "header file" ruling to hardware.

I don't understand why you can't see how programming specifications could reveal information about protected IP, whether it be copyright, patent or trade secret (or any of the other mechanisms which aren't usually relevent to open source driver support).

If you publish specs, you might be endangering some trade secret. You certainly cannot endanger a copyright or a patent. We agree that trademarks aren't on the table.

Your comment suggests to me that you are not talking enough with your lawyers. That surprises me since I picture you (or your predecessors) talking to them for half a dozen years.

I'm also quite surprised at how long the "declassifying" process is taking. It has been over five years since the direction was announced. New chips have been released and sunsetted in that time. I know: I bought several in anticipation of open source drivers. The video card I'm using while I type this is an example: this HD 3600 has UVD1 and so is too old; I did buy it expecting more complete open source support.

The sad thing is that in that five years, Intel has reached sufficient performance for video that it becomes the obvious choice. I bought a few cute Brazos systems but even the closed source drivers have made the experience disappointing. Stupid little things like not keeping up with the kernel, something caused by not being "in-tree".

[log0]

TBH I find this whole GPU hardware interfaces IP completely surreal.

Think of the following fictional case. AMD relesases a new CPU with some new and awesome Cool'n'Quiet bits, but requires you to use a driver to be able to use it. In addition the CPU will have a some badass simd block, but instead of being accessible through an instruction set extension you have to use a driver again.

Because of the IP protection and stuff, you know.

[hal2k1]

If you publish specs, you might be endangering some trade secret. You certainly cannot endanger a copyright or a patent. We agree that trademarks aren't on the table.

Your comment suggests to me that you are not talking enough with your lawyers. That surprises me since I picture you (or your predecessors) talking to them for half a dozen years.

I'm also quite surprised at how long the "declassifying" process is taking. It has been over five years since the direction was announced. New chips have been released and sunsetted in that time. I know: I bought several in anticipation of open source drivers. The video card I'm using while I type this is an example: this HD 3600 has UVD1 and so is too old; I did buy it expecting more complete open source support.

The sad thing is that in that five years, Intel has reached sufficient performance for video that it becomes the obvious choice. I bought a few cute Brazos systems but even the closed source drivers have made the experience disappointing. Stupid little things like not keeping up with the kernel, something caused by not being "in-tree".

This is another comment with which I agree entirely. Programming specs in and of themselves are not IP, but I suppose they might possibly reveal some trade secret (some aspect of hardware design), but I really cannot see how.

So now here is a second poster who has been able to express things better than I. I'm beginning to think that I might need to take a course on better communication skills, or something.

PS: when I say programming specs are not IP, I should point out that AMD can have copyright over the programming spec documents. This would mean that no other party would have the right to duplicate AMDs programming specification documents and sell these document copies for monetary consideration without first getting permission from AMD to do so. It would not mean, however, that AMD would have any other rights over the information within these documents. After all, when AMD sells hardware to customers, said customers are actually supposed to be able to use that hardware however they please, including writing and running open source programs utilising that hardware.

[artivision]

Yes, two drivers. Not sure of current names but something like atidxx32.dll and atioglxx.dll...

What do you mean by FX ?

By FX i mean anything that looks like a shader program, but is inside a GPU driver instead of a game, like a filter for example.

As for the driver, i thing that the synthesizer is not related to any API. That's why compilers target AMD_IL, because that A.I. machine unifies code from different compilers to a more ASIC form.

[xgt001]

when are the PM bits coming!

first of thanks a lot AMD for releasing UVD code. now that this is open source will catalyst will also switch to vdpau?? and how can I try the open uvd code on my system? by latest development snapshot from git with mesa branch?? and looks like AMD is also ready with next round of PM .. when are you releasing it???