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?
Announcement
Collapse
No announcement yet.
Mesa Mega Driver Patches Published
Collapse
X
-
Originally posted by uid313 View PostBig 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.
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
-
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
-
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.
Comment
-
Originally posted by mendieta View PostI 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.
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
-
Originally posted by not.sure View PostDoesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?
Comment
-
Originally posted by marek View PostThere 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
-
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
Comment