Announcement

Collapse
No announcement yet.

Mesa Mega Driver Patches Published

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

  • #16
    Originally posted by mendieta View Post
    I agree with the general sentiment. Remeber 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.
    It's surprisingly easy to do so as well. My upcoming lima mesa driver will only run against an especially hacked tree. The (few) actual codechanges i need are to support my driver using the binary compiler (as opposed to the glsl compiler, for which support will be added as a next step). Building (and of course running) the driver externally only requires build system changes.

    This gives me a really short turn-around time for testing new driver code, which is mighty important on a 1GHz Cortex-A8. Linux-sunxi.org will host "fixed" packages for the common distributions, and i am sure that all mali based SoC projects will soon refer to these packages, just like they all now use my packaging of the binary driver.

    Comment


    • #17
      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?
      There is no politics. It saves a lot of disk space and improves performance by a few percents, and there is more performance to gain from link-time optimizations.

      Comment


      • #18
        From a cursory look, it doesn't even break the old (removed) classic drivers.

        Comment


        • #19
          Originally posted by marek View Post
          There is no politics. It saves a lot of disk space and improves performance by a few percents, and there is more performance to gain from link-time optimizations.
          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?

          Comment


          • #20
            To be honest, this is actually the exact opposite of what I wanted from Mesa. I wanted it to be SO modularized, that even the kernel bridges are external *shrug*.

            Like, move all of the kernel-specific code (Linux vs BSD, etc) into mesabridge-linux, mesabridge-bsd, whatever and have it interact with "Mesa Core" via an API... And then of course, have the drivers separate as well and have them interact via a proper API...

            But I'm not a "real" developer and my ideas are usually stupid, so anybody feel free to tell me why that would be a bad idea.

            Comment


            • #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; 10-02-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