Announcement

Collapse
No announcement yet.

Mesa Mega Driver Patches Published

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

  • #21
    Originally posted by libv View Post
    How does it save diskspace compared to building with shared libraries? By removing the dri/common copies in each driver? Surely that can be generally applied without having to throw everything into one big blob?
    Do you mean like libdricore? I think libdricore was a step in the wrong direction. Mesa has only private driver interfaces and private interfaces should NEVER EVER be exported. The "megadrivers" solution is the only thing that makes sense.

    Comment


    • #22
      Originally posted by brosis View Post
      I know the much easier and future proof approach.
      Gallium.
      I love how people think Gallium is some magical cure all for every problem. If you look closer, you'll discover that the megadrivers idea improves all drivers, including all the Gallium drivers. Classic vs. Gallium is irrelevant here.

      All drivers share the same core Mesa code. In the old days, we used to build a separate copy of that core into each driver. This was easy, and made it possible to optimize the hardware-specific code and the common core together, which improved performance. There were no symbol visibility problems. The major downside is it meant shipping 15 different copies of this shared core (which is around 3.3MB), resulting in some wasted disk space.

      In 2011, Canonical contributed patches to build the core Mesa code into a shared library, libdricore, which all drivers could link against. This saved around 50MB of disk space, which was (at the time) important for install CD media. Unfortunately, the way it was architected, we had to expose every function in core Mesa so that drivers could use them. This polluted the namespace really badly - we shipped symbols like hash_table_insert, visit_list_elements, and so on. If an application had their own functions with the same names, they might accidentally get ours and most likely crash. It also meant that you had to keep libdricore.so and xyz_dri.so in sync - if you accidentally got a mismatched version, everything would crash horribly. Due to libtool's insane handling of rpath, this was actually really common, at least for developers.

      Many of us would gladly go back to building everything together, as we did in the old days, but apparently disk space is still a concern for Fedora and Ubuntu, which offer live images that fit on 1GB USB flash drives. So, enter Megadrivers, which basically says "let's build all the drivers together in one big megadriver_dri.so". It accomplishes the disk space savings of libdricore without the symbol versioning problem or the performance loss from splitting the core and driver code apart.

      My personal opinion is that this is a lot of work to save 50MB of space. The smallest USB drive I have is 4GB, and most stores don't even carry 1GB drives, so I have a really hard time believing this is a meaningful problem to solve. I also don't see other open source projects worrying about disk space. That said, I still believe megadrivers is much better than the current libdricore-based system we have now, so while I think some of the motivations are absurd, I'm still in favor of doing it.
      Free Software Developer .:. Mesa and Xorg
      Opinions expressed in these forum posts are my own.

      Comment


      • #23
        Originally posted by marek View Post
        Do you mean like libdricore? I think libdricore was a step in the wrong direction. Mesa has only private driver interfaces and private interfaces should NEVER EVER be exported. The "megadrivers" solution is the only thing that makes sense.
        I agree with Marek 100%. Keeping the core Mesa<->Driver interfaces private is extremely useful. When I added performance counter support the other week, I had to extend the driver interface, adding code in both halves. When implementing ARB_transform_feedback2 in i965, I also added some driver hooks to make life a lot easier, updating code in both places. Most new development involves extending both halves, and it's much less complicated to keep them in sync and not worry about ABI incompatibility.
        Free Software Developer .:. Mesa and Xorg
        Opinions expressed in these forum posts are my own.

        Comment


        • #24
          Don't want to interfere with the discussion, but if the distros are so desperate to save 50MB there, why not use some delta compression (locate/separate functions in driver binaries, look for matching blocks, I am sure there will be quite a few given the amount of common code, even with LTO).

          Comment


          • #25
            Other systems?

            Does other operating systems have this same problem with dricore, private interfaces that exposed etc?

            Does Windows or OS X have this problem?
            If so, how do they deal with this problem?

            Comment


            • #26
              Originally posted by uid313 View Post
              Does other operating systems have this same problem with dricore, private interfaces that exposed etc?

              Does Windows or OS X have this problem?
              If so, how do they deal with this problem?
              On Windows users have to manually download a 135MB (AMD) or 188MB (nVidia) driver installer which only works with one vendor's graphics cards. In other words, they don't deal with this at all. But they also don't ship bootable live USB images that work out of the box on every machine under the sun.

              No idea about OS X.
              Free Software Developer .:. Mesa and Xorg
              Opinions expressed in these forum posts are my own.

              Comment


              • #27
                Originally posted by marek View Post
                Do you mean like libdricore? I think libdricore was a step in the wrong direction. Mesa has only private driver interfaces and private interfaces should NEVER EVER be exported. The "megadrivers" solution is the only thing that makes sense.
                libdricore was the proper solution. Nobody however counted on guys like you being _that_ utterly lazy, and that unwilling to make mesa development come to the 21st century.

                But hah. So megadrivers _only_ saves space in comparison to the former huge-drivers... I'm sorry, but that's just laughable.

                Is the faster load times also measured against the situation from before libdricore, or has that been measured against libdricore? I smell a whole lot of intellectual dishonesty with this.

                How are there "private" "driver" interfaces. That's called APIs, and can be rather readily turned into a moving public APIs, all it takes is a mindset change.
                Last edited by libv; 02 October 2013, 05:11 AM.

                Comment


                • #28
                  Originally posted by libv View Post
                  libdricore was the proper solution. Nobody however counted on guys like you being _that_ utterly lazy, and that unwilling to make mesa development come to the 21st century.

                  But hah. So megadrivers _only_ saves space in comparison to the former huge-drivers... I'm sorry, but that's just laughable.

                  Is the faster load times also measured against the situation from before libdricore, or has that been measured against libdricore? I smell a whole lot of intellectual dishonesty with this.

                  How are there "private" "driver" interfaces. That's called APIs, and can be rather readily turned into a moving public APIs, all it takes is a mindset change.
                  You are insane. It's not the 21st century you're proposing. You want to take Mesa back to the stone age. The current way of managing the project is the only way to sustain progress. If you don't like it, make your own fork, or don't use Mesa at all.

                  Personally I'm mainly interested in link-time optimizations. I don't care much about the space.

                  Comment


                  • #29
                    Originally posted by marek View Post
                    You are insane. It's not the 21st century you're proposing. You want to take Mesa back to the stone age. The current way of managing the project is the only way to sustain progress. If you don't like it, make your own fork, or don't use Mesa at all.

                    Personally I'm mainly interested in link-time optimizations. I don't care much about the space.
                    As a recent Golang-er, I can tell...shared objects suck! Code/data ratio now enables us to ship bigger executables, and the kernel is taking care of consolidating the same parts/swapping out unused parts.

                    Comment


                    • #30
                      Honestly, how can someone really care about disk space in the 2013? It shouldn't even be considered as an advantage in my opinion
                      ## VGA ##
                      AMD: X1950XTX, HD3870, HD5870
                      Intel: GMA45, HD3000 (Core i5 2500K)

                      Comment

                      Working...
                      X