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

[Marek Olšák]

+1

We still have some CPU overhead performance targets we haven't reached. One
of them is to decrease CPU overhead for one benchmark 4 times compared to
everything we already have in master. I don't know how we are going to do
that, but we'll try.

Marek

On Mon, Mar 22, 2021 at 6: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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210323/f50069f9/attachment.htm>