Announcement

Collapse
No announcement yet.

Mesa Mega Driver Patches Published

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

  • phoronix
    started a topic Mesa Mega Driver Patches Published

    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

  • oibaf
    replied
    Originally posted by xming View Post
    I have been building mesa with -flto for a long time, all I need is to do tthe following after configure
    Code:
    sed -i -e "s/flto/fno-lto/g" src/mapi/shared-glapi/Makefile
    sed -i -e "s/flto/fno-lto/g" src/mapi/vgapi/Makefile
    Nice, it would be useful if you can send a patch to enable it with a configure option like --enable-lto .

    Leave a comment:


  • przemoli
    replied
    Originally posted by JS987 View Post
    LTO is still broken. You should probably report bug to GCC or LTO will never fully work.
    That got me wondering on compiling Mesa with Clang.. Any benefits? Anyone tried? Any Gentoo user around?

    Leave a comment:


  • JS987
    replied
    Originally posted by Bitiquinho View Post
    Which are the correct flags for building this as a monolithic driver ? Compiling with -flto still fails for me.
    LTO is still broken. You should probably report bug to GCC or LTO will never fully work.

    Leave a comment:


  • xming
    replied
    Originally posted by Bitiquinho View Post
    Which are the correct flags for building this as a monolithic driver ? Compiling with -flto still fails for me.
    I have been building mesa with -flto for a long time, all I need is to do tthe following after configure
    Code:
    sed -i -e "s/flto/fno-lto/g" src/mapi/shared-glapi/Makefile
    sed -i -e "s/flto/fno-lto/g" src/mapi/vgapi/Makefile

    Leave a comment:


  • Bitiquinho
    replied
    Can't get LTO build

    Which are the correct flags for building this as a monolithic driver ? Compiling with -flto still fails for me.

    Leave a comment:


  • libv
    replied
    Originally posted by marek View Post
    Sure, Gallium did break things into smaller, manageable parts, but in order to evolve those parts rapidly, they all need to be developed as a single binary, even though they are pretty separate at the code level.
    See, this is the bit that i do not agree with. You do not need to have one-huge-blob for development to move fast. I actually am very certain that driver development would be faster and higher quality, if driver deployment were much easier. This would incur a slight bit of infrastructure overhead, but the net effect would be more than positive.

    Originally posted by marek View Post
    I don't think the Mesa model is comparable to the kernel, alsa, and oss. Each project has a different set of goals and constraints. What works for one project doesn't necessarily work for another. And as far as I know, the Mesa model works for everybody who has at least 3 commits there.
    This smells like another bit of mesa logic.

    Just like in 2010 when i got to hear that i could perhaps have modular drivers for gallium, but never for the old style dri drivers. I then went off for a few months, and came back with modular drivers for ""old"" mesa. And then i got told that i could perhaps have modular drivers for old style dri drivers, but never for gallium...

    Now my view that Mesa could do well out of modularity and shared libraries is discounted on the fact that i do not have enough commits. But in order to have enough commits, i first need to fully buy into the mesa way of working. So either one buys in completely, and doesn't talk about what clearly is a very political issue, or one is told to STFU on account of not having bought in in the first place. Another nice mesa Catch-22.

    And btw, if you think that a statement like "you only have 2 commits, so stfu" stopped me arguing, this clearly proves you wrong. I was just stuck into the chromebook mali very deeply. Imho it is pretty poor when one has to revert to such tactics, especially with the author of a mesa graphics driver. Given the situation open source software is in, one would think that mesa would be there to provide a framework for drivers, and that everything is done to give driver developers an easier time, and not the other way around.

    Leave a comment:


  • marek
    replied
    Originally posted by libv View Post
    Anyway, since everyone always likes to always compare monolithic projects to the kernel. How stone age is the kernel? The kernel allows modules, the kernel allow moving bits of interface that one actually does call APIs. Sure, you can build things in and perhaps get some advantage out of that, but try sending an email to the kernel stating "all this module business, that's just bs, we should all just go back to building a single monolithic binary! And tell you what, why don't we just build a bigger monolith which supports multiple arches?"

    I sometimes feel like the days where people were bashing alsa for breaking things up in manageable parts, whereas oss was just one big binary and that was surely how it was meant to be.
    Sure, Gallium did break things into smaller, manageable parts, but in order to evolve those parts rapidly, they all need to be developed as a single binary, even though they are pretty separate at the code level.

    I don't think the Mesa model is comparable to the kernel, alsa, and oss. Each project has a different set of goals and constraints. What works for one project doesn't necessarily work for another. And as far as I know, the Mesa model works for everybody who has at least 3 commits there.

    Leave a comment:


  • libv
    replied
    Originally posted by marek View Post
    You are insane. It's not the 21st century you're proposing. You want to take Mesa back to the stone age. The current way of managing the project is the only way to sustain progress. If you don't like it, make your own fork, or don't use Mesa at all.

    Personally I'm mainly interested in link-time optimizations. I don't care much about the space.
    Anyway, since everyone always likes to always compare monolithic projects to the kernel. How stone age is the kernel? The kernel allows modules, the kernel allow moving bits of interface that one actually does call APIs. Sure, you can build things in and perhaps get some advantage out of that, but try sending an email to the kernel stating "all this module business, that's just bs, we should all just go back to building a single monolithic binary! And tell you what, why don't we just build a bigger monolith which supports multiple arches?"

    I sometimes feel like the days where people were bashing alsa for breaking things up in manageable parts, whereas oss was just one big binary and that was surely how it was meant to be.

    Leave a comment:


  • darkbasic
    replied
    Honestly, how can someone really care about disk space in the 2013? It shouldn't even be considered as an advantage in my opinion

    Leave a comment:

Working...
X