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

[Dylan Baker]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191204/86f7fc32/attachment-0001.sig>