Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 38

Thread: Mesa Mega Driver Patches Published

  1. #21
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote 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.

  2. #22
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    136

    Default

    Quote 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.

  3. #23
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    136

    Default

    Quote 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.

  4. #24
    Join Date
    Jul 2010
    Posts
    490

    Default

    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).

  5. #25
    Join Date
    Dec 2011
    Posts
    2,048

    Default 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?

  6. #26
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    136

    Default

    Quote 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.

  7. #27
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    Quote 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 at 05:11 AM.

  8. #28
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote 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.

  9. #29
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    511

    Default

    Quote 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.

  10. #30
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    934

    Default

    Honestly, how can someone really care about disk space in the 2013? It shouldn't even be considered as an advantage in my opinion

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •