Results 1 to 10 of 10

Thread: Mesa Can Now Be Smaller, Build Faster

  1. #1
    Join Date
    Jan 2007
    Posts
    15,387

    Default Mesa Can Now Be Smaller, Build Faster

    Phoronix: Mesa Can Now Be Smaller, Build Faster

    As something of value to more users than Mesa receiving EXT_texture_compression_RGTC support is that the shared DRI core patch has been merged. This results in a significantly smaller package size for Mesa (circa 30MB savings) and results in Mesa building about 13% faster...

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

  2. #2
    Join Date
    Sep 2010
    Posts
    147

    Default Wrong person

    With this shared DRI core patch by Intel's Eric Anholt, a shared DRI core library is created instead, which are then dynamically linked to by the drivers.
    That's very wrong - the patch is not by Eric. It's by Christopher James Halse Rogers from Canonical. Eric just committed it to Mesa master.

  3. #3
    Join Date
    Sep 2008
    Posts
    989

    Default

    A Mesa build is ridiculously fast on a commodity Core i7 anyway. I have a script that only selects the exact driver I want, and culls the rest. That cuts down on your build time more significantly than the dricore improvement ever could.

    Still, a welcome little respite, might save me a second or two every few days

  4. #4

    Default

    Traditionally the Mesa DRI drivers have statically linked all of the common Mesa code into each driver build. Statically copying all of this shared code into each of the modules obviously results in larger module sizes and more code that needs to be compiled.
    Linking is done after compilation is finished. Regardless of whether you statically link code or dynamically link code, the total amount of compilation work remains the same.

    Unless the code is being copied by a preprocessor, your statement is wrong. If it is being copied by a preprocessor, then your statement is also wrong, because that has nothing to do with linking.

  5. #5
    Join Date
    Dec 2008
    Location
    Poland
    Posts
    119

    Default

    Quote Originally Posted by allquixotic View Post
    A Mesa build is ridiculously fast on a commodity Core i7 anyway.
    Core i7 is ridiculously expensive these days and it's good that packages take less place because you can add more to live cd's.

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,269

    Default

    Yes, this is especially good for livecd's. The patch was shipping in Fedora for years before this, good to see it finally upstream.

  7. #7

    Default

    Calling functions from external libraries usually slows down the execution of a program.

    You may easily check it out by building bzip2 statically or linked against libbz2.so

    There will be almost 20% performance difference.

  8. #8

    Default

    Quote Originally Posted by Plombo View Post
    That's very wrong - the patch is not by Eric. It's by Christopher James Halse Rogers from Canonical. Eric just committed it to Mesa master.
    <sarcasm><troll>
    impossible. canonical don't contribute anything
    </troll></sarcasm>

  9. #9
    Join Date
    Jan 2008
    Posts
    299

    Default

    Quote Originally Posted by birdie View Post
    Calling functions from external libraries usually slows down the execution of a program.

    You may easily check it out by building bzip2 statically or linked against libbz2.so

    There will be almost 20% performance difference.
    Benchmarks please.

  10. #10
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    972

    Default

    Quote Originally Posted by mattst88 View Post
    Benchmarks please.
    I second this

    how long does it take to do a dlopen() to an external shared library vs a statically linked one?

Posting Permissions

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