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

2021-03-22 Thread Dylan Baker
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

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

2021-03-22 Thread 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


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

2021-03-22 Thread 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

2021-03-22 Thread 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 th