Announcement

Collapse
No announcement yet.

A Modularized Mesa 7.8 Is Published

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

  • A Modularized Mesa 7.8 Is Published

    Phoronix: A Modularized Mesa 7.8 Is Published

    Mesa 7.8 was released last week (and then yesterday an emergency 7.8.1 release arrived) in its traditional bundled form with the DRI drivers, but this afternoon a version with the popular hardware drivers modularized and built around an SDK, has been published...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why original mesa don't switch modularized version?

    Comment


    • #3
      I would examine his git tree and compare it to regular Mesa, but I'm too lazy. Maybe he would get more attention from busy Mesa devs (not that I am one) if there were samples of code that was improved. Or scenarios that demonstrate how modularized Mesa would be better. Any kind of practical comparison.

      He should also post a FAQ - I'm probably not the only one who's fuzzy on the benefits. This helps a little:
      Originally posted by [url=http://www.phoronix.com/scan.php?page=news_item&px=ODA2MQ]Luc Modularizes Mesa, DRI Drivers[/url]
      He shared with everyone his views on changes that should be made to the Mesa/X.Org/DRM stack, including some greater modularization, in an effort to make the testing / build process easier, drive greater maintainability of drivers, and unifying components by providing more shared libraries and formalizing different APIs.
      So does it actually accomplish that?

      Comment


      • #4
        Originally posted by Death Knight View Post
        Why original mesa don't switch modularized version?
        Because they disagree with Luc that it's the right thing to do. Or at least, that its's the right thing for *them*.

        As far as I can tell, it amounts to that while Luc's approach would be more convenient for packaging and for users wanting to update drivers, the actual developers consider the current approach to suit them better. And seeing as how they're the ones doing the work, they're not much interested in Luc's changes.

        Comment


        • #5
          I appreciate Luc doing extra work for the community and all, but what does he expect to happen? I can't imagine a scenario where a group of devs would just drop what they're doing because someone out of the group moved some stuff around. There would be a little overhead where they're trying to figure out what he did, but it'd be annoying enough to not bother with it probably. Must be frustrating.

          Comment


          • #6
            Originally posted by garytr24 View Post
            I appreciate Luc doing extra work for the community and all, but what does he expect to happen? I can't imagine a scenario where a group of devs would just drop what they're doing because someone out of the group moved some stuff around. There would be a little overhead where they're trying to figure out what he did, but it'd be annoying enough to not bother with it probably. Must be frustrating.
            Not to mention that there is a reason that Luc is not "part of the group", despite his obvious talent as a programmer and his interest in improving linux graphics.

            He is very quick to throw around personal insults and attacks on the character and motivations of others. Understandably, this does not tend to inspire a cooperative attitude in those others, regardless of the technical merits of his positions.

            Comment


            • #7
              Originally posted by thalience View Post
              Not to mention that there is a reason that Luc is not "part of the group", despite his obvious talent as a programmer and his interest in improving linux graphics.

              He is very quick to throw around personal insults and attacks on the character and motivations of others. Understandably, this does not tend to inspire a cooperative attitude in those others, regardless of the technical merits of his positions.
              Depends on what you call quick. There is a lot of history there, and all of that can be boiled down to characters and their motivations.

              Comment


              • #8
                Originally posted by libv View Post
                Depends on what you call quick. There is a lot of history there, and all of that can be boiled down to characters and their motivations.
                And i have never been part of "the" group from the start. When Keith got caught lying, I just wanted to get a driver developed, instead of trying to kill xfree86. I also was not doing kdrive, i was not doing the cool stuff like dri and mpeg. I was doing modesetting, on hardware for which free software was a good choice OS, for a vendor that was then showing potential for becoming more open. Goals all deemed useless then apparently, but not so useless later on, and the same story has been repeating itself ever since.

                Comment


                • #9
                  Originally posted by garytr24 View Post
                  I appreciate Luc doing extra work for the community and all, but what does he expect to happen? I can't imagine a scenario where a group of devs would just drop what they're doing because someone out of the group moved some stuff around. There would be a little overhead where they're trying to figure out what he did, but it'd be annoying enough to not bother with it probably. Must be frustrating.
                  It's single patches each time, that just alters the build system. Most of it is actually just listing the headerfiles that form the SDK.

                  Don't you think that developers should actually spend some time thinking about what their users actually need? Or do you think that they shouldjust play around to suit themselves, all the time?

                  Comment


                  • #10
                    Originally posted by libv View Post
                    It's single patches each time, that just alters the build system. Most of it is actually just listing the headerfiles that form the SDK.
                    I did look at the changes and it is just build changes. I could see how the changes would make things easier on distributors and users. I'm not sure how much more difficult it would be for other developers probably almost none, especially after the initial adjustment period.

                    I really don't understand why this is such a big deal, why not accept it? Can someone please explain? It'd be great to hear from a developer who is opposed. It's much easier to discuss when there is something tangible to talk about, no one can make assumptions about what it will or will not do. Nice job Luc.

                    Comment

                    Working...
                    X