ATI, please release an Open UVD API

[V!NCENT]

Lets reverse engineer without manpower anyway. Yeah that'd be great; AMD's DRM gets cracked, key revoked and FLOSS documentation stops!

[Jimbo]

uvd is nonsence because uvd is only a copyprotection the UVD self uses the SHADERS! to calculate the vids...

No, UVD is a dedicated chip, it uses its own functions to calculate vid, using very low power. Post processing is done on shaders.

Anyway, I would not consider uvd really important nowadays. Mplayer / ffmpeg is truly an awesome software!!, try to read their devel list you will be shocked, those devs work at assembler level fighting to achieve always less cpu cycles per instruction. An atom d510, 10 W cpu, with mplayer-mt (multi-threaded version) can decode Hi-Def h.264 AVC @ 40Mbps.

[Jimbo]

the hd2900 for exampel do have no UVD unit but the same featureset...

uuhh you mean the UVD unit use the shaders for post-processing ? LOL..

i know the UVD unit use the shaders.

because.... the shaders do the work and the UVD unit do the copyprotection.

No you are wrong.

The 2900 is a special case, where amd marketing claims things that 2900 doesn't have.

http://www.dailytech.com/Whoops+ATI+Radeon+HD+2900+XT+Lacks+UVD/article7447.htm

[Jimbo]

No, you are totally wrong. You can have all features not because UVD does the drm portection and shaddes do the work, it is because software - cpu does all the work. On GPU with UVD chip (present on the same GPU die) video uses specifically implemented UVD functions to get decoded, and then it is post processed using shaders or cpu.

[Panix]

So, ATI, why don't you release a API to make use of UVD? That way you can keep all the secrets and still unleash the power of UVD in Linux. The Linux community will likely pick it up and make vaapi implementations which in turn can then be used in players like mplayer, xine and what not.

I'm asking this because ATI is even actively promoting it's new features, but we all know they are not available on Linux at all! The little deal you have with splitted-desktop-systems is nice and does help to get some UVD stuff in linux, but it would be far better if you just release an API to make use of all of UVD's power.
^

Good luck on that...

[gbeauche]

you can have all feature with NO UVD unit but you need the UVD unit for DRM and Copyprotection.

No, you can't. The problem is you don't know, or understand, about the different decoding stages. In particular, what VLD, motion compenstation et al. are all about, and where it is done.

and the UVD unit use 'shaders' for calculations.

Again, no. It's a separate block with specific I/O.

[HokTar]

right now bridgman and os team work an an shader based solution for the os driver.. thats a big deal!

Any source of this?

I would be really happy but honestly I don't think this is the case. Bridgman only said that they will try their best to be able to give out documentation for uvd for _future_ generation cards. And there is a big difference.

Probably our best chance is Veerappen who wants to write a vp8 decoder in opencl. However, we don't even have a working opencl state tracker at the moment...

[droidhacker]

Any source of this?

I would be really happy but honestly I don't think this is the case. Bridgman only said that they will try their best to be able to give out documentation for uvd for _future_ generation cards. And there is a big difference.

Probably our best chance is Veerappen who wants to write a vp8 decoder in opencl. However, we don't even have a working opencl state tracker at the moment...

Bridgman did make some remarks to that effect as I recall. I'm not going to bother looking it up and posting a link since it was on this forum -- you can search for it yourself.

As I understand it, it is an integrated unit, using both shaders as well as some proprietary logic. Fact though, is that many of the older cards did lack the "UVD" unit, and instead did some of the work on the CPU, still with the heavy lifting on the shaders.

BOTH ARGUMENTS ARE RIGHT AND BOTH ARGUMENTS ARE WRONG. It is somewhere in between!

[bridgman]

Any source of this? (bridgman & team working on shader based decode)

Didn't come from me

A few things :

- UVD *does* do the decoding work (without using shaders), but it *also* participates in DRM

- everything *after* decode is done on shaders... colour space conversion, scaling, filtering, other post processing etc...

- haven't had time / remembered to find out how r600 handles video but believe it runs decode on CPU then uses same post-processing on shaders

- we are still working towards an XvBA API release for fglrx, schedule TBD but hopefully soon

- I'm still saying "don't assume we will be able to release UVD programming info" but we are still going to investigate whether it can be done... we've worked through enough of the higher priority tasks that I think investigation will happen in the next ~6 months or so

- key point is that spending time investigating UVD programming info release means that time is not being spent on releasing other info/code and that other info has much higher probability of success... we might spend a few man-years of effort investigating UVD and conclude that we can't release anything, but the time would still be gone and other potential good things would not get done in the meantime

- UVD only accelerates specific formats so for things like Theora and VP8 you're still going to want shader-based decode IMO...

- I still think the best plan is to implement an XvMC-ish state tracker over Gallium3D (but designed for modern video formats, not MPEG2) then modify ffmpeg/libavcodec and others to use that state tracker for MC and deblock filtering... you could do more (IDCT etc.. ) on shaders in principle but IMO you're better off avoiding having to push data back from GPU to CPU so best approach is to pick a point in the decode pipe where everything *after* that point can be done efficiently on shaders...

- IIRC the only sticky part with modern video formats and that approach was inter-prediction... probably do-able but haven't had time to work out the details

EDIT - I haven't complained about the 1 minute edit limit for a while, so consider it complained-about

[Jimbo]

From wikipedia, seems pretty correct:

UVD/UVD+

Decoding of H.264/AVC, and VC-1 video codecs entirely in hardware. However, video post-processing is passed to the shaders. MPEG-2 decoding is not performed within UVD, but in the shader processors.

UVD 2 (ati HD4000)

Full bitstream decoding of H.264/MPEG-4 AVC, VC-1, as well as MPEG2 video streams, and in addition it also supports dual video stream decoding and Picture-in-Picture mode. This makes UVD2 full BD-Live compliant.

UVD 2.2 (ati HD4000 and HD5000)

The UVD 2.2 features a re-designed local memory interface and enhances the compatibility with MPEG2/H.264/VC-1 videos.


Briefing, on cards with UVD chip:

-Decoding of H.264 and VC-1 doesn't use shaders.
-Decoding of MPEG2 use shaders on UVD/UVD+, on UVD2 don't use shaders.
-Post processing is done on shaders.