<div dir="auto">Another thing is that glsl_to_tgsi is going to be removed but an old driver may want to keep it. For this case, glsl_to_tgsi will be preserved in the lts branch.<div dir="auto"> </div><div dir="auto">Marek</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon., Mar. 29, 2021, 18:59 Ilia Mirkin, <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Probably nv30 would do well to "move on" as well. But it also presents an interesting question -- the nv30 driver has lots of problems. I have no plans to fix them, nor am I aware of anyone else with such plans. However if such a developer were to turn up, would it be reasonable to assume that their work would ultimately land in this "lts" branch/tree/whatever? Some of the "fixes" will require large-ish changes to the driver... Cheers, -ilia On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>> wrote: > > Alright that's r300 and swr that are going to find a new home in the lts branch. Do any other gallium drivers want to join them? > > Marek > > On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan, <<a href="mailto:jan.zielinski@intel.com" target="_blank" rel="noreferrer">jan.zielinski@intel.com</a>> wrote: >> >> On Thursday, March 25, 2021 8:47 Marek Olšák wrote: >> > 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. >> >> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently are focusing effort on other OSS projects, and want to maintain OpenSWR at its current feature level, but we are often seeing Mesa core changes causing problems in OpenSWR, that we can’t always address right away. So, we would like to point our users to a stable branch, that limits the amount of effort required for OpenSWR to support its existing users. >> >> Jan >> >> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: >> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark <mailto:<a href="mailto:robdclark@gmail.com" target="_blank" rel="noreferrer">robdclark@gmail.com</a>> wrote: >> > > >> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <mailto:<a href="mailto:dylan@pnwbakers.com" target="_blank" rel="noreferrer">dylan@pnwbakers.com</a>> 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 >> > > >> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and >> > > gallium is already starting to get poked thru in the name of >> > > performance, and we've already discovered cases of classic drivers >> > > being broken for multiple months with no one noticing. I think a >> > > slower moving -lts branch is the best approach to keeping things >> > > working for folks with older hw. >> > > >> > > But possibly there is some value in not completely disabling gallium >> > > completely in the -lts branch. We do have some older gallium drivers >> > > which do not have CI coverage and I think are not used frequently by >> > > developers who are tracking the latest main/master branch. I'm not >> > > suggesting that we remove them from the main (non-lts) branch but it >> > > might be useful to be able to recommend users of those drivers stick >> > > with the -lts version for better stability? >> > >> > I agree with this. Generally, I don't think we should delete anything >> > from the -lts branch. Doing so only risks more breakage. We probably >> > want to change some meson build defaults to not build anything but old >> > drivers but that's it. >> > >> > --Jason >> > >> > > BR, >> > > -R >> > > >> > > > 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 >> > > > mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a> >> > > > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> >> > > _______________________________________________ >> > > mesa-dev mailing list >> > > mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a> >> > > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> >> > >> >> -- >> Dylan Baker >> mailto:<a href="mailto:dylan@pnwbakers.com" target="_blank" rel="noreferrer">dylan@pnwbakers.com</a> >> _______________________________________________ >> mesa-dev mailing list >> mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a> >> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> >> Intel Technology Poland sp. z o.o. >> ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. >> Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. >> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. > > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div>