[Mesa-dev] [AppVeyor] mesa-webhook master #15069 completed
Build mesa-webhook 15069 completed Commit 447890ad64 by Tomeu Vizoso on 3/27/2020 2:31 PM: Revert "gitlab-ci: Disable jobs for Collabora's LAVA lab"\n\nLab is online again.\n\nThis reverts commit 1351ee03352b12690233a73e160f92da2edecf16.\n\nSigned-off-by: Tomeu Vizoso \nTested-by: Marge Bot \nPart-of: Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák wrote: > > > > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke 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
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
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, wrote: > On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák wrote: > > > > > > > > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke > 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
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák 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, wrote: >> >> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák wrote: >> > >> > >> > >> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke >> > 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
