Announcement

Collapse
No announcement yet.

Mesa Can Now Be Smaller, Build Faster

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


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

            Comment


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

              Comment


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

                Comment


                • #9
                  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.

                  Comment


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

                    Comment

                    Working...
                    X