Announcement

Collapse
No announcement yet.

ATI, please release an Open UVD API

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ATI, please release an Open UVD API

    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 ^_^

  • #2
    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!

    Comment


    • #3
      Originally posted by droidhacker View Post
      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.

      Comment


      • #4
        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 ?

        Comment


        • #5
          Originally posted by bridgman View Post
          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.

          Comment


          • #6
            Originally posted by markg85 View Post
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by markg85 View Post
                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 ^_^
                1.) UVD is not such a big deal, except a semi working DRM mess that cannot be released due the mounstrous amount DRM code from third parties that AMD cannot release to opensource (i bet that the RIAA and combo would drop dead if that code is released, jajajaja ill pay to see that XD), so forget UVD, it just wont ever happen (and i have my doubts if xvba+va will be usable for the average joe in the next 5 years {i mean perfectly stable like VDPAU, i know it kinda work somehow in some driver on some cards when the moon phase is right and the astros are aligned})

                2. you are lucky XD that gallium have advanced this far cuz now 2 another phoronix readers and me are continuing the previous work of younes manton to decode video on the GPU using the assembly like TGSI language, so far is almost decoding mpeg2 properly(i still need some help with TGSI {btw Marek reread my post i posted new questions XD } )and since younes manton figure out a way to make the MC algorithm to render in real time in a geforce 6200 and my idct code can be reolved using only sums and dot products which are the most time consuming passes, im pretty sure you wont notice much difference against uvd using low level gpu. ofc the project is still at a very young stage but once we get familiar with TGSI it should advance faster(TGSI is quite dark to get it working cuz there is almost no documentation but marek explain quite nice )

                mmm even in a bit more time in the future we are considering include encoding acceleration but first the first right? and the good thing about using TGSI(probably opengl and opencl too later) is we can be codec agnostic and in theory even compress audio in the gpu(need more studie to be sure in practice ofc)

                Comment


                • #9
                  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

                  Comment


                  • #10
                    Originally posted by markg85 View Post
                    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)

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        Originally posted by markg85 View Post
                        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.

                        Comment


                        • #13
                          Originally posted by jrch2k8 View Post
                          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"

                          Comment


                          • #14
                            Originally posted by Kirurgs View Post
                            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})

                            Comment


                            • #15
                              Originally posted by markg85 View Post
                              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!

                              Comment

                              Working...
                              X