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

[Dylan Baker]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210322/71052cb3/attachment.sig>