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
