As for loading, doesn't glvnd solve that? On Sun, Mar 29, 2020, 1:19 AM Marek Olšák <mar...@gmail.com> wrote:
> If you want a complete fork or removal, that's fine with me. It's > technically more challenging for driver loaders and packaging though. > > Marek > > On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand, <ja...@jlekstrand.net> > wrote: > >> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák <mar...@gmail.com> wrote: >> > >> > 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. >> >> If we make sure that we modify the #include guards on every header in >> src/mesa_classic so that any accidental cross-includes lead to double >> definitions and therefore compile errors, that would probably help. >> It'd certainly give me a lot more confidence that we've done it right. >> >> > The biggest part is to make src/compiler completely independent and >> that's a worthy goal by itself. >> >> Yeah, I've wanted to see that happen since we started splitting stuff >> out to make Vulkan a possibility. >> >> > Milestones: >> > - make src/compiler a standalone lib >> > - don't include src/mesa in other places >> > - split classic drivers into src/mesa_classic >> >> If you're willing to do the work, I guess I'm not opposed for now. >> >> That said, I also have some somewhat selfish reasons for wanting to do >> a fork. In particular, I'd like to freeze i965 and possibly Gen7 >> Vulkan in time so that we can stop maintaining the i965 and the old >> vec4 back-end compiler. Even though we're not adding features, I >> still find myself having to fix those up from time to time due to >> reworks elsewhere. Maybe the answer is to copy and isolate them too >> but, at that point, why not just put them in a branch? >> >> --Jason >> >> >> > 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
