<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu., Mar. 25, 2021, 12:14 Dylan Baker, <<a href="mailto:dylan@pnwbakers.com">dylan@pnwbakers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We don't have any recent information on the status of r300. Splitting it would be wise.</div><div dir="auto"><br></div><div dir="auto">Same thinking could be applied to other gallium drivers for old hardware that don't receive new development and are becoming more and more irrelevant every year due to their age.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:<br>
> On Wed, Mar 24, 2021 at 10:28 AM Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank" rel="noreferrer">robdclark@gmail.com</a>> wrote:<br>
> ><br>
> > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank" rel="noreferrer">dylan@pnwbakers.com</a>> wrote:<br>
> > ><br>
> > > 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>
> ><br>
> > I'm +1 for the -lts branch.. the layering between mesa "classic" and<br>
> > gallium is already starting to get poked thru in the name of<br>
> > performance, and we've already discovered cases of classic drivers<br>
> > being broken for multiple months with no one noticing.  I think a<br>
> > slower moving -lts branch is the best approach to keeping things<br>
> > working for folks with older hw.<br>
> ><br>
> > But possibly there is some value in not completely disabling gallium<br>
> > completely in the -lts branch.  We do have some older gallium drivers<br>
> > which do not have CI coverage and I think are not used frequently by<br>
> > developers who are tracking the latest main/master branch.  I'm not<br>
> > suggesting that we remove them from the main (non-lts) branch but it<br>
> > might be useful to be able to recommend users of those drivers stick<br>
> > with the -lts version for better stability?<br>
> <br>
> I agree with this.  Generally, I don't think we should delete anything<br>
> from the -lts branch.  Doing so only risks more breakage.  We probably<br>
> want to change some meson build defaults to not build anything but old<br>
> drivers but that's it.<br>
> <br>
> --Jason<br>
> <br>
> > BR,<br>
> > -R<br>
> ><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" rel="noreferrer">mesa-dev@lists.freedesktop.org</a><br>
> > > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
> > _______________________________________________<br>
> > mesa-dev mailing list<br>
> > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a><br>
> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
><br>
<br>
-- <br>
  Dylan Baker<br>
  <a href="mailto:dylan@pnwbakers.com" target="_blank" rel="noreferrer">dylan@pnwbakers.com</a><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div></div></div>