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

Wed Jun 16 06:51:26 UTC 2021

Why not proceed with splitting the classic drivers including i965 as
was discussed previously?

Then, when you feel that crocus and i915g are ready to be default, you
can simply delete i965 from the classic branch and tell users they can
use mesa main once again.

On Tue, 2021-06-15 at 20:03 -0500, Jason Ekstrand wrote:
> I'm bringing this up via e-mail so it gets a wider audience. Given
> how will crocus is working at this point, is like to propose we hold
> off for about three more releases before we drop classic. This next
> release, 21.2, we'll have crocus as an option with i965 as the
> default. There will also be a -Dprefer-crocus meson options so
> distros or individuals can attempt to flip it on. The release after
> that, 21.3, we'll keep i965 in the tree but have crocus be the
> default (assuming things are going well.) Some time in 2022, probably
> after the 22.2 release or so, we'll delete classic.
> 
> Why wait so long? Well, it just landed and we don't have a Cherryview
> story yet so I'm hesitant to make it the default too quickly. Even if
> it were the default in 21.2, it's already too late, likely, to hit
> the fall 2021 distro release cycle. If we flip it to the default
> before the end of the year, that'll get crocus into spring distros.
> This is good because 22.04 is an Ubuntu LTS release and I think
> they'd rather bump crocus versions to fix bugs than backport on top
> of i965. But that's really fort Ubuntu to decide. In any case, we
> won't see broad-spread usage and the flood of bug reports until next
> spring so we may want to wait until then to stay deleting code.
> 
> If we wanted to accelerate things, one option, once we're ready,
> would be to ask the person who manages the oibaf PPA to switch to
> crocus early. That may get some early adopters on board.
> 
> Thoughts?
> 
> --Jason
> 
> On April 9, 2021 22:09:14 Dylan Baker <dylan at pnwbakers.com> wrote:
> 
> > Quoting Dylan Baker (2021-03-22 15:15:30)
> > > 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
> > > 
> > 
> > Here is a merge request to remove classic:
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153
> > 
> > Dylan
> > 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev