Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: Mesa Mega Driver Patches Published

  1. #31
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

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

  2. #32
    Join Date
    Jan 2009
    Posts
    624

    Default

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

  3. #33
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

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

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

  4. #34
    Join Date
    Nov 2010
    Posts
    41

    Default Can't get LTO build

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

  5. #35
    Join Date
    Jan 2010
    Posts
    21

    Default

    Quote 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

  6. #36
    Join Date
    Sep 2012
    Posts
    343

    Default

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

  7. #37
    Join Date
    Sep 2010
    Posts
    687

    Default

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

  8. #38

    Default

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

Posting Permissions

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