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.
Marek On Mon., Mar. 29, 2021, 18:59 Ilia Mirkin, <imir...@alum.mit.edu> wrote: > 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 <mar...@gmail.com> 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, <jan.zielin...@intel.com> > 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: > robdcl...@gmail.com> wrote: > >> > > > >> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <mailto: > dy...@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 > >> > > > >> > > 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:mesa-dev@lists.freedesktop.org > >> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> > > _______________________________________________ > >> > > mesa-dev mailing list > >> > > mailto:mesa-dev@lists.freedesktop.org > >> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> > > >> > >> -- > >> Dylan Baker > >> mailto:dy...@pnwbakers.com > >> _______________________________________________ > >> mesa-dev mailing list > >> mailto:mesa-dev@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> 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 > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev