Page 1 of 3 123 LastLast
Results 1 to 10 of 38

Thread: Mesa Mega Driver Patches Published

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,429

    Default Mesa Mega Driver Patches Published

    Phoronix: Mesa Mega Driver Patches Published

    Eric Anholt of Intel has published his initial patches for implementing the "mega drivers" concept within Mesa...

    http://www.phoronix.com/vr.php?view=MTQ3Mzc

  2. #2
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    392

    Default

    Doesn't seem to make too much sense from a technical point of view. Anybody has an idea about the politics side?

  3. #3
    Join Date
    Jan 2011
    Posts
    1,287

    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?
    On politics, if forced (i.e., if it's not just a build time option) means you need to rebuild the whole mesa to use any driver that is not upstream.
    On tech, I think it has some security/stability relevance, since they don't need to make all the symbols public.

  4. #4
    Join Date
    Oct 2008
    Posts
    2,911

    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?
    Hiding all the symbols is a huge win on the technical side - although possibly it could be done in another way, i'm not sure about that.

  5. #5
    Join Date
    Jul 2013
    Posts
    223

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

    and is noting about a 2.61% performance increase
    It reduces some CPU load due to moving some calls to internal instead of across linked libraries. Also, once Gallium gets added to the mix, it will create a single binary that's about 1/6 the size of the current Mesa package (if you include ALL drivers, like some distros do)

  6. #6
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,102

    Default

    Michael, any chances on benchmarking this driver against the ones it merges?

  7. #7
    Join Date
    Nov 2008
    Posts
    142

    Default I hope this stays optional.

    Mega binaries are not a good practice and the performance benefits seem negligible. Modularization is harder but almost always the better approach.

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

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

    Default

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

  10. #10
    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?

Posting Permissions

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