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

[Rob Clark]

Other than the minor detail that we don't have pci-id's to
differentiate between adreno generations, I might suggest a2xx users
to use -lts

BR,
-R

On Thu, Mar 25, 2021 at 9:14 AM Dylan Baker <dylan at pnwbakers.com> wrote:
>
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. Maybe it makes sense to keep gallium for r300? But how many r300 breakages have we had in recent memory?
>
> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark <robdclark at gmail.com> wrote:
> > >
> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <dylan at pnwbakers.com> 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
> > >
> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > > gallium is already starting to get poked thru in the name of
> > > performance, and we've already discovered cases of classic drivers
> > > being broken for multiple months with no one noticing.  I think a
> > > slower moving -lts branch is the best approach to keeping things
> > > working for folks with older hw.
> > >
> > > But possibly there is some value in not completely disabling gallium
> > > completely in the -lts branch.  We do have some older gallium drivers
> > > which do not have CI coverage and I think are not used frequently by
> > > developers who are tracking the latest main/master branch.  I'm not
> > > suggesting that we remove them from the main (non-lts) branch but it
> > > might be useful to be able to recommend users of those drivers stick
> > > with the -lts version for better stability?
> >
> > I agree with this.  Generally, I don't think we should delete anything
> > from the -lts branch.  Doing so only risks more breakage.  We probably
> > want to change some meson build defaults to not build anything but old
> > drivers but that's it.
> >
> > --Jason
> >
> > > BR,
> > > -R
> > >
> > > > 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
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> --
>   Dylan Baker
>   dylan at pnwbakers.com