<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <body> <div dir="auto"> <div dir="auto">I'm bringing this up via e-mail so it gets a wider audience. Given how will crocus is working at this point, is like to propose we hold off for about three more releases before we drop classic. This next release, 21.2, we'll have crocus as an option with i965 as the default. There will also be a -Dprefer-crocus meson options so distros or individuals can attempt to flip it on. The release after that, 21.3, we'll keep i965 in the tree but have crocus be the default (assuming things are going well.) Some time in 2022, probably after the 22.2 release or so, we'll delete classic.</div><div dir="auto"><br></div><div dir="auto">Why wait so long? Well, it just landed and we don't have a Cherryview story yet so I'm hesitant to make it the default too quickly. Even if it were the default in 21.2, it's already too late, likely, to hit the fall 2021 distro release cycle. If we flip it to the default before the end of the year, that'll get crocus into spring distros. This is good because 22.04 is an Ubuntu LTS release and I think they'd rather bump crocus versions to fix bugs than backport on top of i965. But that's really fort Ubuntu to decide. In any case, we won't see broad-spread usage and the flood of bug reports until next spring so we may want to wait until then to stay deleting code.</div><div dir="auto"><br></div><div dir="auto">If we wanted to accelerate things, one option, once we're ready, would be to ask the person who manages the oibaf PPA to switch to crocus early. That may get some early adopters on board.</div><div dir="auto"><br></div><div dir="auto">Thoughts?</div><div dir="auto"><br></div><div dir="auto">--Jason</div><div dir='auto'><br></div> <div id="aqm-original" style="color: black;"> <div dir="auto">On April 9, 2021 22:09:14 Dylan Baker <dylan@pnwbakers.com> wrote:</div> <div><br></div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div dir="auto">Quoting Dylan Baker (2021-03-22 15:15:30)</div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <div dir="auto">Hi list,</div> <div dir="auto"><br></div> <div dir="auto">We've talked about it a number of times, but I think it's time time to</div> <div dir="auto">discuss splitting the classic drivers off of the main development branch</div> <div dir="auto">again, although this time I have a concrete plan for how this would</div> <div dir="auto">work.</div> <div dir="auto"><br></div> <div dir="auto">First, why? Basically, all of the classic drivers are in maintanence</div> <div dir="auto">mode (even i965). Second, many of them rely on code that no one works</div> <div dir="auto">on, and very few people still understand. There is no CI for most of</div> <div dir="auto">them, and the Intel CI is not integrated with gitlab, so it's easy to</div> <div dir="auto">unintentionally break them, and this breakage usually isn't noticed</div> <div dir="auto">until just before or just after a release. 21.0 was held up (in small</div> <div dir="auto">part, also me just getting behind) because of such breakages.</div> <div dir="auto"><br></div> <div dir="auto">I konw there is some interest in getting i915g in good enough shape that</div> <div dir="auto">it could replace i915c, at least for the common case. I also am aware</div> <div dir="auto">that Dave, Ilia, and Eric (with some pointers from Ken) have been</div> <div dir="auto">working on a gallium driver to replace i965. Neither of those things are</div> <div dir="auto">ready yet, but I've taken them into account.</div> <div dir="auto"><br></div> <div dir="auto">Here's the plan:</div> <div dir="auto"><br></div> <div dir="auto">1) 21.1 release happens</div> <div dir="auto">2) we remove classic from master</div> <div dir="auto">3) 21.1 reaches EOL because of 21.2</div> <div dir="auto">4) we fork the 21.1 branch into a "classic-lts"¹ branch</div> <div dir="auto">5) we disable all vulkan and gallium drivers in said branch, at least at</div> <div dir="auto">the Meson level</div> <div dir="auto">6) We change the name and precidence of the glvnd loader file</div> <div dir="auto">7) apply any build fixups (turn of intel generators for versions >= 7.5,</div> <div dir="auto">for example</div> <div dir="auto">8) maintain that branch with build and critical bug fixes only</div> <div dir="auto"><br></div> <div dir="auto">This gives ditros and end users two options.</div> <div dir="auto">1) then can build *only* the legacy branch in the a normal Mesa provides</div> <div dir="auto">libGL interfaces fashion</div> <div dir="auto">2) They can use glvnd and install current mesa and the legacy branch in</div> <div dir="auto">parallel</div> <div dir="auto"><br></div> <div dir="auto">Because of glvnd, we can control which driver will get loaded first, and</div> <div dir="auto">thus if we decide i915g or the i965 replacement is ready and turn it on</div> <div dir="auto">by default it will be loaded by default. An end user who doesn't like</div> <div dir="auto">this can add a new glvnd loader file that makes the classic drivers</div> <div dir="auto">higher precident and continue to use them.</div> <div dir="auto"><br></div> <div dir="auto">Why fork from 21.1 instead of master?</div> <div dir="auto"><br></div> <div dir="auto">First, it allows us to delete classic immediately, which will allow</div> <div dir="auto">refactoring to happen earlier in the cycle, and for any fallout to be</div> <div dir="auto">caught and hopefully fixed before the release. Second, it means that</div> <div dir="auto">when a user is switched from 21.1 to the new classic-lts branch, there</div> <div dir="auto">will be no regressions, and no one has to spend time figuring out what</div> <div dir="auto">broke and fixing the lts branch.</div> <div dir="auto"><br></div> <div dir="auto">When you say "build and critical bug fixes", what do you mean?</div> <div dir="auto"><br></div> <div dir="auto">I mean update Meson if we rely on something that in the future is</div> <div dir="auto">deprecated and removed, and would prevent building the branch or an</div> <div dir="auto">relying on some compiler behavior that changes, gaping exploitable</div> <div dir="auto">security holes, that kind of thing.</div> <div dir="auto"><br></div> <div dir="auto">footnotes</div> <div dir="auto">¹Or whatever color you like your bikeshed</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">Here is a merge request to remove classic:</div> <div dir="auto">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153</div> <div dir="auto"><br></div> <div dir="auto">Dylan</div> </blockquote> </div><div dir="auto"><br></div> </div></body> </html>