Announcement

Collapse
No announcement yet.

Mesa Mega Driver Patches Published

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

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

    Comment


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

      Comment


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

        Comment


        • #34
          Can't get LTO build

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

          Comment


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

            Comment


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

              Comment


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

                Comment


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

                  Comment

                  Working...
                  X