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

[Ian Romanick]

On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> Can you be more specific? Also, is there a reason why that work can't
> or shouldn't be done directly in the LTS branch?  As Ken pointed out,

The bulk of things that I had going were to enable some extensions and
make those extensions non-optional.  ARB_framebuffer_object was at the
top of the list, but there were a couple of others.  I think ARB_fbo
also affected the Gallium nouveau driver.  Some of that was derailed
when I wasn't able to remove (classic) support for NV04 and NV05... and
I don't remember exactly where I left it.  I would expect some of those
kinds of changes to also happen in post-fork mainline too.

Some of the other stuff... would actually be easier after the split
because I wouldn't have to deal with Windows compilers.

> I'm not sure we want to totally declare those drivers dead. People can
> still do feature or enhancement development of they want to, it just
> happens in a different branch.
> 
> I think we need to be more clear about what "LTS mode" means for
> developers and users here. It isn't that they can never change our be
> improved. It's that we've gotten to the point where what they're
> getting from being in the active development tree is breakage, not
> "free" improvements. We're suggesting changing the social contract
> with users, so to speak, from "these drivers still pick up
> improvements from core" to "we won't break these drivers when we make
> improvements to core in master."

That is interesting.  I doesn't sound very much like "long term stable"
as in the original proposal.  What would the versioning scheme be?  In
the original proposal, I would have expected versions go to 21.1.∞.  How
would that work if some version adds a feature?  Would the versions (and
branches from the branch?) follow the usual Mesa Year.Quarter.x scheme?

> So, unless there's a solid reason why such work needs to happen in the
> master branch, I don't see a reason to hold this up for it.  As long
> as you're committed to test r200 and i915 when you make said changes,
> we can do a feature release on the LTS branch. Users and distros just
> shouldn't expect that to be a common thing.

This inverts the current testing problem.  Right now, r200 and i915 are
poorly tested, but 965G through Sandybridge are very well tested.  While
I can totally test core changes on r200 and i915, how would I verify
that those changes don't break, say, Ironlake?

> --Jason
> 
> On Tue, Mar 23, 2021 at 3:26 AM Ian Romanick <idr at freedesktop.org> wrote:
>>
>> I would like to wait a couple more releases to do this.  I have a couple
>> things that I've been gradually working on for some of the non-i965
>> classic drivers that I'd like to land before they're put out to pasture.
>>  I talked to ajax about this a few weeks ago, and he was amenable at the
>> time.
>>
>> I can step up on testing at least r200 to make sure core changes aren't
>> making things explode.  That should also cover most of the problems that
>> could hit i915.  i965 gets good coverage in the Intel CI, so I don't
>> think that's as big of a problem.
>>
>> On 3/22/21 3:15 PM, Dylan Baker wrote:
>>> 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