ATI, please release an Open UVD API

[markg85]

Hi,

from time to time i give ATI some rants because they totally deserve it for making (lets stay polite this time) not perfect video card drivers in linux. However the recent developments in the open source ATI drivers are suddenly shooting up so i think it's that time again to beg for something that ATI still hasn't made available yet.

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.

2 links for ATI's UVD promoting in slides:



btw, confidential? NDA? you ATI guys should check the ones you give your slides to.. they are all over the web right now (not that i mind it).

The bigger picture
There is a bigger picture in this (not talking about the above images). You know there is a little thing in Linux called "VA API"? That little thing isn't much of a success right now because there is only one vendor making it possible to make a vaapi implementation: nvidia! There is a closed source vaapi lib for ati, but that's sadly far from being perfect.

I know this motivation has been brought up more then once but i do it again anyway. nvidia is able to give a API to let users make a vaapi lib, so why can't AMD/ATI do that as well? In theory (if you look at how open ATI is with linux) they should be more then willing to provide it so i just don't get why they didn't do that yet... Does there really needs to be a company that asks it from ati along with a big bag of money?

Here is a BIG advantage when both nvidia and ati (as the 2 biggest GPU manufactures) have a fully functional vaapi lib that is reliable: other software devs can then start to use vaapi to get hardware accelerated decoding! For example flash (how much i hate it sucking up my cpu), the oss flash alternatives, all media players out there for linux and it would greatly improve the linux graphic experience since most users simply often do things video related (browsing youtube for example).

So, again. Please make a UVD API available that allows the linux community to develop vaapi drivers. It would be best if this UVD API would also be usable for the open source ATI alternative drivers, but i can imagine that being a lot more difficult then making an API available through the catalyst driver.

Last but not least. I want to mail this to all ATI persons remotely connected to this issue to let them know it _is_ an issue. I'm searching for one person's email in perticulair: "Dirk Meyer" AMD CEO. I want him to read this and finally get some speed in this (hopefully he likes linux), but i haven't found his email address yet.. if someone could pm that to me?

I was nice this time right? ^_^
Just wait and see how my post is when i get a 6870 card and find out that it doesn't work ^_^

[droidhacker]

Can't possibly agree with that idea.
The binary driver is targeted for their workstation customers, who don't spend all day every day playing videos.

The open source driver is what YOU should be using.

If you use the open source driver, then a UVD API in the blob driver is pointless.

So forget about that.... just get something working on the open source driver!

[markg85]

Can't possibly agree with that idea.
The binary driver is targeted for their workstation customers, who don't spend all day every day playing videos.

The open source driver is what YOU should be using.

If you use the open source driver, then a UVD API in the blob driver is pointless.

So forget about that.... just get something working on the open source driver!

You have to start somewhere and a "in driver" API is far more likely then a API that can be used through the oss driver. Don't get me wrong here i do want to get it working in there, but that might be a bit to much to ask right now.

As for using the oss driver.. If it would be usable i would but i hate to see my fans spinning at 100% or to get seemingly random xorg crashes all the time or disabled compositing effects (KDE, KWin)... The oss driver (although progressing nicely) is just not usable for me yet in day to day usage.

[droidhacker]

You have to start somewhere and a "in driver" API is far more likely then a API that can be used through the oss driver. Don't get me wrong here i do want to get it working in there, but that might be a bit to much to ask right now.

As for using the oss driver.. If it would be usable i would but i hate to see my fans spinning at 100% or to get seemingly random xorg crashes all the time or disabled compositing effects (KDE, KWin)... The oss driver (although progressing nicely) is just not usable for me yet in day to day usage.

You must be using some ancient version. In my experience, the Open driver is 100% stable. Fans??? Who needs fans! I don't have any fans. No crashes, compositing works great -- compiz or metacity, can't stand kde, just too "windoze-meets-the-smurfs" for my taste.

[markg85]

Oke, i've done a little bit of "research" to see why UVD works so neat on windows and so bad on Linux. Turns out that UVD works in windows by using DXVA : DirectX Video Acceleration and through that anyone can make some app to have accelerated video decoding fun. And since gallium already has native Direct3D support it must already be possible (perhaps though wine since that can read dll files) to make an implementation of the DXVA 2.0 specs : http://download.microsoft.com/downlo.../DXVA_H264.pdf then somehow use the catalyst DXVA dll to make calls to UVD.. Then you can make a va-api wrapper that uses the DXVA lib and from there on plain linux can be used.

Yes, i know this is quite a detour to get it working, but think of it this way. Windows catalyst drivers will always be in a better shape then their linux counter parts (foss and closed drivers) and with this detour you always use the windows driver thus your always "on par" with windows regarding video decoding.

I agree that a opensource UVD driver and specification is far better, but sadly not likely to happen anytime soon.

Now there are a few things to do here and i sadly can't do any of them. Sadly no time nor knowledge to do it.

- Create a DXVA 2.0 linux implementation
- Somehow use the windows catalyst UVD (or DXVA) driver in wine
- Create a VA API wrapper

This can perhaps be made a little easier by ATI by providing the DXVA driver as a separate dll file (don't know where it is now.. can't find it in my windows installation.. perhaps it's already a seperate dll file)

Seriously think about this with for example the gallium r600g driver. If that's made with direct3d support enabled then it should be possible to implement the DXVA 2.0 spec in linux and once that is done it should be possible to use wine to load the DXVA 2.0 ATI windows library followed by making a VA API wrapper, then you have in fact "through wine" hardware accelerated video decoding! It actually doesn't seem like a bad idea to me.. just a lot of work and requires wine to play accelerated video.

Note: VLC already has a self made dxva2api.h file : http://download.videolan.org/pub/vid...rib/dxva2api.h which might be fairly easy to port to Linux when the r600g driver is used..?

Let me know what you guys think,
Mark

[jrch2k8]

Oke, i've done a little bit of "research" to see why UVD works so neat on windows and so bad on Linux. Turns out that UVD works in windows by using DXVA : DirectX Video Acceleration and through that anyone can make some app to have accelerated video decoding fun. And since gallium already has native Direct3D support it must already be possible (perhaps though wine since that can read dll files) to make an implementation of the DXVA 2.0 specs : http://download.microsoft.com/downlo.../DXVA_H264.pdf then somehow use the catalyst DXVA dll to make calls to UVD.. Then you can make a va-api wrapper that uses the DXVA lib and from there on plain linux can be used.

Yes, i know this is quite a detour to get it working, but think of it this way. Windows catalyst drivers will always be in a better shape then their linux counter parts (foss and closed drivers) and with this detour you always use the windows driver thus your always "on par" with windows regarding video decoding.

I agree that a opensource UVD driver and specification is far better, but sadly not likely to happen anytime soon.

Now there are a few things to do here and i sadly can't do any of them. Sadly no time nor knowledge to do it.

- Create a DXVA 2.0 linux implementation
- Somehow use the windows catalyst UVD (or DXVA) driver in wine
- Create a VA API wrapper

This can perhaps be made a little easier by ATI by providing the DXVA driver as a separate dll file (don't know where it is now.. can't find it in my windows installation.. perhaps it's already a seperate dll file)

Seriously think about this with for example the gallium r600g driver. If that's made with direct3d support enabled then it should be possible to implement the DXVA 2.0 spec in linux and once that is done it should be possible to use wine to load the DXVA 2.0 ATI windows library followed by making a VA API wrapper, then you have in fact "through wine" hardware accelerated video decoding! It actually doesn't seem like a bad idea to me.. just a lot of work and requires wine to play accelerated video.

Note: VLC already has a self made dxva2api.h file : http://download.videolan.org/pub/vid...rib/dxva2api.h which might be fairly easy to port to Linux when the r600g driver is used..?

Let me know what you guys think,
Mark

i think that can't be made easily or at least it will take 3 times more time than simply do it with a native interface, especially assuming that you need to do the miracle of find out what the hell dxva is calling inside the GPU and then you will need the second miracle of find out where the hell that code is present in fglrx if exists at all(probably is complete disabled in compilation time) assuming the fact is not possible to install catalyst on wine and even less possible to get it to render due to the fact that wine can't access directly the gpu and the zillion windows dependencies of the internal coding to access the gpu, beside that is a project that will born dead, nobody is going to go through that mess and wine fight to get video accel on linux through a windows app(i'am one)(assuming you can get that mess to render in realtime without a 5970 and an i7).

on the windows side is easier and much less costlier cuz you are just reusing the plataform that already exists in windows but for linux won't be pretty

in the case of direct3d is a total different situation since gallium is pretty close to the D3D specification and wine already have a convertion layer created for D3D/opengl, so you just need to replace the opengl path for the TGSI exported path, but DXVA is completely unrelated for most of the parts to D3D and there is nothing similar enough in wine or linux and the dxva plugin for uvd won't magically work with catalyst since that plugins is pretty much a wrapper of internals of the gpu that would be a hell to reverse engineer and since we don't know how UVD works or how to access it in the GPU we should have to do it using shaders anyway...

so in conclusion, this one most likely won't happen at all or at best in a very long future, for the OSS driver the best is a native implementation perfomance wise and acceptance wise.

BTW, UVD use shaders too, UVD seems to handle the decryption/hdcp/drm and few other stuff and the shaders do the heavy lifting using pre created path in the shaders(maybe from the firmware itself maybe brigdman could be clearer on this) and since there is no way in hell that RIAA and combo would grant permission to legally use decrypt/hdcp/drm/etc. the community would end cracking and removing it(for linux, in windows already exists, it just stuff of porting it)

[gbeauche]

Yes, i know this is quite a detour to get it working, but think of it this way. Windows catalyst drivers will always be in a better shape then their linux counter parts (foss and closed drivers) and with this detour you always use the windows driver thus your always "on par" with windows regarding video decoding.

You are assuming the wine and/or Direct3D parts are in good shape. Going through a Win32 DLL is insane.

- Create a DXVA 2.0 linux implementation
- Somehow use the windows catalyst UVD (or DXVA) driver in wine
- Create a VA API wrapper

The VA-API driver for using the UVD on Linux already exists: this is xvba-video. It was also suggested to get access to the lower-level API and hook directly into the driver, thus bypassing the whole XvBA implementation and API defects. So far, this failed.

Seriously think about this with for example the gallium r600g driver. If that's made with direct3d support enabled then it should be possible to implement the DXVA 2.0 spec in linux and once that is done it should be possible to use wine to load the DXVA 2.0 ATI windows library followed by making a VA API wrapper, then you have in fact "through wine" hardware accelerated video decoding! It actually doesn't seem like a bad idea to me.. just a lot of work and requires wine to play accelerated video.

This would be a bad idea, and I would even prefer using XvBA in that case...

BTW, S3 wrote their VA-API driver this way and actually ported their DXVA implementation to Linux verbatim. Yes, perverting the VA-API data structures with the DXVA ones as is. Needless to say, this looked awful.

[bridgman]

markg85, I'm surprised your fans are running at 100% unless you haven't actually enabled any of the power saving features. What power profile are you using ?

[markg85]

markg85, I'm surprised your fans are running at 100% unless you haven't actually enabled any of the power saving features. What power profile are you using ?

that was some months ago with the 2.6.34 (or even the .33) kernel and i did get it working back then but that caused xorg crashes... however the state is much better now.

but please this wasn't the question! lets stay on topic.

[droidhacker]

So... the topic is "we need video accel".

Well, if what they have in the blob was made better/perfect, I *still* wouldn't use it, because that would require the use of the blob, which I am NOT interested in.

I therefore say... give us UVD for OPEN SOURCE.