[Mesa-dev] [RFC] Concrete proposal to split classic
jason at jlekstrand.net
Thu Mar 25 17:49:57 UTC 2021
Can you be more specific? Also, is there a reason why that work can't
or shouldn't be done directly in the LTS branch? As Ken pointed out,
I'm not sure we want to totally declare those drivers dead. People can
still do feature or enhancement development of they want to, it just
happens in a different branch.
I think we need to be more clear about what "LTS mode" means for
developers and users here. It isn't that they can never change our be
improved. It's that we've gotten to the point where what they're
getting from being in the active development tree is breakage, not
"free" improvements. We're suggesting changing the social contract
with users, so to speak, from "these drivers still pick up
improvements from core" to "we won't break these drivers when we make
improvements to core in master."
So, unless there's a solid reason why such work needs to happen in the
master branch, I don't see a reason to hold this up for it. As long
as you're committed to test r200 and i915 when you make said changes,
we can do a feature release on the LTS branch. Users and distros just
shouldn't expect that to be a common thing.
On Tue, Mar 23, 2021 at 3:26 AM Ian Romanick <idr at freedesktop.org> wrote:
> I would like to wait a couple more releases to do this. I have a couple
> things that I've been gradually working on for some of the non-i965
> classic drivers that I'd like to land before they're put out to pasture.
> I talked to ajax about this a few weeks ago, and he was amenable at the
> I can step up on testing at least r200 to make sure core changes aren't
> making things explode. That should also cover most of the problems that
> could hit i915. i965 gets good coverage in the Intel CI, so I don't
> think that's as big of a problem.
> On 3/22/21 3:15 PM, Dylan Baker wrote:
> > Hi list,
> > We've talked about it a number of times, but I think it's time time to
> > discuss splitting the classic drivers off of the main development branch
> > again, although this time I have a concrete plan for how this would
> > work.
> > First, why? Basically, all of the classic drivers are in maintanence
> > mode (even i965). Second, many of them rely on code that no one works
> > on, and very few people still understand. There is no CI for most of
> > them, and the Intel CI is not integrated with gitlab, so it's easy to
> > unintentionally break them, and this breakage usually isn't noticed
> > until just before or just after a release. 21.0 was held up (in small
> > part, also me just getting behind) because of such breakages.
> > I konw there is some interest in getting i915g in good enough shape that
> > it could replace i915c, at least for the common case. I also am aware
> > that Dave, Ilia, and Eric (with some pointers from Ken) have been
> > working on a gallium driver to replace i965. Neither of those things are
> > ready yet, but I've taken them into account.
> > Here's the plan:
> > 1) 21.1 release happens
> > 2) we remove classic from master
> > 3) 21.1 reaches EOL because of 21.2
> > 4) we fork the 21.1 branch into a "classic-lts"¹ branch
> > 5) we disable all vulkan and gallium drivers in said branch, at least at
> > the Meson level
> > 6) We change the name and precidence of the glvnd loader file
> > 7) apply any build fixups (turn of intel generators for versions >= 7.5,
> > for example
> > 8) maintain that branch with build and critical bug fixes only
> > This gives ditros and end users two options.
> > 1) then can build *only* the legacy branch in the a normal Mesa provides
> > libGL interfaces fashion
> > 2) They can use glvnd and install current mesa and the legacy branch in
> > parallel
> > Because of glvnd, we can control which driver will get loaded first, and
> > thus if we decide i915g or the i965 replacement is ready and turn it on
> > by default it will be loaded by default. An end user who doesn't like
> > this can add a new glvnd loader file that makes the classic drivers
> > higher precident and continue to use them.
> > Why fork from 21.1 instead of master?
> > First, it allows us to delete classic immediately, which will allow
> > refactoring to happen earlier in the cycle, and for any fallout to be
> > caught and hopefully fixed before the release. Second, it means that
> > when a user is switched from 21.1 to the new classic-lts branch, there
> > will be no regressions, and no one has to spend time figuring out what
> > broke and fixing the lts branch.
> > When you say "build and critical bug fixes", what do you mean?
> > I mean update Meson if we rely on something that in the future is
> > deprecated and removed, and would prevent building the branch or an
> > relying on some compiler behavior that changes, gaping exploitable
> > security holes, that kind of thing.
> > footnotes
> > ¹Or whatever color you like your bikeshed
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev