Quoting Dylan Baker (2021-03-22 15:15:30) > 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
Here is a merge request to remove classic: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153 Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
