<div dir="ltr"><div>+1</div><div><br></div><div>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.<br></div><div><br></div><div>Marek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 22, 2021 at 6:15 PM Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
We've talked about it a number of times, but I think it's time time to<br>
discuss splitting the classic drivers off of the main development branch<br>
again, although this time I have a concrete plan for how this would<br>
work.<br>
<br>
First, why? Basically, all of the classic drivers are in maintanence<br>
mode (even i965). Second, many of them rely on code that no one works<br>
on, and very few people still understand. There is no CI for most of<br>
them, and the Intel CI is not integrated with gitlab, so it's easy to<br>
unintentionally break them, and this breakage usually isn't noticed<br>
until just before or just after a release. 21.0 was held up (in small<br>
part, also me just getting behind) because of such breakages.<br>
<br>
I konw there is some interest in getting i915g in good enough shape that<br>
it could replace i915c, at least for the common case. I also am aware<br>
that Dave, Ilia, and Eric (with some pointers from Ken) have been<br>
working on a gallium driver to replace i965. Neither of those things are<br>
ready yet, but I've taken them into account.<br>
<br>
Here's the plan:<br>
<br>
1) 21.1 release happens<br>
2) we remove classic from master<br>
3) 21.1 reaches EOL because of 21.2<br>
4) we fork the 21.1 branch into a "classic-lts"¹ branch<br>
5) we disable all vulkan and gallium drivers in said branch, at least at<br>
   the Meson level<br>
6) We change the name and precidence of the glvnd loader file<br>
7) apply any build fixups (turn of intel generators for versions >= 7.5,<br>
   for example<br>
8) maintain that branch with build and critical bug fixes only<br>
<br>
This gives ditros and end users two options.<br>
1) then can build *only* the legacy branch in the a normal Mesa provides<br>
   libGL interfaces fashion<br>
2) They can use glvnd and install current mesa and the legacy branch in<br>
   parallel<br>
<br>
Because of glvnd, we can control which driver will get loaded first, and<br>
thus if we decide i915g or the i965 replacement is ready and turn it on<br>
by default it will be loaded by default. An end user who doesn't like<br>
this can add a new glvnd loader file that makes the classic drivers<br>
higher precident and continue to use them.<br>
<br>
Why fork from 21.1 instead of master?<br>
<br>
First, it allows us to delete classic immediately, which will allow<br>
refactoring to happen earlier in the cycle, and for any fallout to be<br>
caught and hopefully fixed before the release. Second, it means that<br>
when a user is switched from 21.1 to the new classic-lts branch, there<br>
will be no regressions, and no one has to spend time figuring out what<br>
broke and fixing the lts branch.<br>
<br>
When you say "build and critical bug fixes", what do you mean?<br>
<br>
I mean update Meson if we rely on something that in the future is<br>
deprecated and removed, and would prevent building the branch or an<br>
relying on some compiler behavior that changes, gaping exploitable<br>
security holes, that kind of thing.<br>
<br>
footnotes<br>
¹Or whatever color you like your bikeshed_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div>