A few questions about video decode acceleration

[Redeeman]

so do you really think that we will be using gallium this time next year, with all its glory?

[ollo]

... any chance this will accelerate things for ATI GPUs too?

http://code.google.com/soc/2008/xorg/appinfo.html?csaid=ACD6AA025594454A

http://www.bitblit.org/gsoc/g3dvl/index.shtml

Regards, ollo

[glisse]

... any chance this will accelerate things for ATI GPUs too?

http://code.google.com/soc/2008/xorg/appinfo.html?csaid=ACD6AA025594454A

http://www.bitblit.org/gsoc/g3dvl/index.shtml

Regards, ollo

The beauty of this project is that you get acceleration whenever you have a gallium driver for your hardware. As the plan is to move forward to write a new gallium driver for radeon hardware means that this infrastructure will be accelerated on AMD GPUs. I don't have a time table for when such things will pop up and i think pretty much no one know when this will actually happen. Of course, oddly , writting code is the only way to make this happen

[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

[Forge]

Bridgman - I'm sure that AMD is doing everything they can to open up everything they can. I've put my money where my mouth is and an now running a 4850, my 8800GT is in a desk drawer. I believe you are doing the right thing, and am sure that you will prove that to be true.

Please carry on checking/releasing those docs; thanks for everything you do.

[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!

[Redeeman]

what is the capabilities of the UVD thing anyway?

does it handle 50mbit H264 stream?

[chaos386]

This may be coming a little out of left field here, but what about using CAL/GPGPU? Would it be a reasonable way to avoid the legal issues surrounding the UVD, or would it be so much slower that it wouldn't be worth the effort?

In any case, using the GPU to accelerate video encoding would be a dream come true, and if that gets done, how much more work would decoding be?

[bridgman]

Redeeman: I don't know the exact limits of UVD but they do scale with clock speed, ie the only real chellenge is decoding high bit-rate content at low clocks.

chaos386, that will be no problem and all the info required is available today, either using CAL, or Gallium for the open source world, or by having the drivers feed shader commands into the 3d core like they do for Xv and EXA Render.

What CAL brings is the ability to make use of the shader processors *without* having to have the specialized knowledge of a driver developer. I believe we are demo-ing video encode/transcode using CAL already. Video encoding and transcoding are particularly attractive for execution on the shaders (via CAL or...) because encoding requires relatively more floating point work than decoding (for things like motion estimation).

The main appeal of UVD is that it has enough fixed-function blocks that it can do the same decoding task as CPU + shaders but draw less power while doing it.