<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 6/16/21 11:03 AM, Jason Ekstrand wrote:<br>
</p>
<blockquote type="cite"
cite="mid:17a125842a0.2817.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</blockquote>
<p>I though the idea was to put everything in a classic branch and
let distros run "classic" hardware from that. What happens after 3
releases does i965 still go to the classic branch with the other
classic drivers? If so is it really worth waiting just because
Ubuntu might have to back-port a bug fix?<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:17a125842a0.2817.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net">
<div dir="auto">
<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
<a class="moz-txt-link-rfc2396E" href="mailto:dylan@pnwbakers.com"><dylan@pnwbakers.com></a> 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"><a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153</a></div>
<div dir="auto"><br>
</div>
<div dir="auto">Dylan</div>
</blockquote>
</div>
<div dir="auto"><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>
</pre>
</blockquote>
</body>
</html>