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

Sun Apr 4 09:33:11 UTC 2021

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, <imirkin at alum.mit.edu> 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 <maraeo at gmail.com> 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, <jan.zielinski at intel.com>
> 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 <mailto:
> robdclark at gmail.com> wrote:
> >> > >
> >> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <mailto:
> dylan at 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
> >> > > > 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
> >> > > > mailto:mesa-dev at lists.freedesktop.org
> >> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> > > _______________________________________________
> >> > > mesa-dev mailing list
> >> > > mailto:mesa-dev at lists.freedesktop.org
> >> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >
> >>
> >> --
> >>   Dylan Baker
> >>   mailto:dylan at pnwbakers.com
> >> _______________________________________________
> >> mesa-dev mailing list
> >> mailto:mesa-dev at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> Intel Technology Poland sp. z o.o.
> >> ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia
> Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 |
> Kapita zakadowy 200.000 PLN.
> >> Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata
> i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej
> wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie;
> jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione.
> >> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210404/c8c8ddc8/attachment.htm>