Announcement

Collapse
No announcement yet.

Mesa Mega Driver Patches Published

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

  • Mesa Mega Driver Patches Published

    Phoronix: Mesa Mega Driver Patches Published

    Eric Anholt of Intel has published his initial patches for implementing the "mega drivers" concept within Mesa...

    http://www.phoronix.com/vr.php?view=MTQ3Mzc

  • #2
    Doesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?

    Comment


    • #3
      Originally posted by not.sure View Post
      Doesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?
      On politics, if forced (i.e., if it's not just a build time option) means you need to rebuild the whole mesa to use any driver that is not upstream.
      On tech, I think it has some security/stability relevance, since they don't need to make all the symbols public.

      Comment


      • #4
        Originally posted by not.sure View Post
        Doesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?
        Hiding all the symbols is a huge win on the technical side - although possibly it could be done in another way, i'm not sure about that.

        Comment


        • #5
          Originally posted by not.sure View Post
          Doesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?
          um...

          and is noting about a 2.61% performance increase
          It reduces some CPU load due to moving some calls to internal instead of across linked libraries. Also, once Gallium gets added to the mix, it will create a single binary that's about 1/6 the size of the current Mesa package (if you include ALL drivers, like some distros do)

          Comment


          • #6
            Michael, any chances on benchmarking this driver against the ones it merges?

            Comment


            • #7
              I hope this stays optional.

              Mega binaries are not a good practice and the performance benefits seem negligible. Modularization is harder but almost always the better approach.

              Comment


              • #8
                I really hope this is a configurable option

                Originally posted by phoronix View Post
                Eric Anholt of Intel has published his initial patches for implementing the "mega drivers" concept within Mesa...
                This is exactly the kind of thing I don't need when trying to perform a "git bisect".

                Comment


                • #9
                  Is this even a good idea?

                  Big monolithic things are usually bad.

                  Isn't there any alternative ways do accomplish similar benefits without the drawbacks?

                  I don't think anyone else (Apple or Microsoft, etc) would use this solution.

                  Comment


                  • #10
                    I know the much easier and future proof approach.
                    Gallium.

                    Comment


                    • #11
                      IMHO I don't think this is a good idea. Are they really worried about the public symbols? Just be consistent, and prefix all the functions with the same string. Is not there some kind of "moderator" like in the linux kernel?

                      Comment


                      • #12
                        Originally posted by uid313 View Post
                        Big monolithic things are usually bad.

                        Isn't there any alternative ways do accomplish similar benefits without the drawbacks?

                        I don't think anyone else (Apple or Microsoft, etc) would use this solution.
                        Actually Microsoft appears to like the idea of mega packages. Case in point: a 'ps aux' on Linux lists hundreds (somethings even thousands) of background processes while get-process in Powershell usually returns only 30 - 50 running background EXEs.

                        Given that pattern, it's not impossible to believe that Microsoft might pursue mega drivers some time in the future as part of its next strategy for Windows.

                        Comment


                        • #13
                          Smells like utter laziness on part of cleaning up the symbols and on fixing up their visibility. It's a mental and technological step back, that when set in stone, will come to bite us all in the ass soon.

                          Getting a 2.61% advantage (+/- 1.16) is enough to warrant this as a build time option for those seeking those extra few % for their specific installation, but not near enough to even dare to try to portray this as The-One-And-Only-Solution because it solves nothing that doesn't have a much better solution.

                          Comment


                          • #14
                            I wonder how this can save space compared to the current situation.
                            Instead of having only one driver installed (the one for you hardware), you have only one driver with all the code for the others inside.
                            It seems to loose disk space instead...

                            Comment


                            • #15
                              I agree with the general sentiment. Remember when X was modularized? That was perceived as a good thing, not a bad thing. I am not into the details of Mesa, but I would think that it should be possible to define an API in Mesa proper, and have individual drivers export/implement the symbols defined in that API.
                              Last edited by mendieta; 10-01-2013, 08:39 AM. Reason: typo

                              Comment

                              Working...
                              X