Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 38

Thread: Mesa Mega Driver Patches Published

  1. #11
    Join Date
    Sep 2012
    Posts
    252

    Default

    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?

  2. #12
    Join Date
    Jun 2009
    Posts
    504

    Default

    Quote Originally Posted by uid313 View Post
    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.

  3. #13
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    302

    Default

    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.

  4. #14
    Join Date
    Mar 2009
    Posts
    47

    Default

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

  5. #15
    Join Date
    Apr 2009
    Posts
    491

    Default

    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.
    Last edited by mendieta; 10-01-2013 at 08:39 AM. Reason: typo

  6. #16
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    302

    Default

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

  7. #17
    Join Date
    Jan 2009
    Posts
    599

    Default

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

  8. #18
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,734

    Default

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

  9. #19
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    302

    Default

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

  10. #20
    Join Date
    Jul 2013
    Posts
    223

    Default

    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.

Posting Permissions

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