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

[Alyssa Rosenzweig]

I'd like to see it happen, though I don't understand how to make these
coexist for distros. Would like to hear from the Debian/etc maintainers
of mesa.

Then again I *think* classic-lts doesn't need to be built for
armhf/arm64 at all, so I suppose I'm personally unaffected :-P

On Mon, Mar 22, 2021 at 03:15:30PM -0700, 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