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. 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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
