[Mesa-dev] [RFC] Concrete proposal to split classic

[Emma Anholt]

On Tue, Jun 15, 2021 at 8:16 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri <tarceri at itsqueeze.com> wrote:
> >
> > On 6/16/21 11:03 AM, Jason Ekstrand wrote:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Thoughts?

It certainly is tempting to just throw away classic without going
through this LTS branch adventure (I might say "charade") for distros.
I really think that people with i8xx/r200/r100 are better served with
swrast than HW GL in an otherwise-current world of software, and for
an old-distro snapshot where lots of software *would* work on that
hardware, what we do in current Mesa doesn't matter.  i915's right at
the cusp of usefulness in my opinion, and I'd put r300 pretty close to
it.

If we're acting like this LTS branch is a serious thing, though, then
I don't see a good reason to wait until 2022.  Let "did they build
crocus" be the switch between current Mesa and LTS i965.

I really want !8044 and garbage-collecting huge swaths of the GLSL
compiler, and while 2022 may realistically be when we can do that by,
I think we'll be slower about pushing on it if people are thinking
"well, we can't delete anything till next year anyway".

> > 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?
>
> Yeah, that was the idea.  However, with crocus in good shape and Emma
> Anholt working on i915g, it may be that the actual answer is we just
> throw away the classic drivers and the only thing you really need the
> old branch for is r200 and ancient nouveau.

i915g still has major issues: large vertex count crashes, lack of link
failures, and crashes on compile failures being the top ones.  Once I
get driver-produced link failures plumbed through gallium somehow
(feels possible now that we precompile, and vc4 really needs it for
conformance too) and the NIR stuff landed, I think it'll be a pretty
plausible driver, and probably on average better for users than the
bitrotted stuff we've shipped for the last decade.  Regression-free
would be a long road, though, and given a different compiler pipeline
that might schedule differently plus the texture phase limits,
possibly not tractable in practice.

By far the limiting factor for i915g progress now that I've got some
CI rigged up is review.  My preference would be that we all agree that
nobody wants to look at i915, and some responsible folks (ajax and a
couple Intel volunteers, perhaps?) bless me to merge without review
once an i915g-only MR has been up for a week.