The #include spaghetti will be resolved before the split. I don't care about including gallium, but no code will include src/mesa outside of that. The biggest part is to make src/compiler completely independent and that's a worthy goal by itself.
Milestones: - make src/compiler a standalone lib - don't include src/mesa in other places - split classic drivers into src/mesa_classic Marek On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, <ja...@jlekstrand.net> wrote: > On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák <mar...@gmail.com> wrote: > > > > > > > > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke <kenn...@whitecape.org> > wrote: > >> > >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák 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. > >> > > >> > Opinions? > >> > > >> > Thanks, > >> > Marek > >> > >> FWIW, I am not in favor of either plan for the time being. > >> > >> - I agree with Eric that we're finally starting to clean up and > >> de-duplicate things, and pay off technical debt we've put off for > >> a long time. I think forking everything in-tree would just be a > >> giant mess. > >> > >> - I agree with Dave that this seems to be a giant hassle for our > >> downstreams with little benefit for them in the short term. > > > > > > If classic drivers were moved to src/mesa_classic, nothing would change > for downstream. > > I'm concerned that doing that is just asking for more maintenance > problems than we have today. One of the problems we currently have is > that our #includes are still spaghetti. We've got stuff in src/util > which inclues stuff in gallium as well as stuff in mesa/main. If we > even have one cross-wired include, it could lead to bezar and nearly > impossible to trace bugs due to ABI incompatibility between the two > copies of src/mesa the moment we start changing structs or function > prototypes. The obvious answer to this is "we'll sort out the > spaghetti mess". However, that also means serious changes to > src/compiler/glsl because it includes mtypes.h. Do we clone that too? > I honestly think that this particular cure is likely far worse than > the disease of having to do careful testing of src/mesa changes. > > IMO, a far better plan would be to give it one more year so that > distros and users get experience with iris and then fork off an LTS > branch and delete all the legacy stuff from master. We can continue > to do maintenance in the LTS branch as needed but I honestly don't > expect much work to happen there. The most difficult thing will be > deciding what to remove from master but I don't want to make that > decision today. However, doing a clean fork means we don't have to > worry about cross-contamination in shared code causing weird issues > because they're in separate branches. We will have to figure out a > few loader issues to ensure that the master drivers get preferred over > the LTS ones or somehow disable all master drivers in the LTS branch. > > --Jason >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
