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

[AdrenalineJunky]

I didn't think OpenDecode had been released for Linux -- AFAIK it is Windows-only right now.

any clue when(if?) it'll make it to linux?

[bridgman]

No, but we generally don't talk about future plans for Catalyst anyways.

[eldar]

bridgman My question was probably lost in the thread, so I repeat it again - is it feasible to implement VDPAU on top of existing APIs XvBA or even using OpenCL for the purpose of getting accelerated Flash videos? Because VDPAU seems to be an open standard and it even has sources available.

[AdrenalineJunky]

vdpau being an open api, given the proper knowledge and hardware access you could implement it on anything capable of video decoding.

it would be basically the same as what gbaouche did, except he used va-api instead of vdpau.

[bridgman]

I imagine implementing VDPAU on top of XvBA could be done (in the same way that gbeauche implemented VA-API over XvBA) but I don't know that anyone has looked at it. IIRC the VA-API spec has more API options which make it a better fit for implementing over another API.

I haven't looked much at the practicalities of implementing a decode API over OpenCL. It's definitely possible, but I'm not sure how well the two APIs match (ie how well the resulting stack would perform). Implementing a decode API over Gallium3D seems like a better option based on the (very) limited amount of time I have had to look at the options.

[eldar]

But Gallium3D isn't what Catalyst uses, is it?

[evolution]

But Gallium3D isn't what Catalyst uses, is it?

Yes, it's true. Catalyst uses its own OpenGL implementation, not Gallium3D.

Using Gallium3D would cause a huge regression in 3D performance for Catalyst users and OpenGL 3D features (currently has only full OpenGL 2.1 implementation, I think ).

Cheers

[bwat47]

I imagine implementing VDPAU on top of XvBA could be done (in the same way that gbeauche implemented VA-API over XvBA) but I don't know that anyone has looked at it. IIRC the VA-API spec has more API options which make it a better fit for implementing over another API.

I haven't looked much at the practicalities of implementing a decode API over OpenCL. It's definitely possible, but I'm not sure how well the two APIs match (ie how well the resulting stack would perform). Implementing a decode API over Gallium3D seems like a better option based on the (very) limited amount of time I have had to look at the options.

Something really needs to happen to enable hardware acceleration on cards like the 2xxx series . Compared to windows linux is quite unusable when it comes to watching hd videos right now.

I know its not like totally amd's fault or anything, as the whole situation for stuff like hardware acceleration in linux is kind of a mess in the first place.

vdpau may not have as flexible of an api, but when it comes to getting support from stuff like video players, and flash it would definitely be the way to go. I don't see flash adding support for other api's besides vdpau anytime soon. And many linux players already support vdpau, getting va-api/xvba working is a lot more difficult.

I am sure you know a lot more on the subject than I, however.

[bwat47]

Darn 1 minute edit limits :/

anyway. Any flash heavy website is also abysmal in performance compared to the hardware accelerated flash in windows. Just watching a flash video in linux really pegs my cpu and makes my laptop very hot.

This is another example of how fragmentation in linux can really harm things. In windows there is one api. dxva. It is supported by ati and nvidia and in windows 7 will work great by default on most cards. In linux you have xv, xvmc, vdpau, va-api/xvba ect.. and nothing is truly standardized. If there was one api supported by nvidia and ati, video players and flash could target it and get the maximum amount of user satisfaction, rather than only subsets of users with the right cards/packages/driver/player.

[Armin]

LOL So in effect gbeauche could today bump to his potential 0.8.x-series and probably easily implement it on the v2.3 SDK supplied OVDECODE_API On Windows, perhaps even have UVD1 based cards work too, Today.

and so all the windows OSS developers could then integrate that into FFmpeg,VLC etc, adding Yet one More video decode option to their growing OSS windows code base, But Linux today cant do even one fully working option for all (UVD1 through UVD3) AMD based cards due to known reported bug's/missing OVdecode

WRONG: The AMD Stream SDK (as their runtime, AFAIK) only supports Radeon HD 4xxx and higher. So that is not really a way to go for people with an 2xxx or 3xxx, as I'm.

If I understood the infos on the AMD homepage wronge and should be mistaken with this, I'm happy to be corrected.

-Armin