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

[Alyssa Rosenzweig]

> 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.

Congratulations, you're the new i915g maintainer ;-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timur Kristóf]

Why not proceed with splitting the classic drivers including i965 as
was discussed previously?

Then, when you feel that crocus and i915g are ready to be default, you
can simply delete i965 from the classic branch and tell users they can
use mesa main once again.

On Tue, 2021-06-15 at 20:03 -0500, 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?
> 
> --Jason
> 
> On April 9, 2021 22:09:14 Dylan Baker  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 

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

[Emma Anholt]

On Tue, Jun 15, 2021 at 8:16 PM Jason Ekstrand  wrote:
>
> On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri  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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On 6/16/21 1:16 PM, Jason Ekstrand wrote:


On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri  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?

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.
Fair enough. I don't really have any stake in these drivers, but I am 
eager to get to work on clean ups once we drop the classic drivers. I 
would be disappointed if we were forced to wait another year just to 
have the Intel drivers kept in the classic branch anyway. Going on past 
experience we can pretty much guarantee that someone will at least ask 
we keep them. Anyway up to you guys I guess.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri  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?
>
> 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.

--Jason


> --Jason
>
> On April 9, 2021 22:09:14 Dylan Baker  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.
>>>

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

[Timothy Arceri]

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  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@lists.freedesktop.org

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

[Jason Ekstrand]

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?

--Jason

On April 9, 2021 22:09:14 Dylan Baker  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Dylan Baker]

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

signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

Another thing is that glsl_to_tgsi is going to be removed but an old driver
may want to keep it. For this case, glsl_to_tgsi will be preserved in the
lts branch.

Marek

On Mon., Mar. 29, 2021, 18:59 Ilia Mirkin,  wrote:

> Probably nv30 would do well to "move on" as well. But it also presents
> an interesting question -- the nv30 driver has lots of problems. I
> have no plans to fix them, nor am I aware of anyone else with such
> plans. However if such a developer were to turn up, would it be
> reasonable to assume that their work would ultimately land in this
> "lts" branch/tree/whatever? Some of the "fixes" will require large-ish
> changes to the driver...
>
> Cheers,
>
>   -ilia
>
> On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák  wrote:
> >
> > Alright that's r300 and swr that are going to find a new home in the lts
> branch. Do any other gallium drivers want to join them?
> >
> > Marek
> >
> > On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan, 
> wrote:
> >>
> >> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> >> > Same thinking could be applied to other gallium drivers for old
> hardware that don't receive new development and are becoming more and more
> irrelevant every year due to their age.
> >>
> >> Can we also keep Gallium for OpenSWR driver on -lts branch? We
> currently are focusing effort on other OSS projects, and want to maintain
> OpenSWR at its current feature level, but we are often seeing Mesa core
> changes causing problems in OpenSWR, that we can’t always address right
> away. So, we would like to point our users to a stable branch, that limits
> the amount of effort required for OpenSWR to support its existing users.
> >>
> >> Jan
> >>
> >> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> >> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  robdcl...@gmail.com> wrote:
> >> > >
> >> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker  dy...@pnwbakers.com> 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
> >> > >
> >> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> >> > > gallium is already starting to get poked thru in the name of
> >> > > performance, and we've already discovered cases of classic drivers
> >> > > being broken for multiple months with no one noticing.  I think a
> >> > > slower moving -lts branch is the best approach to keeping things
> >> > > working for folks with older hw.
> >> > >
> >> > > But possibly there is some value in not completely disabling gallium
> >> > > completely in the -lts branch.  We do have some older gallium
> drivers
> >> > > which do not have CI coverage and I think are not used frequently by
> >> > > developers who are tracking the latest main/master branch.  I'm not
> >> > > suggesting that we remove them from the main (non-lts) branch but it
> >> > > might be useful to be able to recommend users of those drivers stick
> >> > > with the -lts version for better stability?
> >> >
> >> > I agree with this.  Generally, I don't think we should delete anything
> >> > from the -lts branch.  Doing so only risks more breakage.  We probably
> >> > want to change some meson build defaults to not build anything but old
> >> > drivers but that's it.
> >> >
> >> > --Jason
> >> >
> >> > > BR,
> >> > > -R
> >> > >
> >> > > > 6) We change the name and precidence of the glvnd loader file
> >> > > > 7) apply any build fixups (turn of intel generators for versions

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

[Ian Romanick]

On 3/25/21 3:13 PM, Jason Ekstrand wrote:
> On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke  wrote:
>>
>> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
>>> 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.
> 
> Hrm... That is a genuinely interesting extension on those platforms.
> From a "make it non-optional and dead-code" perspective, we can do
> that on mainline immediately post-fork easily enough.  Enabling it on
> legacy could be done separately.  If we wanted to also clean up the
> core on the legacy branch then, yeah, it'd have to be done twice.
> 
 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?
> 
> I think we should make a distinction between what users should expect
> and what devs are allowed to do.  It should be LTS from the
> perspective that users shouldn't expect new features.  Then again,
> they really shouldn't expect new features on those drivers anyway.
> ¯\_(ツ)_/¯
> 
>> That's a good point.  It's a bit expanded from "put out to pasture" so
>> maybe "-lts" isn't great.  We could call it "-classic", unless Marek
>> wants to include r300g in there too.  "-legacy" seems reasonable.  It
>> looks like NVIDIA has various "legacy" branches with a version number
>> based on the original version where things branched off from.
>>
>> So maybe we could do:
>>
>>- mesa-legacy21 21.1.X
>>
>> where X increments on every release without worrying whether it adds
>> features or simply bug fixes.  We figure true features and major
>> development will be pretty rare anyway.
> 
> Yeah, I don't know that we need to worry too much about stable vs.
> feature releases on the legacy branch.  If we still wanted a concept
> of major releases, we could slow it down to 1/year or something.
> Really, whatever makes it easiest for the release maintainers is fine
> with me.

Since I suspect Gentoo will be one of the few distros that carry this
branch for a long time, I asked Matt about this.  I think he's fine with
infrequent YY.MM or YY.QQ.xx type releases where the least significant
part is incremented for non-feature changes and the YY is incremented
every year regardless of the kind of change.

As long as I can continue to count on using the Intel CI from time to
time to test the legacy branch... I'm okay with splitting whenever.

 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?
>>
>> Post-fork, Intel CI would stop testing i965 on mainline obviously,
>> since it wouldn't exist there any longer.
>>
>> But I imagine it would add a new mesa_legacy21 job (like mesa_master)
>> which would still test i965 and i915, per-commit.  Clayton/Nico could
>> also add "dev/idr/legacy" branches which trigger testing on i965/i915
>> only.  The existing expected 

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

[Alyssa Rosenzweig]

> Probably nv30 would do well to "move on" as well. But it also presents
> an interesting question -- the nv30 driver has lots of problems. I
> have no plans to fix them, nor am I aware of anyone else with such
> plans. However if such a developer were to turn up, would it be
> reasonable to assume that their work would ultimately land in this
> "lts" branch/tree/whatever? Some of the "fixes" will require large-ish
> changes to the driver...

AFAIU, the issue isn't large changes to the driver, but large changes to
common code. So unless you're switching it to NIR or something, it
probably doesn't matter.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Clark]

I'm considering freedreno a2xx, although that is not a separate build
option from meson PoV.. I'd welcome arguments one way or another from
any stakeholder

(we also have a bit of a CI gap for a4xx.. although other than the
usual "shuffle all the registers/bitfields around" that we see between
gens it has a lot in common with a3xx/a5xx which do have CI coverage,
so I'm a bit less concerned about unintentionally breaking it)

BR,
-R

On Mon, Mar 29, 2021 at 3:48 PM Marek Olšák  wrote:
>
> Alright that's r300 and swr that are going to find a new home in the lts 
> branch. Do any other gallium drivers want to join them?
>
> Marek
>
> On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,  wrote:
>>
>> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
>> > Same thinking could be applied to other gallium drivers for old hardware 
>> > that don't receive new development and are becoming more and more 
>> > irrelevant every year due to their age.
>>
>> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently are 
>> focusing effort on other OSS projects, and want to maintain OpenSWR at its 
>> current feature level, but we are often seeing Mesa core changes causing 
>> problems in OpenSWR, that we can’t always address right away. So, we would 
>> like to point our users to a stable branch, that limits the amount of effort 
>> required for OpenSWR to support its existing users.
>>
>> Jan
>>
>> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
>> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  
>> > wrote:
>> > >
>> > > On Mon, Mar 22, 2021 at 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
>> > >
>> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
>> > > gallium is already starting to get poked thru in the name of
>> > > performance, and we've already discovered cases of classic drivers
>> > > being broken for multiple months with no one noticing.  I think a
>> > > slower moving -lts branch is the best approach to keeping things
>> > > working for folks with older hw.
>> > >
>> > > But possibly there is some value in not completely disabling gallium
>> > > completely in the -lts branch.  We do have some older gallium drivers
>> > > which do not have CI coverage and I think are not used frequently by
>> > > developers who are tracking the latest main/master branch.  I'm not
>> > > suggesting that we remove them from the main (non-lts) branch but it
>> > > might be useful to be able to recommend users of those drivers stick
>> > > with the -lts version for better stability?
>> >
>> > I agree with this.  Generally, I don't think we should delete anything
>> > from the -lts branch.  Doing so only risks more breakage.  We probably
>> > want to change some meson build defaults to not build anything but old
>> > drivers but that's it.
>> >
>> > --Jason
>> >
>> > > BR,
>> > > -R
>> > >
>> > > > 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 

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

[Jason Ekstrand]

On Mon, Mar 29, 2021 at 5:59 PM Ilia Mirkin  wrote:
>
> Probably nv30 would do well to "move on" as well. But it also presents
> an interesting question -- the nv30 driver has lots of problems. I
> have no plans to fix them, nor am I aware of anyone else with such
> plans. However if such a developer were to turn up, would it be
> reasonable to assume that their work would ultimately land in this
> "lts" branch/tree/whatever? Some of the "fixes" will require large-ish
> changes to the driver...

I think that's fine.  I've said before that my definition of "LTS" is
more "it no longer picks up bugs and improvements to core from the
active dev work on master" more than "long-term stable".  I'm fine if
someone wants to fix things or even add features on the LTS branch.
And if a driver goes from virtually zero maintenance to active
development again, it can move back to main; it just may need a little
updating.

--Jason


> Cheers,
>
>   -ilia
>
> On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák  wrote:
> >
> > Alright that's r300 and swr that are going to find a new home in the lts 
> > branch. Do any other gallium drivers want to join them?
> >
> > Marek
> >
> > On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,  
> > wrote:
> >>
> >> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> >> > Same thinking could be applied to other gallium drivers for old hardware 
> >> > that don't receive new development and are becoming more and more 
> >> > irrelevant every year due to their age.
> >>
> >> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently 
> >> are focusing effort on other OSS projects, and want to maintain OpenSWR at 
> >> its current feature level, but we are often seeing Mesa core changes 
> >> causing problems in OpenSWR, that we can’t always address right away. So, 
> >> we would like to point our users to a stable branch, that limits the 
> >> amount of effort required for OpenSWR to support its existing users.
> >>
> >> Jan
> >>
> >> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> >> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  
> >> > wrote:
> >> > >
> >> > > On Mon, Mar 22, 2021 at 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
> >> > >
> >> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> >> > > gallium is already starting to get poked thru in the name of
> >> > > performance, and we've already discovered cases of classic drivers
> >> > > being broken for multiple months with no one noticing.  I think a
> >> > > slower moving -lts branch is the best approach to keeping things
> >> > > working for folks with older hw.
> >> > >
> >> > > But possibly there is some value in not completely disabling gallium
> >> > > completely in the -lts branch.  We do have some older gallium drivers
> >> > > which do not have CI coverage and I think are not used frequently by
> >> > > developers who are tracking the latest main/master branch.  I'm not
> >> > > suggesting that we remove them from the main (non-lts) branch but it
> >> > > might be useful to be able to recommend users of those drivers stick
> >> > > with the -lts version for better stability?
> >> >
> >> > I agree with this.  Generally, I don't think we should delete anything
> >> > from the -lts branch.  

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

[Ilia Mirkin]

Probably nv30 would do well to "move on" as well. But it also presents
an interesting question -- the nv30 driver has lots of problems. I
have no plans to fix them, nor am I aware of anyone else with such
plans. However if such a developer were to turn up, would it be
reasonable to assume that their work would ultimately land in this
"lts" branch/tree/whatever? Some of the "fixes" will require large-ish
changes to the driver...

Cheers,

  -ilia

On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák  wrote:
>
> Alright that's r300 and swr that are going to find a new home in the lts 
> branch. Do any other gallium drivers want to join them?
>
> Marek
>
> On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,  wrote:
>>
>> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
>> > Same thinking could be applied to other gallium drivers for old hardware 
>> > that don't receive new development and are becoming more and more 
>> > irrelevant every year due to their age.
>>
>> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently are 
>> focusing effort on other OSS projects, and want to maintain OpenSWR at its 
>> current feature level, but we are often seeing Mesa core changes causing 
>> problems in OpenSWR, that we can’t always address right away. So, we would 
>> like to point our users to a stable branch, that limits the amount of effort 
>> required for OpenSWR to support its existing users.
>>
>> Jan
>>
>> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
>> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  
>> > wrote:
>> > >
>> > > On Mon, Mar 22, 2021 at 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
>> > >
>> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
>> > > gallium is already starting to get poked thru in the name of
>> > > performance, and we've already discovered cases of classic drivers
>> > > being broken for multiple months with no one noticing.  I think a
>> > > slower moving -lts branch is the best approach to keeping things
>> > > working for folks with older hw.
>> > >
>> > > But possibly there is some value in not completely disabling gallium
>> > > completely in the -lts branch.  We do have some older gallium drivers
>> > > which do not have CI coverage and I think are not used frequently by
>> > > developers who are tracking the latest main/master branch.  I'm not
>> > > suggesting that we remove them from the main (non-lts) branch but it
>> > > might be useful to be able to recommend users of those drivers stick
>> > > with the -lts version for better stability?
>> >
>> > I agree with this.  Generally, I don't think we should delete anything
>> > from the -lts branch.  Doing so only risks more breakage.  We probably
>> > want to change some meson build defaults to not build anything but old
>> > drivers but that's it.
>> >
>> > --Jason
>> >
>> > > BR,
>> > > -R
>> > >
>> > > > 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 

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

[Marek Olšák]

Alright that's r300 and swr that are going to find a new home in the lts
branch. Do any other gallium drivers want to join them?

Marek

On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan, 
wrote:

> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> > Same thinking could be applied to other gallium drivers for old hardware
> that don't receive new development and are becoming more and more
> irrelevant every year due to their age.
>
> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently
> are focusing effort on other OSS projects, and want to maintain OpenSWR at
> its current feature level, but we are often seeing Mesa core changes
> causing problems in OpenSWR, that we can’t always address right away. So,
> we would like to point our users to a stable branch, that limits the amount
> of effort required for OpenSWR to support its existing users.
>
> Jan
>
> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark 
> wrote:
> > >
> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker  dy...@pnwbakers.com> 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
> > >
> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > > gallium is already starting to get poked thru in the name of
> > > performance, and we've already discovered cases of classic drivers
> > > being broken for multiple months with no one noticing.  I think a
> > > slower moving -lts branch is the best approach to keeping things
> > > working for folks with older hw.
> > >
> > > But possibly there is some value in not completely disabling gallium
> > > completely in the -lts branch.  We do have some older gallium drivers
> > > which do not have CI coverage and I think are not used frequently by
> > > developers who are tracking the latest main/master branch.  I'm not
> > > suggesting that we remove them from the main (non-lts) branch but it
> > > might be useful to be able to recommend users of those drivers stick
> > > with the -lts version for better stability?
> >
> > I agree with this.  Generally, I don't think we should delete anything
> > from the -lts branch.  Doing so only risks more breakage.  We probably
> > want to change some meson build defaults to not build anything but old
> > drivers but that's it.
> >
> > --Jason
> >
> > > BR,
> > > -R
> > >
> > > > 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
> > > > 

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

[Zielinski, Jan]

On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> Same thinking could be applied to other gallium drivers for old hardware that 
> don't receive new development and are becoming more and more irrelevant every 
> year due to their age.

Can we also keep Gallium for OpenSWR driver on -lts branch? We currently are 
focusing effort on other OSS projects, and want to maintain OpenSWR at its 
current feature level, but we are often seeing Mesa core changes causing 
problems in OpenSWR, that we can’t always address right away. So, we would like 
to point our users to a stable branch, that limits the amount of effort 
required for OpenSWR to support its existing users.

Jan

On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
> >
> > On Mon, Mar 22, 2021 at 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
> >
> > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > gallium is already starting to get poked thru in the name of
> > performance, and we've already discovered cases of classic drivers
> > being broken for multiple months with no one noticing.  I think a
> > slower moving -lts branch is the best approach to keeping things
> > working for folks with older hw.
> >
> > But possibly there is some value in not completely disabling gallium
> > completely in the -lts branch.  We do have some older gallium drivers
> > which do not have CI coverage and I think are not used frequently by
> > developers who are tracking the latest main/master branch.  I'm not
> > suggesting that we remove them from the main (non-lts) branch but it
> > might be useful to be able to recommend users of those drivers stick
> > with the -lts version for better stability?
> 
> I agree with this.  Generally, I don't think we should delete anything
> from the -lts branch.  Doing so only risks more breakage.  We probably
> want to change some meson build defaults to not build anything but old
> drivers but that's it.
> 
> --Jason
> 
> > BR,
> > -R
> >
> > > 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 

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

[Rob Clark]

On Thu, Mar 25, 2021 at 2:12 PM Kenneth Graunke  wrote:
>
> On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> > Other than the minor detail that we don't have pci-id's to
> > differentiate between adreno generations, I might suggest a2xx users
> > to use -lts
> >
> > BR,
> > -R
>
> Could it be set up such that freedreno in mainline fails to load on
> a2xx (and you could delete such code), while freedreno in -lts fails
> to load on a3xx+?  Basically, don't have any overlapping HW support
> in both branches.
>
> --Ken

ahh, if glvnd moves on to try the next driver after the first one
fails, that would work perfectly.  Not sure if I'd remove the code
from mainline but might hide it behind a debug flag.  Haven't thought
it through too much yet, since I assumed it would require teaching
glvnd new things.  But it would be nice to worry less about breaking
things that aren't in CI and not easy to test.

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke  wrote:
>
> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> > 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.

Hrm... That is a genuinely interesting extension on those platforms.
From a "make it non-optional and dead-code" perspective, we can do
that on mainline immediately post-fork easily enough.  Enabling it on
legacy could be done separately.  If we wanted to also clean up the
core on the legacy branch then, yeah, it'd have to be done twice.

> > > 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?

I think we should make a distinction between what users should expect
and what devs are allowed to do.  It should be LTS from the
perspective that users shouldn't expect new features.  Then again,
they really shouldn't expect new features on those drivers anyway.
¯\_(ツ)_/¯

> That's a good point.  It's a bit expanded from "put out to pasture" so
> maybe "-lts" isn't great.  We could call it "-classic", unless Marek
> wants to include r300g in there too.  "-legacy" seems reasonable.  It
> looks like NVIDIA has various "legacy" branches with a version number
> based on the original version where things branched off from.
>
> So maybe we could do:
>
>- mesa-legacy21 21.1.X
>
> where X increments on every release without worrying whether it adds
> features or simply bug fixes.  We figure true features and major
> development will be pretty rare anyway.

Yeah, I don't know that we need to worry too much about stable vs.
feature releases on the legacy branch.  If we still wanted a concept
of major releases, we could slow it down to 1/year or something.
Really, whatever makes it easiest for the release maintainers is fine
with me.

> > > 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?
>
> Post-fork, Intel CI would stop testing i965 on mainline obviously,
> since it wouldn't exist there any longer.
>
> But I imagine it would add a new mesa_legacy21 job (like mesa_master)
> which would still test i965 and i915, per-commit.  Clayton/Nico could
> also add "dev/idr/legacy" branches which trigger testing on i965/i915
> only.  The existing expected results files would continue to work.

I think this should work fine.  It would end up being more like once
per piglit MR rather than once per mesa MR since the cadence on the
legacy branch should slow to a crawl.

If anything, it might make testing easier since you'll have the whole
pre-gen8 farm to yourself if you're hacking on the legacy branch. 

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kenneth Graunke]

On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
[snip]
> > 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?

That's a good point.  It's a bit expanded from "put out to pasture" so
maybe "-lts" isn't great.  We could call it "-classic", unless Marek
wants to include r300g in there too.  "-legacy" seems reasonable.  It
looks like NVIDIA has various "legacy" branches with a version number
based on the original version where things branched off from.

So maybe we could do:

   - mesa-legacy21 21.1.X

where X increments on every release without worrying whether it adds
features or simply bug fixes.  We figure true features and major
development will be pretty rare anyway.

> > 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?

Post-fork, Intel CI would stop testing i965 on mainline obviously,
since it wouldn't exist there any longer.

But I imagine it would add a new mesa_legacy21 job (like mesa_master)
which would still test i965 and i915, per-commit.  Clayton/Nico could
also add "dev/idr/legacy" branches which trigger testing on i965/i915
only.  The existing expected results files would continue to work.

Then testing would be pretty similar to today, you'd just have a
different dev branch for targeting master (testing anv and iris)
or legacy21 (testign i915 and i965).

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kenneth Graunke]

On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> Other than the minor detail that we don't have pci-id's to
> differentiate between adreno generations, I might suggest a2xx users
> to use -lts
> 
> BR,
> -R

Could it be set up such that freedreno in mainline fails to load on
a2xx (and you could delete such code), while freedreno in -lts fails
to load on a3xx+?  Basically, don't have any overlapping HW support
in both branches.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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  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 

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

[Marek Olšák]

On Thu., Mar. 25, 2021, 12:14 Dylan Baker,  wrote:

> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from
> Meson. Maybe it makes sense to keep gallium for r300? But how many r300
> breakages have we had in recent memory?
>

We don't have any recent information on the status of r300. Splitting it
would be wise.

Same thinking could be applied to other gallium drivers for old hardware
that don't receive new development and are becoming more and more
irrelevant every year due to their age.

Marek


> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
> > >
> > > On Mon, Mar 22, 2021 at 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
> > >
> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > > gallium is already starting to get poked thru in the name of
> > > performance, and we've already discovered cases of classic drivers
> > > being broken for multiple months with no one noticing.  I think a
> > > slower moving -lts branch is the best approach to keeping things
> > > working for folks with older hw.
> > >
> > > But possibly there is some value in not completely disabling gallium
> > > completely in the -lts branch.  We do have some older gallium drivers
> > > which do not have CI coverage and I think are not used frequently by
> > > developers who are tracking the latest main/master branch.  I'm not
> > > suggesting that we remove them from the main (non-lts) branch but it
> > > might be useful to be able to recommend users of those drivers stick
> > > with the -lts version for better stability?
> >
> > I agree with this.  Generally, I don't think we should delete anything
> > from the -lts branch.  Doing so only risks more breakage.  We probably
> > want to change some meson build defaults to not build anything but old
> > drivers but that's it.
> >
> > --Jason
> >
> > > BR,
> > > -R
> > >
> > > > 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 

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

[Jason Ekstrand]

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,
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."

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.

--Jason

On Tue, Mar 23, 2021 at 3:26 AM Ian Romanick  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
> >
> >
> > ___
> > mesa-dev mailing list
> > 

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

[Rob Clark]

Other than the minor detail that we don't have pci-id's to
differentiate between adreno generations, I might suggest a2xx users
to use -lts

BR,
-R

On Thu, Mar 25, 2021 at 9:14 AM Dylan Baker  wrote:
>
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. 
> Maybe it makes sense to keep gallium for r300? But how many r300 breakages 
> have we had in recent memory?
>
> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
> > >
> > > On Mon, Mar 22, 2021 at 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
> > >
> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > > gallium is already starting to get poked thru in the name of
> > > performance, and we've already discovered cases of classic drivers
> > > being broken for multiple months with no one noticing.  I think a
> > > slower moving -lts branch is the best approach to keeping things
> > > working for folks with older hw.
> > >
> > > But possibly there is some value in not completely disabling gallium
> > > completely in the -lts branch.  We do have some older gallium drivers
> > > which do not have CI coverage and I think are not used frequently by
> > > developers who are tracking the latest main/master branch.  I'm not
> > > suggesting that we remove them from the main (non-lts) branch but it
> > > might be useful to be able to recommend users of those drivers stick
> > > with the -lts version for better stability?
> >
> > I agree with this.  Generally, I don't think we should delete anything
> > from the -lts branch.  Doing so only risks more breakage.  We probably
> > want to change some meson build defaults to not build anything but old
> > drivers but that's it.
> >
> > --Jason
> >
> > > BR,
> > > -R
> > >
> > > > 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 

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

[Dylan Baker]

By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. 
Maybe it makes sense to keep gallium for r300? But how many r300 breakages have 
we had in recent memory?

On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
> >
> > On Mon, Mar 22, 2021 at 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
> >
> > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > gallium is already starting to get poked thru in the name of
> > performance, and we've already discovered cases of classic drivers
> > being broken for multiple months with no one noticing.  I think a
> > slower moving -lts branch is the best approach to keeping things
> > working for folks with older hw.
> >
> > But possibly there is some value in not completely disabling gallium
> > completely in the -lts branch.  We do have some older gallium drivers
> > which do not have CI coverage and I think are not used frequently by
> > developers who are tracking the latest main/master branch.  I'm not
> > suggesting that we remove them from the main (non-lts) branch but it
> > might be useful to be able to recommend users of those drivers stick
> > with the -lts version for better stability?
> 
> I agree with this.  Generally, I don't think we should delete anything
> from the -lts branch.  Doing so only risks more breakage.  We probably
> want to change some meson build defaults to not build anything but old
> drivers but that's it.
> 
> --Jason
> 
> > BR,
> > -R
> >
> > > 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___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > 

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

[Dylan Baker]

Maybe I could have been clearer, but I meant "We only guarantee that we'll keep 
the build working and that major security problems get fixed", If you or 
someone else wants to fix other issues that's fine, but I meant if someone says 
"i915c is too slow for some workload", we reserve the right to close that as 
EWONTFIX.

On Tue, Mar 23, 2021, at 01:26, Ian Romanick 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
> > 
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> 
>

-- 
  Dylan Baker
  dy...@pnwbakers.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
>
> On Mon, Mar 22, 2021 at 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
>
> I'm +1 for the -lts branch.. the layering between mesa "classic" and
> gallium is already starting to get poked thru in the name of
> performance, and we've already discovered cases of classic drivers
> being broken for multiple months with no one noticing.  I think a
> slower moving -lts branch is the best approach to keeping things
> working for folks with older hw.
>
> But possibly there is some value in not completely disabling gallium
> completely in the -lts branch.  We do have some older gallium drivers
> which do not have CI coverage and I think are not used frequently by
> developers who are tracking the latest main/master branch.  I'm not
> suggesting that we remove them from the main (non-lts) branch but it
> might be useful to be able to recommend users of those drivers stick
> with the -lts version for better stability?

I agree with this.  Generally, I don't think we should delete anything
from the -lts branch.  Doing so only risks more breakage.  We probably
want to change some meson build defaults to not build anything but old
drivers but that's it.

--Jason

> BR,
> -R
>
> > 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___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Clark]

On Mon, Mar 22, 2021 at 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

I'm +1 for the -lts branch.. the layering between mesa "classic" and
gallium is already starting to get poked thru in the name of
performance, and we've already discovered cases of classic drivers
being broken for multiple months with no one noticing.  I think a
slower moving -lts branch is the best approach to keeping things
working for folks with older hw.

But possibly there is some value in not completely disabling gallium
completely in the -lts branch.  We do have some older gallium drivers
which do not have CI coverage and I think are not used frequently by
developers who are tracking the latest main/master branch.  I'm not
suggesting that we remove them from the main (non-lts) branch but it
might be useful to be able to recommend users of those drivers stick
with the -lts version for better stability?

BR,
-R

> 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___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Alyssa Rosenzweig]

> And, yeah, I'd love to drop vec4 but yeah...  One advantage to keeping
> vec4 in the tree for some stuff is that it means we have full-featured
> hardware able to test vec4 NIR.  That seems like a feature.

I have to keep caring about Midgard for the next indefinitely so please
don't break vec4 NIR ;-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

+1

We still have some CPU overhead performance targets we haven't reached. One
of them is to decrease CPU overhead for one benchmark 4 times compared to
everything we already have in master. I don't know how we are going to do
that, but we'll try.

Marek

On Mon, Mar 22, 2021 at 6: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___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Tue, Mar 23, 2021 at 8:39 AM Kenneth Graunke  wrote:
>
> On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> > On March 23, 2021 01:46:54 Kenneth Graunke  wrote:
> [snip]
> > > One extra thought: can we also fork off anv Gen7.x support at the same
> > > time?  If distros are already going to be building i965 for Gen7.x from
> > > that branch, building Vulkan from there should be easy as well.
> >
> > I'm not sure how I feel about that one. Here are some thoughts:
> >
> >  1. I'd love to have it out of the way
> >  2. Unlike i965, it is still picking up features. Part of what makes
> > dropping i965 a reasonable idea is that OpenGL is also in maintenance mode.
> > Vulkan isn't.
> >  3. Generally, things are architected well enough that relocations aren't a
> > problem.
> >  4. Being able to always do batch chaining would be nice.
> >  5. The only new feature still in development for i965 is
> > GL_EXT_external_objects. That would be more reliable if Gen7 ANV and i965
> > were in the same branch.
> >  6. If crocus gets GL_EXT_external_objects, it'll be better if Gen7 ANV is
> > in the master branch.
> >  7. I'd love to stop caring about vec4.
>
> Point 2 is true.  I'm not sure I agree about 3, the anv execbuf handling
> is a lot more complicated than I think it needs to be.

It's not great, I'll grant.  But it's not too awful and, until we get
rid of VM_BIND, we have to at least keep BO usage tracking even if we
were able to drop relocations.

> It would be really nice to cull vec4 and MRF support from the compiler
> as well---and all of the vec4/fs code sharing and base classes.  That
> would be really nice.  But, I guess that if crocus comes into existence,
> then we need all that again.  That's unfortunate :(

Me too.  There is some stuff I think we can drop.  We can drop
shader_time, for instance, as well as the param array and all the push
constant re-arranging code.

And, yeah, I'd love to drop vec4 but yeah...  One advantage to keeping
vec4 in the tree for some stuff is that it means we have full-featured
hardware able to test vec4 NIR.  That seems like a feature.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On 3/23/21 7:26 PM, Ian Romanick 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.


Is there any reason these could not just land in the forked classic 
branch? The consensus seems to be we would still be making the odd 
release of these forked drivers, unlike how the DRI1 drivers were put 
out to pasture. Ken already outlined a desire to still be able to add 
occasional features to i965.


There is real momentum around cleaning up and optimising core Mesa at 
the moment, I'd really hate to see that slow down just because of a self 
imposed rule on what changes can land in a forked classic branch. I 
can't see there being to many MRs and releases required whether we 
applied a strict "build and critical bug fixes only" policy or just let 
any reasonable MR be accepted. I mean its not like there are MR flowing 
in for classic drivers now.


Just to be clear I'm +1 for forking 21.1.


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


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kenneth Graunke]

On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> On March 23, 2021 01:46:54 Kenneth Graunke  wrote:
[snip]
> > One extra thought: can we also fork off anv Gen7.x support at the same
> > time?  If distros are already going to be building i965 for Gen7.x from
> > that branch, building Vulkan from there should be easy as well.
> 
> I'm not sure how I feel about that one. Here are some thoughts:
> 
>  1. I'd love to have it out of the way
>  2. Unlike i965, it is still picking up features. Part of what makes 
> dropping i965 a reasonable idea is that OpenGL is also in maintenance mode. 
> Vulkan isn't.
>  3. Generally, things are architected well enough that relocations aren't a 
> problem.
>  4. Being able to always do batch chaining would be nice.
>  5. The only new feature still in development for i965 is 
> GL_EXT_external_objects. That would be more reliable if Gen7 ANV and i965 
> were in the same branch.
>  6. If crocus gets GL_EXT_external_objects, it'll be better if Gen7 ANV is 
> in the master branch.
>  7. I'd love to stop caring about vec4.

Point 2 is true.  I'm not sure I agree about 3, the anv execbuf handling
is a lot more complicated than I think it needs to be.

It would be really nice to cull vec4 and MRF support from the compiler
as well---and all of the vec4/fs code sharing and base classes.  That
would be really nice.  But, I guess that if crocus comes into existence,
then we need all that again.  That's unfortunate :(

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On March 23, 2021 01:46:54 Kenneth Graunke  wrote:


On Monday, March 22, 2021 3:15:30 PM PDT 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


Hi Dylan,

I largely like this plan.  i915 and r200 and novueau_vieux definitely
need to be forked off, to keep them working as we do core refactors.

In the past, we weren't working on core much, and so they largely kept
working with some pain, but not -too- much effort.  But these days,
we're seeing a lot of work from Marek and others to clean up and rework
a lot of core drawing code, state upload code, and so on.  I remember
all the work Tim did to rework uniform handling and ancient classic was
a pain point for him as well.  I had to track down like 5 overlapping
Piglit regressions on i915 this release cycle, just to get the driver
working...no worse than it was before.  And i915 is tested regularly
in the Intel CI.  r200 isn't tested regularly.  Doubtful about vieux.

I had thought about also forking other old drivers like i915g or r300g.
But it sounds like there's still some interest in i915g, and those
tend to get fixed up as the Gallium infrastructure is still actively
being maintained (unlike things like swrast and tnl).  So I guess we
can leave those in mainline.

I'm hesitant about i965.  One thing I will say is that, if i965 is
included in the plan, there would probably be more interest in working
on that branch than mere "critical bug fixes" as you defined.  We might
discover new games that don't work; people might write bug fixes for
i965, at which point we should merge and ship them.  But we could still
do on-demand releases when enough interesting bug fixes have piled up,
rather than doing them on a schedule.  That should hopefully not be
too burdensome.

While a part of me hates the idea of forking i965 off, I think it may
actually be the best call.  We haven't done any new interesting feature
development on those platforms in ages, and they're complete in terms of
OpenGL spec support.  We aren't spending any time optimizing performance
on those platforms.  They're pretty much in bug-fix-only mode already.
Whether that bug fixing happens on master or on a "classic-lts" branch
doesn't matter; it 

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

[Alyssa Rosenzweig]

I'd like to see it happen, though I don't understand how to make these
coexist for distros. Would like to hear from the Debian/etc maintainers
of mesa.

Then again I *think* classic-lts doesn't need to be built for
armhf/arm64 at all, so I suppose I'm personally unaffected :-P

On Mon, Mar 22, 2021 at 03:15:30PM -0700, 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



> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ian Romanick]

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
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kenneth Graunke]

On Monday, March 22, 2021 3:15:30 PM PDT 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

Hi Dylan,

I largely like this plan.  i915 and r200 and novueau_vieux definitely
need to be forked off, to keep them working as we do core refactors.

In the past, we weren't working on core much, and so they largely kept
working with some pain, but not -too- much effort.  But these days,
we're seeing a lot of work from Marek and others to clean up and rework
a lot of core drawing code, state upload code, and so on.  I remember
all the work Tim did to rework uniform handling and ancient classic was
a pain point for him as well.  I had to track down like 5 overlapping
Piglit regressions on i915 this release cycle, just to get the driver
working...no worse than it was before.  And i915 is tested regularly
in the Intel CI.  r200 isn't tested regularly.  Doubtful about vieux.

I had thought about also forking other old drivers like i915g or r300g.
But it sounds like there's still some interest in i915g, and those
tend to get fixed up as the Gallium infrastructure is still actively
being maintained (unlike things like swrast and tnl).  So I guess we
can leave those in mainline.

I'm hesitant about i965.  One thing I will say is that, if i965 is
included in the plan, there would probably be more interest in working
on that branch than mere "critical bug fixes" as you defined.  We might
discover new games that don't work; people might write bug fixes for
i965, at which point we should merge and ship them.  But we could still
do on-demand releases when enough interesting bug fixes have piled up,
rather than doing them on a schedule.  That should hopefully not be
too burdensome.

While a part of me hates the idea of forking i965 off, I think it may
actually be the best call.  We haven't done any new interesting feature
development on those platforms in ages, and they're complete in terms of
OpenGL spec support.  We aren't spending any time optimizing performance
on those platforms.  They're pretty much in bug-fix-only mode already.
Whether 

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

[Jason Ekstrand]

+1. I'd we think GLVND and X are ready for this, I think it's a good plan.

On March 22, 2021 17:34:09 Eric Anholt  wrote:


On Mon, Mar 22, 2021 at 3:27 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


I would like it if Intel could avoid garbage-collecting older-HW
shared code for at least a release due aforementioned WIPs, but I
think it's time to call the classic i965_dri.so and i915_dri.so done.


I'm happy to leave older hardware support in the tree for now. We need to 
keep the vec4 compiler for HSW Vulkan support for now and there's no harm 
in keeping old hardware support in ISL. I'm a little tempted to let HSW 
Vulkan bitrot in the LTS branch too but it does still pick up features here 
and there so I'm unsure if that's a good idea or not.


--Jason



+1 from me assuming that we validate that one can actually get a
working X server with the mesa-legacy set installed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Anholt]

On Mon, Mar 22, 2021 at 3:27 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

I would like it if Intel could avoid garbage-collecting older-HW
shared code for at least a release due aforementioned WIPs, but I
think it's time to call the classic i965_dri.so and i915_dri.so done.

+1 from me assuming that we validate that one can actually get a
working X server with the mesa-legacy set installed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev