[Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On 2019-12-04 at 18:54, Dylan Baker <dylan at pnwbakers.com> wrote:
> Quoting Kristian Høgsberg (2019-12-04 10:43:46)
> > On Wed, Dec 4, 2019 at 10:31 AM Rob Clark <robdclark at gmail.com> wrote:
> > >
> > > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt <eric at anholt.net> wrote:
> > > >
> > > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák <maraeo at gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Here are 2 proposals to simplify and better optimize the GL->Gallium translation.
> > > > >
> > > > > 1) Move classic drivers to a fork of Mesa, and remove them from master. Classic drivers won't share any code with master. glvnd will load them, but glvnd is not ready for this yet.
> > > > >
> > > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target location.
> > > > >
> > > > > Option 2 is more acceptable to people who want to keep classic drivers in the tree and it can be done right now.
> > > >
> > > > (resending reply-all)
> > > >
> > > > I object to both of these. They increase work for Mesa folks like me
> > > > who do tree-wide work.
> > > >
> > > > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > > > the technical debt that we built with gallium copying so much of
> > > > src/mesa/main, and saying "let's go duplicate more code so we can do
> > > > some unspecified optimization work" gets me really upset.
> > >
> > > tbf option #1 would be a copy of the code.. but a copy that we'd
> > > (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> > > If we started refactoring the legacy fork, that would strongly defeat
> > > the purpose of having it!
> > >
> > > Given that we don't have most of the classic drivers (other than i965)
> > > in CI, and presumably not many folks who are tracking master test the
> > > old classic drivers, moving them off to a fork seems to me to
> > > significantly reduce the risk of refactorings (whether it be for perf
> > > or for cleanup).
> > 
> > Another option would be to do a LTS-kind of release of mesa and then
> > drop the non-gallium drivers. It could even be limited in scope to the
> > non-gallium drivers, in the sense that we'd only do releases for fixes
> > to those drivers. It's basically option 1), but saying that we still
> > care about maintaining the drivers, but they wont receive new
> > features. With i965 being at GL 4.6, I don't think that's an
> > unreasonable stance (contrast with years ago when i965 feature level
> > was lagging the hw capability and spec).
> 
> This is what I was trying to propose when I proposed this, basically just
> security fixes, major bugs, and build breakages. And the release would straight
> up disable gallium drivers and vulkan drivers (unless Jason wanted to drop <
> gen8 from anv at the same time?) This isn't really all that different than what
> we did in mesa 7 with the dri1 drivers, just using glvnd as the loader instead
> of the mesa loader.

Yes, this as the last release before we delete the classic drivers is the best option IMO 👍

> 
> I really had thought of this as a something to do toward the end of next year or
> early 2021, not something to do immediately. Given another 6-18 months Haswell
> will have gone from pretty old to really old, and hopefully less interesting to
> people.
> 
> Dylan
> 
> > 
> > At the end of the day, it will impact the Intel team the most and I
> > think it's largely their call.
> > 
> > Kristian
> > 
> > >
> > > BR,
> > > -R