[Mesa-dev] [RFC] Concrete proposal to split classic

[Dylan Baker]

Maybe I could have been clearer, but I meant "We only guarantee that we'll keep the build working and that major security problems get fixed", If you or someone else wants to fix other issues that's fine, but I meant if someone says "i915c is too slow for some workload", we reserve the right to close that as EWONTFIX.

On Tue, Mar 23, 2021, at 01:26, Ian Romanick 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
> time.
> 
> 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
> > 
> 
>

-- 
  Dylan Baker
  dylan at pnwbakers.com