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

Wed Jun 16 01:36:37 UTC 2021

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?

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?

>
> --Jason
>
> On April 9, 2021 22:09:14 Dylan Baker <dylan at pnwbakers.com> wrote:
>
>> 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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210616/e32c922b/attachment-0001.htm>