Announcement

Collapse
No announcement yet.

Mesa's Rate Of Git Development Is Slowing

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

  • #31
    Originally posted by gamerk2 View Post
    So...even if the driver works 100% (which I can't say one way or the other), if there aren't any updates, it gets depriciated?

    Am I the only person who realizes how idiotic that is?

    Also, the fact MESA needs so many drivers for different architectures is why I hope Gallium replaces it. One interface, one backend.
    You vision of gallium is somewhat wrong. There currently are 12 backends (4 nvidia, 4 amd, 1 intel, 1 svga, 2 pure X11), not one. And the interface changes on a regular basis to gain new features. At this point I'm not sure gallium can handle GL 3.1 (there may be changes needed for UBO) and I'm certain it can't handle GL 3.2+ (need some things for geometry shaders).

    Unmaintained drivers quickly don't work 100% anymore because the API changes for new features and untested updates can only stretch to a point. Or, in other terms, every unmaintained driver eventually stops working 100% (and can end up near 0% very fast in some cases).

    OG.

    Comment


    • #32
      It's worth noting that 2010 was the year we rewrote the GLSL compiler basically from scratch. So the commit stats might have been a bit abnormally high that year. It'll be interesting to see how things stand in December.

      Also, OG is right, Gallium doesn't support UBOs, as required by 3.1. But neither does Mesa...or the shared GLSL compiler for that matter. Soon

      As for unmaintained drivers...it goes without saying that we wouldn't remove a driver that's working 100%. Most of the drivers we've removed were either horrendously broken (i965g), or only supported DRI1. For those that don't remember the bad old days, DRI1 meant that GL applications drew straight onto the screen; there was no way to transform them. With the advent of modern composited desktop environments like GNOME 3, KDE 4, or Compiz, this means no Expos?, no cube switcher, no coverflow alt-tabbing, and so on. Everything would zoom out, but any GL applications would draw smack on top of everything, at full size. It looked horrible and really broke these new user experiences. Since nobody stepped up to convert them to the modern DRI2 interface - even after it'd been around for several years - we decided it was time to remove them, and make our life easier. (Have we mentioned that developing Mesa/Gallium is hard? )

      Plus, Mesa and Gallium are both evolving a lot to incorporate new GL features, and this means reworking and rearchitecting a lot of stuff. Occasionally this means rewriting stuff in all the drivers, which can be a fair bit of work. Less drivers means it's easier to make those kinds of changes. Also, making cross-driver architecture changes can be a bit dodgy - typically the person doing the work only really tests on one system, rather than trying each generation of Radeon, Nvidia, Intel, Matrox, SiS, etc. For drivers that receive little to no actual testing, we don't have a lot of confidence that they still work or will continue to work. Ideally, we'd have them all in a lab, and test everything (and we should!). But let's be honest...there's a lot of people testing r600 or Sandybridge, and not a lot of people using (say) r200.

      We did keep compatibility so you can load the drivers from an older Mesa; simply using the older driver means you get less accidental breakage, and since there wasn't really any work being done anyway, you're not really missing out. It's just kind of a pain for packaging.
      Free Software Developer .:. Mesa and Xorg
      Opinions expressed in these forum posts are my own.

      Comment

      Working...
      X