Originally posted by libv
View Post
Announcement
Collapse
No announcement yet.
Mesa Mega Driver Patches Published
Collapse
X
-
Originally posted by brosis View PostI know the much easier and future proof approach.
Gallium.
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
-
Originally posted by marek View PostDo 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.Free Software Developer .:. Mesa and Xorg
Opinions expressed in these forum posts are my own.
Comment
-
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
-
Originally posted by uid313 View PostDoes 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?
No idea about OS X.Free Software Developer .:. Mesa and Xorg
Opinions expressed in these forum posts are my own.
Comment
-
Originally posted by marek View PostDo 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.
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
-
Originally posted by libv View Postlibdricore 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.
Personally I'm mainly interested in link-time optimizations. I don't care much about the space.
Comment
-
Originally posted by marek View PostYou 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
Comment