UVD/hw acceleration If, when?

[bridgman]

now kernelOfTruth, be fair it's ONLY BEEN 387 DAYS since the UVD IP review was mentioned Right here on the board, you cant expect a Generic Industry standard AMD/ATI UVD Hardware ASIC IP Review to be Authorised, signed off, and started, let alone done and dusted so quickly;

I think it's been more than 387 days, hasn't it ? I thought the discussion came up relatively early in the project. I said we would tack UVD onto the *end* of the current plan, not that we would bump other existing commitments to make room for it.

Next you will be asking other unreasonable questions like were are the closed source linux beta UVD HW Decode drivers and/or were are the pass this to play/use with the supplyed beta UVD ffmpeg/x264 patchs comment or two on the dev blog URLs

The beta drivers went out to the beta users, and the same functionality has been in the released drivers for a few months now. Not sure if it has moved from development to "official feature" yet, but checking.

IIRC the "mention" of patches was that we would probably *not* be making them available.

[Neuro]

I think it's been more than 387 days, hasn't it ? I thought the discussion came up relatively early in the project. I said we would tack UVD onto the *end* of the current plan, not that we would bump other existing commitments to make room for it.

And what's the current plan? I presume Evergreen is the priority right now, followed by? Old-mesa 3d or Gallium 3d? I'm just curious whether or not hw/acceleration, with the "A OK" from the IP review, can somehow bubbleup to the top of the list in the next, I don't know, 18 months?

I know that I'm pulling your tongue a bit here Don't get me wrong, I'm grateful for the AMD approach to the open source stack (open specs etc), and I have to say the open source drivers rock, especially when you take into consideration the timespan they reached they're current state. I'm just curious

IIRC the "mention" of patches was that we would probably *not* be making them available.

What patches, could you elaborate a bit? Are you talking about patches for XvBA support in mplayer/vlc/xine, whatever, or UVD patches for the open source drivers?

[bridgman]

The list is getting pretty short - Evergreen, resolving some power management problems the devs are running into, HDMI audio for newer GPUs... there's probably something else I won't remember until the second cup of coffee kicks in. I've already started looking at UVD in terms of putting together a plan, and that's where the licensing issues came up -- specifically whether the license which allows us to ship the hardware and software for a decoder as a set will cover enabling third party software to use our hardware. I think it will be OK but it's one more thing we need to investigate.

[bridgman]

(&^%$#&^%$*&%@!! only one minute to edit, stinkin' spammers)

Remember that our commitment is to investigate, not to provide an A-OK. The answer might be "NO".

The patches were internal development changes to exercise XvBA on a few different players. The patches have to stay internal unless/until we have a decision on releasing a public API.

[Neuro]

I've already started looking at UVD in terms of putting together a plan, and that's where the licensing issues came up -- specifically whether the license which allows us to ship the hardware and software for a decoder as a set will cover enabling third party software to use our hardware. I think it will be OK but it's one more thing we need to investigate.

Remember that our commitment is to investigate, not to provide an A-OK. The answer might be "NO".
The patches were internal development changes to exercise XvBA on a few different players. The patches have to stay internal unless/until we have a decision on releasing a public API.

Ok, so this is a licensing issue: you're not sure whether or not you can provide an API which will allow, third-party players (e.g. mplayer or xine), which are potentially not under the license, to use the hardware and software you've got that's under the license. Am I right?

So, I understand this impacts the FGLRX driver... with it you control the HW specs and would only provide a XvBA API... and the issue here is exactly what you stated: you don't know whether or not the publix XvBA API/binding would violate the licensing.

Where does the open-source effort kick in?
The easiest way to do that would be for AMD to release HW specs for open source coders to implement. I recall someone, somewhere mentioning that you're not sure whether that is possible without compromising HDCP, because the DRM stuff is tied up to the acceleration stuff. Is that right?
If that were true, would it mean that there would never be an open-source UVD code? Or could the open-source UVD code be implemented by someone under NDA, with some voodoo "put this here, and read from register there"?

[bridgman]

Nope, the licensing issue is for open source, not for fglrx. The question is whether the combination of our hardware, specs we release, and an open source driver would be covered by our license.

This is in addition to the DRM concerns we knew about at the start; just something that came up when I was starting to rough out a plan.

I can't really speculate on what the available options would be if we couldn't open up UVD, since the available options would depend on which specific problem or problems blocked us. Linux doesn't have the same kind of protected runtime environment as Windows, so releasing a closed source module would basically be the same as jumping up and down yelling "this bit, this bit, reverse-engineer this bit"

[Neuro]

Ah, alright, is pretty clear.

So now it's up to the IP review to decide whether or not UVD will come to open-source drivers. Figers crossed

Just one more question, I know I've already asked a lot... could you give a rough estimate when the IP review will be finished? How long things like that take? A month? 3 months? A year?

[bridgman]

Again, the time varies wildly with the complexity of the domain and the issues we find along the way. It's pretty fast and easy to say "nope" and stop at the first issue... it takes a lot longer to slog through each issue and find a solution for each one. Given that, how long do you want it to take ?

Seriously, you should assume 3-4 months from the time it starts en earnest. It hasn't started in earnest yet.

[Neuro]

I do understand the complexity of the whole licensing/drm/legal stuff. And yea, haste makes waste.

I hope the final outcome, eventually, will be releasing the specs for UVD... Having seen what the open source community, with the help of AMD employees, could do with the R600-R700 specs in such a short time, I really think that'd be the best thing to happen to Linux as a multimedia/video/htpc platform, ever.

Fingers crossed.

[Neuro]

i tell you the time-point they release the specs of the UVD unit....
if someone crack/reverse-engineering the windows HDCP/Copy-protection.
and that on all hardwares,,, intel,nvidia,amd..
after that there is no need for hold the stuff back in the dark,,,

Nah, I don't think that's true. Seeing the rise in popularity of HTPC setups and the fact that nVidia (with their VDPAU-enabled binary blobs) is the only reasonable solution for such use, I think AMD will really try to release the specs.
The thing is simple: if AMD can provide a cheaper, more powerful graphics card with HW-acceleration of VC-1/h.264 with open source driversm which would work out of the box.. they'd have a real killer in the geek-driven HTPC market. And keep in mind, that it's the geeks who are asked for advice by normal consumers on what to buy.

Bridgman, one more question I'd like to ask: what about OpenCL on the open source drivers? Do you have that feature in your release plan? I know that probably that would be done through Gallium. How do you think a Gallium implementation of OpenCL (on for example R7xx or even R8xx) would perform, say compared to the FGLRX drivers?