On 2019-12-04 at 18:54, Dylan Baker <dy...@pnwbakers.com> wrote: > Quoting Kristian Høgsberg (2019-12-04 10:43:46) > > On Wed, Dec 4, 2019 at 10:31 AM Rob Clark <robdcl...@gmail.com> wrote: > > > > > > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt <e...@anholt.net> wrote: > > > > > > > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
