A few questions about video decode acceleration

[TechMage89]

I have a few questions about video decode acceleration:

1.) I understand that the Avivo video processor's specs can be released without legal issues, but UVD's specs cannot because of output protection stuff. Does this mean that R600+ chips will not be able to have any open-source video decode support, or that their support will be limited to the avivo functions? In either case, I'd like to bring up the suggestion again of a blob for video decoding that the open-source driver could tie into.

2.) Bridgman, have the people at amd begun to rummage for video decode spec documents? Do they exist? When do you expect you'll have time to start cleaning them up for release?

3.) This question is more toward the driver developers. What api do you think will be useful for video decode. Is VAAPI the future? Or will extensions to Xvmc work?

[bridgman]

1. I understand that the Avivo video processor's specs can be released without legal issues, but UVD's specs cannot because of output protection stuff

Yep, although the "avivo video processor" is not so much a single processor as a combination of high quality video paths (AVIVO := Advanced Video In / Video Out), some changes to the shader core to process video more efficiently, and some proprietary back-end video processing running on the shaders. If you think about the video pipeline as being decode followed by render, AVIVO is basically very good render acceleration and back-end processing.

R128 through R6xx all have hardware support for the IDCT and MC decoding tasks; IDCT in dedicated hardware, MC using special modes on the shaders. I'm pretty sure we will be able to open IDCT/MC on all those products, not sure about UVD on 6xx.

The 6xx family adds UVD, and we run H.264 and VC1 decode on UVD instead of on the existing IDCT/MC hardware. I suspect the IDCT and MC hardware (which we plan to open up) will also be useful for H.264 and VC-1, just not as efficient as UVD. I don't think we have actually tried using IDCT/MC on H.264/VC-1, however.

Everyone with me so far ? OK, good.

The 780 IGP is the first of the 7xx family with UVD2, and on those parts the IDCT block gets absorbed into UVD so MPEG2 acceleration is done on UVD as well as H.264 and VC-1.I think our chances of opening UVD on 7xx are actually a bit better than UVD on 6xx, but not sure and haven't spent any time on it yet. My current thinking is to open up IDCT/MC on 1xx-6xx, and try to open UVD on 7xx.

Bottom line is that I expect we will be able to enable some pretty good decode *and* render acceleration. It may not use every bit of HW in the chip but other than people playing DVDs on long airplane trips while running Linux I doubt anyone will notice the difference.

2. have the people at amd begun to rummage for video decode spec documents? Do they exist? When do you expect you'll have time to start cleaning them up for release?

Yes and no. Our focus is 6xx 3d, but we are keeping our eyes open for low-hanging fruit. Dave Airlie reminded me yesterday that we used to have a proprietary API for video acceleration which was pretty small and simple, and that if we could dig up source for that it would be a pretty good ddk for using the IDCT/MC hardware on most of the Radeon parts.

The specs defintely exist, that's not a problem; the issue is making sure that we can safely and legally release enough info to write a useful driver. Best guess right now is that we'll start spending more time on video in July.

3. What api do you think will be useful for video decode. Is VAAPI the future? Or will extensions to Xvmc work

I expect XvMC extensions to be the primary API for a while. VAAPI may be newer and cleaner (although I haven't looked at it enough to be sure) but everyone tends to implement XvMC first then XvMC extensions are just an extension away

[TechMage89]

Thanks for the answers, Bridgman, that clears a few things up. I get the impression, than, that *any* modern ati card I purchase will get me some kind of video decode acceleration once this stuff is done. It's great news to hear that it might be possible to open up UVD on r700, that would be awesome for making a mythtv box.

So video accel docs will be worked on once the 3d stuff is all out the door, and you guys are keeping an eye out for things that might be helpful at this point.

The reason I was asking about VAAPI is that what I've heard is that extending XvMC would be difficult and messy to use, and that it might only expose limited functionality (maybe it would be OK for the idct/mc stuff, but probably not for anything beyond that). Since we're starting from scratch here, it seems to make more sense to me to start on a new architecture that's designed to do what you're trying to. I don't know that much about the intricacies of driver development, but there were concerns that VAAPI is Intel-centric and might not adapt well to other cards. Have any of the devs look at the VAAPI spec? Are these concerns justified?

[Ragool]

Hi Bridgman

The 780 IGP is the first of the 7xx family with UVD2, and on those parts the IDCT block gets absorbed into UVD so MPEG2 acceleration is done on UVD as well as H.264 and VC-1.I think our chances of opening UVD on 7xx are actually a bit better than UVD on 6xx, but not sure and haven't spent any time on it yet. My current thinking is to open up IDCT/MC on 1xx-6xx, and try to open UVD on 7xx.
...
Macrovision and HDCP are no problem -- they're actually implemented in the output blocks and we released docs on those back in September/October last year.

This is more serious stuff -- and before you ask, if I could tell you more I WOULD HAVE ALREADY RELEASED THE DOCUMENTS

I am confused. So is it HDCP or is it something else proprietary that is a roadblock to opening UVD? Are you open to TechMage89 's suggestion that radeonhd hook into a UVD blob on linux/freebsd? Or is it against the development philosophy of the radeonhd movement? I hope you are planning for it, else a lot of us will be sorely dissapointed. We would like to see the marvelous performance at low cpu utilizations that the 780G promised us in the specs and reviews. Or is it more correct to say that since UVD is an ASIC optimized for playing protected content, non-protected content will not have much (efficient) use for it ?

I was salivating when I brought the 780G, now my mouth is dry ...

TIA
Kind Regards
Rahul Sawarkar

[bridgman]

I am confused. So is it HDCP or is it something else proprietary that is a roadblock to opening UVD? Are you open to TechMage89 's suggestion that radeonhd hook into a UVD blob on linux/freebsd? Or is it against the development philosophy of the radeonhd movement? I hope you are planning for it, else a lot of us will be sorely dissapointed. We would like to see the marvelous performance at low cpu utilizations that the 780G promised us in the specs and reviews. Or is it more correct to say that since UVD is an ASIC optimized for playing protected content, non-protected content will not have much (efficient) use for it ?

It's not HDCP. Playing protected content (eg. BluRay) legally requires that all of the data from decoder to screen be protected, either by making it "only visible on chip" or encrypting it. Here's an example :

http://en.wikipedia.org/wiki/Protected_Media_Path

The UVD block was designed to play both protected and unprotected content; the challenge is exposing enough info to let you play unprotected content without putting our *protected* content implementations on other OSes at risk.

The problem with dropping a blob into an otherwise open driver is that it makes the blob really easy to reverse engineer. IMO we either provide enough information to use UVD directly in the open driver or we focus on an implementation using the shaders and IDCT block instead. The 780 is the first of our products using the new UVD2 block, which I *think* will be a bit easier to open up safely.

[Forge]

The 780 is the first of our products using the new UVD2 block, which I *think* will be a bit easier to open up safely.

Oooh, ::happy::. So UVD2 might be easier to open than UVD1 was. Even for a qualified answer, that still makes me even happier with my new HD 4850.

RV770 FTW!

[brouhaha]

I can't imagine why there would be any legal problems with releasing the docs on any of the video stuff, as long as the details of enabling Macrovision and HDCP are redacted.

[bridgman]

Macrovision and HDCP are no problem -- they're actually implemented in the output blocks and we released docs on those back in September/October last year.

This is more serious stuff -- and before you ask, if I could tell you more I WOULD HAVE ALREADY RELEASED THE DOCUMENTS

[brouhaha]

It's stuff so secret that you can't even tell us in general terms what it is and why it's secret? I'm impressed! Sounds like real cloak-and-dagger stuff! :-)

Anyhow, thanks again for all the hard work you and the team have put into getting the docs released and supporting open driver development! It's nice being able to recommend ATI products to friends, coworkers, etc., with no reservations.

[TechMage89]

He could tell us. But then he'd have to kill us. And that's a little hard over the internet.