Announcement

Collapse
No announcement yet.

3D Optimizations and UVD... AMD_hal.so!

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

  • 3D Optimizations and UVD... AMD_hal.so!

    HI! After thinking a lot about this (and also chating with cxo on the irc channel) I decided to post...

    The idea is to have a binary library on top of the opensource driver, which would have all the special top secret features into it, developed by AMD/Ati.

    This binary library would be completely optional but it would benefit both, AMD/Ati and also the opensource community. This would speed up the driver development (and indirectly the implementation of GEM/TTM, Gallium, DRI2) giving us a stable driver that has compatibility with every distro and AMD/Ati would be able to create this library on top it and bring advanced features to every user.

    This features would include OpenGL 2D/3D optimization routines for workstation users (mainly FireGL cards), also UVD Accel for normal users and maybe a fast implementation of OpenCL on top of Gallium.

    I have also asked Bridgman about this on the "Ask ATI" dev thread .

    Source of the idea: http://en.wikipedia.org/wiki/Intel_GMA#intel_hal.so

    Well, thanks for your attention, Phoronix rocks!

  • #2
    Oh please no..

    What "special top secret features" ? Of the hardware or of the software ?

    Originally posted by rainbyte View Post
    This would speed up the driver development (and indirectly the implementation of GEM/TTM, Gallium, DRI2) giving us a stable driver that has compatibility with every distro and AMD/Ati would be able to create this library on top it and bring advanced features to every user.

    This features would include OpenGL 2D/3D optimization routines for workstation users (mainly FireGL cards), also UVD Accel for normal users and maybe a fast implementation of OpenCL on top of Gallium.
    All of this is already coming with the open source drivers, and why do you assume that a closed blob would be necessarily faster ?

    Comment


    • #3
      Originally posted by Azultra View Post
      Oh please no..

      What "special top secret features" ? Of the hardware or of the software ?


      All of this is already coming with the open source drivers, and why do you assume that a closed blob would be necessarily faster ?
      We need a CS Module for the UVD/UVD2 and IP Stuff. And as an Optional Component its ok. If you want it Activate it and if not dont use it.


      But Currently we can only choose between a feature rich fglrx with some Problems or a Free Driver with only very Basic stuff.

      Comment


      • #4
        Hi! As Bridgman said in other posts, there are some parts of documentation/code that they can't opensource because of legal/competitive issues... The library can solve that problem for the people who need those features.

        But that won't be the important part for the community, the benefit for us would be to put all the effort in the opensource drivers, because AMD/Ati would help to implement all the features which don't have legal/competitive problems.

        I'm really interested in speed up the development, actually the efforts are so divided that we will get optimized drivers in a lot of time. In the other way, using the library, we can use this features in the short term and replace them with time, so the binary library will be smaller.

        I think that people need to use something that works well, and as Nille said, currently some features are only in determined drivers, but it would be ok to have the library on top of an opensource (very stable) driver.

        Comment


        • #5
          There's no point investing or working in something that by definition has no future.

          Comment


          • #6
            Originally posted by Nille View Post
            We need a CS Module for the UVD/UVD2 and IP Stuff. And as an Optional Component its ok.
            What's "IP Stuff" ? Stands for "Intellectual Property Stuff" ? Could you be more specific ?
            Bridgman said somewhere that UVD was going to be documented.

            Originally posted by Nille View Post
            If you want it Activate it and if not dont use it.
            Of course! Freedom!
            If you want proprietary drivers Activate it and if not dont use it.
            So what's the point with releasing all these specs ?

            Originally posted by Nille View Post
            But Currently we can only choose between a feature rich fglrx with some Problems or a Free Driver with only very Basic stuff.
            You wrote Currently with a capital "C", and you may be right about that.

            Comment


            • #7
              There are three main problems with this approach :

              1. For the 3D driver, the performance isn't just a function of "a secret module" (say, the shader compiler) but from the integration of the entire stack including big chunks of the kernel driver (memory management and command submission). If all those bits aren't used together then the performance is going to drop pretty fast.

              2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet. Until the "what does Linux want to become ?" discussions settle down (if ever) I don't think it makes sense to take the driver in a direction (closed source 3D mixed with open source modesetting) where we would have to completely discard in order to deliver a secure legal BD solution.

              3. For UVD, having a small binary module in an otherwise open source driver doesn't really protect the code at all; it's just too easy to reverse-engineer a closed source module if everything around it is open source. I believe Intel dropped the idea themselves, at least that's the impressino I get from the various articles mentioning it.

              For clarity, issue #1 is a big enough problem before even considering #2 and #3.

              I think the combination of opening up the install/packaging scripts (on phorogit) plus making the drivers more "chatty" so that problems can be diagnosed and fixed more quickly will go a long way to making the driver more tolerant of system-to-system variations.
              Last edited by bridgman; 02-05-2009, 09:04 AM.

              Comment


              • #8
                Well, after reading your post I arrive to a conclusion...

                1- As I see, it would be at least very difficult to implement this kind of approach in the opensource driver in order to add 3D optimizations because of the integration between the opensource and the binary parts. I am not a xorg developer but what about supporting only certain versions of the opensource stack, you know something like "AMD Performance Libs version xxx are compatible with Radeon/Mesa version xxx" so they will stay syncronized.

                2- About BD and DRM, I think that they aren't (and maybe won't be) used in Linux... The normal user would be playing home-made h264 or xvid content or at least downloaded from internet.

                3- UVD critical information, that would be a problem too, if it is difficult to protect it with this approach we would fall in a legal issue. Maybe there is some way to turn this around or maybe not, I'm not sure.

                This has left me a doubt... Would it mean that libva binary approach is insecure too? Will this slow down the development of libva api?

                Well, thanks for all your attention again...

                Comment


                • #9
                  Originally posted by Azultra View Post
                  What's "IP Stuff" ? Stands for "Intellectual Property Stuff" ? Could you be more specific ?

                  Bridgman said somewhere that UVD was going to be documented.

                  ....
                  #80 http://www.phoronix.com/forums/showp...6&postcount=80
                  Bridgman said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


                  popper said:"thats a shame, we are looking at months at the very least then!"

                  Bridgeman said:"I think the attraction of the [NV cuda] library is that it makes it easy to retrieve the decoded frame, while most of the decoder implementations supplied by HW vendors tend to only output to the screen simply because that was the main requirement.

                  We make a similar capability available to ISVs :

                  http://www.cyberlink.com/eng/press_room/view_1756.html
                  "

                  popper said:"yep,that about covers it for basic needs it appears, your average dev and indeed Pro coders such as BetaBoy and the CoreAVC coders dont really need that much help once they have the right library and docs access it seems, BetaBoy said he wanted to support ATI UVD in CoreAVC and related apps but you dont give them or the open SW coders access to the ATI UVD."

                  Quote: 01-08-2009, 07:48 PM
                  Originally Posted by popper
                  thats a shame, we are looking at months at the very least then!
                  Bridgeman said:"For open source, yes, but I expect fglrx will have it sooner."

                  until those UVD header and UVD docs become available, IF ever, we are going nowere, but i assume and really hope Bridgman is hard on the case regarding that vital UVD review, and doing what he can to push it, and its related documentation to the top of the things to get done by someone? inside AMD/ATI ASAP , would that someone be you Bridgeman as the key person?
                  Last edited by popper; 02-05-2009, 12:20 PM.

                  Comment


                  • #10
                    So the implementation of UVD will be slow, we don't have even the specs...

                    Also we aren't sure about which of them are going to be reviewed, because there is UVD (R600 chips) and UVD2 too (R700 chips, more posibilities to be opened)...

                    I have a Radeon HD2400 (rv610) and I'm not sure if the opensource driver would support UVD on it.

                    Comment


                    • #11
                      apparently the actually getting to, and perhaps through the investigation/review part will be slow, (at least Months)unless somone? inside AMD/ATI decides to push it through as a "need it now to catch up with the other companies offerings" to 3rd party video devs/apps type thing.

                      but the actual UVD ASIC if and when its header/docs/code arrives, if ever.... depends on the internal review after all, will be as fast as the other ASIC offerings ,perhaps faster at HW assisted decoding etc.

                      and its been said/implyed the UVD includes a lot more stuff inside than the NV ASIC etc has, but we cant know for sure, as we dont have that documentation/sample code showing it off TODAY and noone inside AMD/ATI has bothered to write it's capability up and released that information....
                      Last edited by popper; 02-05-2009, 01:15 PM.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        For UVD, having a small binary module in an otherwise open source driver doesn't really protect the code at all; it's just too easy to reverse-engineer a closed source module if everything around it is open source.
                        Does this matter? If someone reverse engineers it, it's not AMD's fault. Publishing reverse engineered specs is illegal. AMD is not the police.

                        And I don't really get the "reverse engineering" paranoia. Who needs to actually do it? I can copy BD discs easily anyway. This whole UVD case is useless. It's a PHAIL in big fat letters; it doesn't protect s***t :P You're trying to keep something a secret that no one even gives a flying fsck about how it works because it's circumvented anyway :P

                        Comment


                        • #13
                          Yeah, that would be nice... but it doesn't work that way. Whether the information gets published illegally or not, we still get hit by the consequences.

                          Besides, pretty much *everything* is legal *somewhere* in the world, which wasn't such a problem back when most IP involved which local weeds to grind up into medicine and the Internet relied on ships for routing between continents

                          One of the hardest parts of any open source program is building and maintaining a model of the reverse-engineering activities which are likely to be enabled (or simplified to the point where someone bothers) by the information you release. All of the risk-related decisions have to be made based on the implications of both released and "likely to be reverse-engineered as a result" information.
                          Last edited by bridgman; 02-05-2009, 02:44 PM.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution
                            Yes, a closed-source player running on a closed-source API framework talking to a closed-source hardware driver running on a closed-source kernel--in other words, Windows Vista (or OS X)

                            My understanding is that the "robustness" requirements for the various hi-def DRM standards pretty much categorically exclude anything running on top of a GPLed kernel--and that this was no accident, since Microsoft was heavily involved in crafting these industry standards.

                            The future of BD and other hi-def support on Linux is most likely going to be the same as the present state of DVD support: software developed in civilized countries without ridiculous paracopyright laws, and distributed in the US and EU on a "don't ask, don't tell" basis.

                            And hey, there's a possibility that when some company in Israel comes out with a killer BD-playing Linux netbook, and it can't be sold in the US or EU because of the DMCA (or, more importantly, no US/EU company can build anything to compete with it) the lawmakers will take a good, hard look at just whom those laws are actually "protecting".

                            Comment


                            • #15
                              It's the content creators who want DRM, not Microsoft. Microsoft simply allows that content to be supported in Windows by making up a standard for it. Hollywood creates the stuff, they want DRM, the consumers want the content, Microsoft allows them to have it.

                              Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.

                              Comment

                              Working...
                              X