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; 05 February 2009, 10:04 AM.
              Test signature

              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 :


                  "

                  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; 05 February 2009, 01: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

                    Working...
                    X