ATI, please release an Open UVD API

[Kirurgs]

Hi!

My 2 cents If a person is not technical enough, don't know architecture of drivers and near future plans of driver vendor, it might not be a good idea to suggest do this and that in technical form...
I'm for the working stuff, I don't care whether it's FOSS or not, I spent money on card so I expect it to work with all features working properly.
To be honest I would be for closed source as certain features would be available only to closed source for different reasons, but as already speculated here, AMD just doesn't have enough manpower to correct drivers and priorities are not mainstream consumers, but proffessionals... This is rather sad, however speaking for me, I'm better off with AMD (catalyst) in laptop than nVidia due to PM features like hibernate and suspend, which flawlessy worked on AMD but were failing on nVidia.
I would really like to see XVBA or whatver which is on par with nVidia... I'm having nVidia only in my HTPC just because AMD does not have anything to offer for Linux, I have couple of AMD's but for Desktop / Mobile...
But still, that's priorities, I personally think that if some decision maker in AMD will say we need decent video acceleration, it would happen and not at very high cost, but then again, Linux share is veeeeeeeeeeeery small, so this is how it is, struggling to get anything done But again, nVidia has done VDPAU very nicely, that's why I spent bucks on 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.

[markg85]

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)

I can be wrong but i read somewhere that it's _not_ using shaders.. why else have a separate chip for decoding if you use the GPU chip anyway?

And i still think that either this path or reverse engineering is going to be the fastest way to get the full power of UVD in the near future. Remember that just 2 years ago someone here on phoronix made a native "directx on linux" topic which was somewhat seen as not gonna happen anytime soon: http://www.phoronix.com/forums/showthread.php?t=12287 and now 2 years later we have it.

As for your double miracle. Why would that be needed in the first place? If you have a XVBA IMPLEMENTATION you can use it to accelerate your video. If you have a SPECIFICATION you can use it to make the IMPLEMENTATION. What we have right now is the DOCUMENTATION thus it should be possible to make a native linux implementation without any magic. The only painful part is the loading of a windows dll that implements the same documentation to the video card (the DXVA to UVD driver library which implements DXVA in with the UVD documentation) but i don't see how you need a miracle there... just using the lib should be enough to have a hardware accelerated DXVA implementation.

Now that i think of it a bit more, making a DXVA implementation isn't needed (right?) since that would mean a software based DXVA implementation..?? Or i'm messing things up here..? Anyway, windows has a dxva2.dll in it's system32 folder which can also be found here: http://www.search-dll.com/dll-files/...dxva2.dll.html (i do have a newer one in my system32 folder.. nearly double the size and version: "6.1.7600.16385"

[jrch2k8]

Hi!

My 2 cents If a person is not technical enough, don't know architecture of drivers and near future plans of driver vendor, it might not be a good idea to suggest do this and that in technical form...
I'm for the working stuff, I don't care whether it's FOSS or not, I spent money on card so I expect it to work with all features working properly.
To be honest I would be for closed source as certain features would be available only to closed source for different reasons, but as already speculated here, AMD just doesn't have enough manpower to correct drivers and priorities are not mainstream consumers, but proffessionals... This is rather sad, however speaking for me, I'm better off with AMD (catalyst) in laptop than nVidia due to PM features like hibernate and suspend, which flawlessy worked on AMD but were failing on nVidia.
I would really like to see XVBA or whatver which is on par with nVidia... I'm having nVidia only in my HTPC just because AMD does not have anything to offer for Linux, I have couple of AMD's but for Desktop / Mobile...
But still, that's priorities, I personally think that if some decision maker in AMD will say we need decent video acceleration, it would happen and not at very high cost, but then again, Linux share is veeeeeeeeeeeery small, so this is how it is, struggling to get anything done But again, nVidia has done VDPAU very nicely, that's why I spent bucks on it

well never is bad to post what you think, you never know when so part of those ideas that could sound crazy could be great to use it in another way or project

about commertial or OSS i prefer OSS just for the liberty of be able of do whatever the hell i want with my gpu (like try a different way to decode/encode video using my gpu or a study process, etc) but im a power user so i mostly enjoy this kind of stuff. for the average joe it should choose the one that fit him the best, but probably in the long run OSS would be a much better option that fglrx for most users due the fact it can get tightly integrated into every part of the OS and accelerate a numberless technologies that probably fglrx will take years to adopt(see Xserver support, aiglx, xvba lol, even openGL fails like crazy in fglrx{mostly massive slowdowns in some relases or heavy render bug in some others})

[monraaf]

What we have right now is the DOCUMENTATION thus it should be possible to make a native linux implementation without any magic.

Huh? Please give me a link to UVD docs

The only painful part is the loading of a windows dll that implements the same documentation to the video card (the DXVA to UVD driver library which implements DXVA in with the UVD documentation) but i don't see how you need a miracle there... just using the lib should be enough to have a hardware accelerated DXVA implementation.

LOL, do you seriously expect this to work? UVD is not just some easy replaceable DLL or so file. There's UVD code sprinkled all over the various driver parts, in the fglrx DDX, in the kernel blob, and I expect the situation to be the same in windows.

Not to mention that the idea of using Wine for video playback in Linux is just an atrocity, ugh!

[gbeauche]

BTW, UVD use shaders too

UVD is a separate block. Shaders are only used at the video presentation stage for postprocessing. e.g. colorspace conversion, ProcAmp adjustments, deinterlacing, denoising, HQ upscaling, etc. UVD is a fixed pipeline, it's only a pure decoder.

BTW, this reminds me something, when will we see a UVE? aka Universal Video Encoder? I see ATI as the licensee for an H.264 encoder IP core...

[markg85]

Huh? Please give me a link to UVD docs

I was talking about the DXVA docs.. and i posted a link to that a few posts back.

[jrch2k8]

I can be wrong but i read somewhere that it's _not_ using shaders.. why else have a separate chip for decoding if you use the GPU chip anyway?

And i still think that either this path or reverse engineering is going to be the fastest way to get the full power of UVD in the near future. Remember that just 2 years ago someone here on phoronix made a native "directx on linux" topic which was somewhat seen as not gonna happen anytime soon: http://www.phoronix.com/forums/showthread.php?t=12287 and now 2 years later we have it.

As for your double miracle. Why would that be needed in the first place? If you have a XVBA IMPLEMENTATION you can use it to accelerate your video. If you have a SPECIFICATION you can use it to make the IMPLEMENTATION. What we have right now is the DOCUMENTATION thus it should be possible to make a native linux implementation without any magic. The only painful part is the loading of a windows dll that implements the same documentation to the video card (the DXVA to UVD driver library which implements DXVA in with the UVD documentation) but i don't see how you need a miracle there... just using the lib should be enough to have a hardware accelerated DXVA implementation.

Now that i think of it a bit more, making a DXVA implementation isn't needed (right?) since that would mean a software based DXVA implementation..?? Or i'm messing things up here..? Anyway, windows has a dxva2.dll in it's system32 folder which can also be found here: http://www.search-dll.com/dll-files/...dxva2.dll.html (i do have a newer one in my system32 folder.. nearly double the size and version: "6.1.7600.16385"

1.) 2 years ago was completely different, since every driver needed to create a driver using reverse enginnered asm code for each gpu, making it extremely annoying cuz you will need 10 d3d implementations for 10 gpu's. gallium make it partially possible(D3D stracker is not fully accelerated yet{as far as i checked the tracker}) because allows you to write only the gpu internal asm needed to make TGSI work, so TGSI practically speaking got converted into an gpu agnostic asm substitute that make this kind of low level work way easier and mantainable.

2.) XVBA is 100% useless in the OSS driver, the codepaths are so extremely different that is useless try to hook it up, on the fglrx side is faster just wait to get xvba to work decently with va-api. that why we need to reverse engenieer the UVD asm path. remember that XVBA uses specific code path inside the closed fglrx code and those paths internally generate some asm specifics calls that call UVD, so is not like xvba contains everything and you just need to dlopen it

3.) there is no such thing as UVD documentation at all, amd released only the 3D part of the asics for certain generation of hardware, in fact we dont have OpenCL/Stream documentation either. btw AMD was careful enough to don't release even a clue of how to acess the UVD part of the asics

4.) you are missing the fact that DXVA dll's are not self contained definitions but more like skeletons that fill in your specific VA DXVA implementation plugin for your gpu, so windows can expose a simple API for developers to work but once you call X function in libDXVA that call get relayed to another library (the amd uvd library in this case) that have the actual GPU asm to execute that specific call X, the problem of using any of those libraries is that in the end the uvd DXVA library calls a set of extremely specific code paths only present in catalyst windows not xvba since by definition both expose different symbol names(maybe internally they do the same thing but you will have to add a symbols translation library in the middle to begin with).

if you can solve that specific symbol disparity problem, you have to find some magic way to translate the cryptic catalyst code path to TGSI (that is the miracle!) from wine, then to render you will need a state tracker exposing all the TGSI equivalent of the DXVA UVD code paths, a library libdxva2_wine.so that contain all the hook up to the state tracker and then a set another library to glue the actual libdxva api call from the windows apps(in this case linux would be discarted since the performance hit would be nasty) and probably patch wine and vlc windows to proper handle the texture flow through opengl or native direct3d if get accelerated in that gpu to the screen and one hell lot of time debugging

[V!NCENT]

We have a thousand times or so already. It's simple; nobody plays a movie and does anything else besides OpenGL desktop effects max.

All shader cards are powerfull enough to play this on shaders with OpenCL and so that's all we need and it's FLOSS and doable.

What's the problem then? There's not even a fully working OpenGL 2.1 State Tracker. So what should be focussed on first?; core graphics functionality.

Unless you want to make a State Tracker yourself, which targets the shader language directly anyway. So why OpenCL? Because then all the drivers, including proprietary, will work with the playback software.

End of fscking story.

[markg85]

Oke, perhaps dxva to vaapi is not the optimal path and perhaps not even possible but "if" it "could" work then it would be the fastest way to get all UVD's features on linux.

For now: ATI, please provide UVD documentation!

Note: above is said that there is no clue on how to use UVD, but that's not true anymore. The xvba library is doing it so with some reverse engineering you can probably discover how to make contact wuth the UVD chip?