Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On Sun, Mar 29, 2020, 4:09 PM Jason Ekstrand wrote:
> On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
> wrote:
> >
> > On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom
> wrote:
> > >
> > >
> > >
> > > On 2020-03-29 at 20:58, Jason Ekstrand wrote:
> > > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg <
> hoegsb...@gmail.com> wrote:
> > > > >
> > > > > As for loading, doesn't glvnd solve that?
> > > >
> > > > Not really. There are still problems if you have HW drivers from
> both
> > > > repos on the same system and someone has to decide which one to use.
> > > > We would either have to come up with a good solution to that problem
> > > > or we would have to delete/disable all of the drivers still in master
> > > > in the LTS branch. In any case, there are real problems to solve
> > > > there.
> > >
> > > That's a simple packaging issue, and IMO it's ok to just say in the
> announcement
> > > email "this 'legacy drivers' branch also contains old versions of the
> new
> > > drivers. If you ship both these and a modern version of Mesa, make sure
> > > not to build the same drivers from both trees".
> > >
> > > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=`
> lists
> > > to avoid collisions on their distros.
> >
> > Wouldn't this be much safer anyway with a small patch to remove those
> > "new" drivers from the meson options list?
>
> It may not be that simple. If, for instance, we wanted to cut of Gen7
> Vulkan, we would somehow have to provide an option to limit which
> hardware generations are supported in the LTS branch. Either that or
> just delete support for Gen8+ somehow.
>
The "loader problem" that I was thinking of is the while the dri driver
interface is theoretically a stable API nobody tests mixing loaders from
one mesa release with drivers from another. glvnd does solve that problem
and deciding which Intel gens should be supported by i965 or iris *is* a
simple packaging problem.
As for anv splitting out gen7 support that's orthogonal, local to anv and
less relevant to the decision about dropping legacy dri drivers and go all
gallium. I know it's close to your heart, of course, but since vulkan had a
standard loader interface since day 1, it seems like something you can
decide on independently.
> --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 Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
wrote:
>
> On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom wrote:
> >
> >
> >
> > On 2020-03-29 at 20:58, Jason Ekstrand wrote:
> > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg
> > > wrote:
> > > >
> > > > As for loading, doesn't glvnd solve that?
> > >
> > > Not really. There are still problems if you have HW drivers from both
> > > repos on the same system and someone has to decide which one to use.
> > > We would either have to come up with a good solution to that problem
> > > or we would have to delete/disable all of the drivers still in master
> > > in the LTS branch. In any case, there are real problems to solve
> > > there.
> >
> > That's a simple packaging issue, and IMO it's ok to just say in the
> > announcement
> > email "this 'legacy drivers' branch also contains old versions of the new
> > drivers. If you ship both these and a modern version of Mesa, make sure
> > not to build the same drivers from both trees".
> >
> > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
> > to avoid collisions on their distros.
>
> Wouldn't this be much safer anyway with a small patch to remove those
> "new" drivers from the meson options list?
It may not be that simple. If, for instance, we wanted to cut of Gen7
Vulkan, we would somehow have to provide an option to limit which
hardware generations are supported in the LTS branch. Either that or
just delete support for Gen8+ somehow.
--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 Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom wrote:
>
>
>
> On 2020-03-29 at 20:58, Jason Ekstrand wrote:
> > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg
> > wrote:
> > >
> > > As for loading, doesn't glvnd solve that?
> >
> > Not really. There are still problems if you have HW drivers from both
> > repos on the same system and someone has to decide which one to use.
> > We would either have to come up with a good solution to that problem
> > or we would have to delete/disable all of the drivers still in master
> > in the LTS branch. In any case, there are real problems to solve
> > there.
>
> That's a simple packaging issue, and IMO it's ok to just say in the
> announcement
> email "this 'legacy drivers' branch also contains old versions of the new
> drivers. If you ship both these and a modern version of Mesa, make sure
> not to build the same drivers from both trees".
>
> Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
> to avoid collisions on their distros.
Wouldn't this be much safer anyway with a small patch to remove those
"new" drivers from the meson options list?
> ___
> 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
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On 2020-03-29 at 20:58, Jason Ekstrand wrote:
> On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg
> wrote:
> >
> > As for loading, doesn't glvnd solve that?
>
> Not really. There are still problems if you have HW drivers from both
> repos on the same system and someone has to decide which one to use.
> We would either have to come up with a good solution to that problem
> or we would have to delete/disable all of the drivers still in master
> in the LTS branch. In any case, there are real problems to solve
> there.
That's a simple packaging issue, and IMO it's ok to just say in the announcement
email "this 'legacy drivers' branch also contains old versions of the new
drivers. If you ship both these and a modern version of Mesa, make sure
not to build the same drivers from both trees".
Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
to avoid collisions on their distros.
___
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 Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg wrote: > > As for loading, doesn't glvnd solve that? Not really. There are still problems if you have HW drivers from both repos on the same system and someone has to decide which one to use. We would either have to come up with a good solution to that problem or we would have to delete/disable all of the drivers still in master in the LTS branch. In any case, there are real problems to solve there. --Jason > On Sun, Mar 29, 2020, 1:19 AM Marek Olšák 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, wrote: >>> >>> 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
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
As for loading, doesn't glvnd solve that? On Sun, Mar 29, 2020, 1:19 AM Marek Olšák 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, > wrote: > >> 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 < >> 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
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
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, wrote: > 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 > >>
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
