Mesa Mega Driver Patches Published

[wargames]

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?

[Sonadow]

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

Actually Microsoft appears to like the idea of mega packages. Case in point: a 'ps aux' on Linux lists hundreds (somethings even thousands) of background processes while get-process in Powershell usually returns only 30 - 50 running background EXEs.

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.

[libv]

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.

[Mickabouille]

I wonder how this can save space compared to the current situation.
Instead of having only one driver installed (the one for you hardware), you have only one driver with all the code for the others inside.
It seems to loose disk space instead...

[mendieta]

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.

[libv]

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.

[marek]

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.

[curaga]

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

[libv]

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?

[Daktyl198]

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.