AMD's UVD2-based XvBA Finally Does Something On Linux

[ntt2010]

How about UVD support ?

I wonder why ATI/AMD doesn't support UVD in fglrx, only UVD2.0? Are those
two hardware decoders so different that AMD would have to start write
fglrx driver for UVD support from scratch ?

[gbeauche]

have you been given access to the new sandy bridge prototypes yet ?

No, but I would like to, it's a real great CPU and GPU.

and it seems AMD's UVD is nearly now as good as dead for end user use ,given the sandy bridge Open Encode/Decode ASIC progress

Yes, Intel is already working on VA-API encoding support for Sandy Bridge. I think Fran?ois Piednoel's effort is different from those of the other division. Just hope we don't end up with two drivers.

BTW, Intel is also working on a DRM solution. IIRC, the API already has some provisions for protected content, thus protecting from further vaGetImage() on surface generated from "protected" bitstreams.

[gbeauche]

I wonder why ATI/AMD doesn't support UVD in fglrx, only UVD2.0? Are those two hardware decoders so different that AMD would have to start write fglrx driver for UVD support from scratch ?

The word is in *support*. They already don't support correctly current HW, how do you want them to suppport obsolete HW? Actually, older UVD HW also kind of works but no effort will be made in fixing it if it breaks in a new fglrx release. e.g. some people reported success with HD 3xxx, and even some HD 2xxx series, but I do see some troubles with HD 3870.

[popper]

No, but I would like to, it's a real great CPU and GPU.



Yes, Intel is already working on VA-API encoding support for Sandy Bridge. I think Fran?ois Piednoel's effort is different from those of the other division. Just hope we don't end up with two drivers.

BTW, Intel is also working on a DRM solution. IIRC, the API already has some provisions for protected content, thus protecting from further vaGetImage() on surface generated from "protected" bitstreams.

when Fran?ois Piednoel said "2010-10-18 05:59:18 < frpiednoel> for the moment, we are only supporting windows ... and via DXVA2", he was referring to the Intel? Media SDK 2.0 use as most dev's will need to use.

http://doom10.org/index.php?topic=717.msg4534#msg4534

"...
For Most of the world, SandyBridge acceleration will be accessable through mediaSDK , because it is the easiest way to do it.
After taking with Loren, one thing was very clear, He was totally clear that the x264 community would not include a call to a DLL without any control of the encoding process. I understood his point, and toke on myself to go and try to get the autorization to turn around MEdiaSDK and give you guys direct access (That mean to the world) to the Magic of SandyBridge...."


he went out of his way to stress X264 gets his support directly, and i take that to mean other open dev's such as yourself and your efforts
can also benefit, its probably wise if you go on IRC and ask Dark_Shikari for the details in private as i think they went quiet as people where picking up to many interesting hints

Fran?ois Piednoel did say he would sort out access to the chips for Dark_Shikari, pengvado,<Alex_W, and any other x264 dev's interested, so you can too if you ask on IRC, do you hack on x264 patches, or follow the x264 code-base at all BTW ?

if you dont have an IRC client handy theres always generic web IRC clients such as http://webchat.freenode.net/

enter your required name and #x264dev as the channel your interested in and type the catcha , done

[popper]

if you dont hack on x264 yet, now might be a good time to start LOL

[gbeauche]

he went out of his way to stress X264 gets his support directly, and i take that to mean other open dev's such as yourself and your efforts
can also benefit, its probably wise if you go on IRC and ask Dark_Shikari for the details in private as i think they went quiet as people where picking up to many interesting hints

Intel Media SDK 2.0 is a Windows specific API and library. We also want a fully Open Source implementation using the encoder. This is what Intel is working on, for VA-API on Linux. So, the next steps are to extend FFmpeg and other media application to take benefit of it.

Actually, they were looking for VA-API application using the encoding API for validation. Something that another Intel division already had (GStreamer plugins)... for GMA 600.

[Kano]

It is just bad that VC1 is not supported on Intel.

[popper]

Intel Media SDK 2.0 is a Windows specific API and library. We also want a fully Open Source implementation using the encoder. This is what Intel is working on, for VA-API on Linux. So, the next steps are to extend FFmpeg and other media application to take benefit of it.

Actually, they were looking for VA-API application using the encoding API for validation. Something that another Intel division already had (GStreamer plugins)... for GMA 600.

re the Media SDK, Yeah i know, but the x264 dev's have made sure to include and re-enforce FFmpeg as their preferred input/decode option as they also hack on that and have told Fran?ois to also make sure to include FFMpeg in all this, as the decode part of any patches etc,so im not worried, FFMpeg will get access too.

[gbeauche]

re the Media SDK, Yeah i know, but the x264 dev's have made sure to include and re-enforce FFmpeg as their preferred input/decode option as they also hack on that and have told Fran?ois to also make sure to include FFMpeg in all this, as the decode part of any patches etc,so im not worried, FFMpeg will get access too.

It's midnight in Paris so I will probably join IRC tomorrow if I am not too busy. Anyway, Sandy Bridge is very impressive, and they did a great job on the GPU side. Better than expected.

[popper]

It is just bad that VC1 is not supported on Intel.

well thankfully even MS dont push VC1 (the extended Divx mpeg4 part 2 codec ) and use and advocate AVC/H.264 for general use today , so its not so bad, if dev people really wanted VC1 , then they would and could patch FFMpeg with a VC1 Encoder to make it more viable today OC, but why bother when you now have the option of a commercial x264 licence today.