Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Thu, Mar 25, 2021 at 2:12 PM Kenneth Graunke wrote: > > On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote: > > Other than the minor detail that we don't have pci-id's to > > differentiate between adreno generations, I might suggest a2xx users > > to use -lts > > > > BR, > > -R > > Could it be set up such that freedreno in mainline fails to load on > a2xx (and you could delete such code), while freedreno in -lts fails > to load on a3xx+? Basically, don't have any overlapping HW support > in both branches. > > --Ken ahh, if glvnd moves on to try the next driver after the first one fails, that would work perfectly. Not sure if I'd remove the code from mainline but might hide it behind a debug flag. Haven't thought it through too much yet, since I assumed it would require teaching glvnd new things. But it would be nice to worry less about breaking things that aren't in CI and not easy to test. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke wrote: > > On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote: > > On 3/25/21 10:49 AM, Jason Ekstrand wrote: > > Can you be more specific? Also, is there a reason why that work can't > > or shouldn't be done directly in the LTS branch? As Ken pointed out, > > The bulk of things that I had going were to enable some extensions and > make those extensions non-optional. ARB_framebuffer_object was at the > top of the list, but there were a couple of others. I think ARB_fbo > also affected the Gallium nouveau driver. Some of that was derailed > when I wasn't able to remove (classic) support for NV04 and NV05... and > I don't remember exactly where I left it. I would expect some of those > kinds of changes to also happen in post-fork mainline too. Hrm... That is a genuinely interesting extension on those platforms. From a "make it non-optional and dead-code" perspective, we can do that on mainline immediately post-fork easily enough. Enabling it on legacy could be done separately. If we wanted to also clean up the core on the legacy branch then, yeah, it'd have to be done twice. > > > I'm not sure we want to totally declare those drivers dead. People can > > > still do feature or enhancement development of they want to, it just > > > happens in a different branch. > > > > > > I think we need to be more clear about what "LTS mode" means for > > > developers and users here. It isn't that they can never change our be > > > improved. It's that we've gotten to the point where what they're > > > getting from being in the active development tree is breakage, not > > > "free" improvements. We're suggesting changing the social contract > > > with users, so to speak, from "these drivers still pick up > > > improvements from core" to "we won't break these drivers when we make > > > improvements to core in master." > > > > That is interesting. I doesn't sound very much like "long term stable" > > as in the original proposal. What would the versioning scheme be? In > > the original proposal, I would have expected versions go to 21.1.∞. How > > would that work if some version adds a feature? Would the versions (and > > branches from the branch?) follow the usual Mesa Year.Quarter.x scheme? I think we should make a distinction between what users should expect and what devs are allowed to do. It should be LTS from the perspective that users shouldn't expect new features. Then again, they really shouldn't expect new features on those drivers anyway. ¯\_(ツ)_/¯ > That's a good point. It's a bit expanded from "put out to pasture" so > maybe "-lts" isn't great. We could call it "-classic", unless Marek > wants to include r300g in there too. "-legacy" seems reasonable. It > looks like NVIDIA has various "legacy" branches with a version number > based on the original version where things branched off from. > > So maybe we could do: > >- mesa-legacy21 21.1.X > > where X increments on every release without worrying whether it adds > features or simply bug fixes. We figure true features and major > development will be pretty rare anyway. Yeah, I don't know that we need to worry too much about stable vs. feature releases on the legacy branch. If we still wanted a concept of major releases, we could slow it down to 1/year or something. Really, whatever makes it easiest for the release maintainers is fine with me. > > > So, unless there's a solid reason why such work needs to happen in the > > > master branch, I don't see a reason to hold this up for it. As long > > > as you're committed to test r200 and i915 when you make said changes, > > > we can do a feature release on the LTS branch. Users and distros just > > > shouldn't expect that to be a common thing. > > > > This inverts the current testing problem. Right now, r200 and i915 are > > poorly tested, but 965G through Sandybridge are very well tested. While > > I can totally test core changes on r200 and i915, how would I verify > > that those changes don't break, say, Ironlake? > > Post-fork, Intel CI would stop testing i965 on mainline obviously, > since it wouldn't exist there any longer. > > But I imagine it would add a new mesa_legacy21 job (like mesa_master) > which would still test i965 and i915, per-commit. Clayton/Nico could > also add "dev/idr/legacy" branches which trigger testing on i965/i915 > only. The existing expected results files would continue to work. I think this should work fine. It would end up being more like once per piglit MR rather than once per mesa MR since the cadence on the legacy branch should slow to a crawl. If anything, it might make testing easier since you'll have the whole pre-gen8 farm to yourself if you're hacking on the legacy branch. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote: > On 3/25/21 10:49 AM, Jason Ekstrand wrote: [snip] > > I'm not sure we want to totally declare those drivers dead. People can > > still do feature or enhancement development of they want to, it just > > happens in a different branch. > > > > I think we need to be more clear about what "LTS mode" means for > > developers and users here. It isn't that they can never change our be > > improved. It's that we've gotten to the point where what they're > > getting from being in the active development tree is breakage, not > > "free" improvements. We're suggesting changing the social contract > > with users, so to speak, from "these drivers still pick up > > improvements from core" to "we won't break these drivers when we make > > improvements to core in master." > > That is interesting. I doesn't sound very much like "long term stable" > as in the original proposal. What would the versioning scheme be? In > the original proposal, I would have expected versions go to 21.1.∞. How > would that work if some version adds a feature? Would the versions (and > branches from the branch?) follow the usual Mesa Year.Quarter.x scheme? That's a good point. It's a bit expanded from "put out to pasture" so maybe "-lts" isn't great. We could call it "-classic", unless Marek wants to include r300g in there too. "-legacy" seems reasonable. It looks like NVIDIA has various "legacy" branches with a version number based on the original version where things branched off from. So maybe we could do: - mesa-legacy21 21.1.X where X increments on every release without worrying whether it adds features or simply bug fixes. We figure true features and major development will be pretty rare anyway. > > So, unless there's a solid reason why such work needs to happen in the > > master branch, I don't see a reason to hold this up for it. As long > > as you're committed to test r200 and i915 when you make said changes, > > we can do a feature release on the LTS branch. Users and distros just > > shouldn't expect that to be a common thing. > > This inverts the current testing problem. Right now, r200 and i915 are > poorly tested, but 965G through Sandybridge are very well tested. While > I can totally test core changes on r200 and i915, how would I verify > that those changes don't break, say, Ironlake? Post-fork, Intel CI would stop testing i965 on mainline obviously, since it wouldn't exist there any longer. But I imagine it would add a new mesa_legacy21 job (like mesa_master) which would still test i965 and i915, per-commit. Clayton/Nico could also add "dev/idr/legacy" branches which trigger testing on i965/i915 only. The existing expected results files would continue to work. Then testing would be pretty similar to today, you'd just have a different dev branch for targeting master (testing anv and iris) or legacy21 (testign i915 and i965). --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote: > Other than the minor detail that we don't have pci-id's to > differentiate between adreno generations, I might suggest a2xx users > to use -lts > > BR, > -R Could it be set up such that freedreno in mainline fails to load on a2xx (and you could delete such code), while freedreno in -lts fails to load on a3xx+? Basically, don't have any overlapping HW support in both branches. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On 3/25/21 10:49 AM, Jason Ekstrand wrote: > Can you be more specific? Also, is there a reason why that work can't > or shouldn't be done directly in the LTS branch? As Ken pointed out, The bulk of things that I had going were to enable some extensions and make those extensions non-optional. ARB_framebuffer_object was at the top of the list, but there were a couple of others. I think ARB_fbo also affected the Gallium nouveau driver. Some of that was derailed when I wasn't able to remove (classic) support for NV04 and NV05... and I don't remember exactly where I left it. I would expect some of those kinds of changes to also happen in post-fork mainline too. Some of the other stuff... would actually be easier after the split because I wouldn't have to deal with Windows compilers. > I'm not sure we want to totally declare those drivers dead. People can > still do feature or enhancement development of they want to, it just > happens in a different branch. > > I think we need to be more clear about what "LTS mode" means for > developers and users here. It isn't that they can never change our be > improved. It's that we've gotten to the point where what they're > getting from being in the active development tree is breakage, not > "free" improvements. We're suggesting changing the social contract > with users, so to speak, from "these drivers still pick up > improvements from core" to "we won't break these drivers when we make > improvements to core in master." That is interesting. I doesn't sound very much like "long term stable" as in the original proposal. What would the versioning scheme be? In the original proposal, I would have expected versions go to 21.1.∞. How would that work if some version adds a feature? Would the versions (and branches from the branch?) follow the usual Mesa Year.Quarter.x scheme? > So, unless there's a solid reason why such work needs to happen in the > master branch, I don't see a reason to hold this up for it. As long > as you're committed to test r200 and i915 when you make said changes, > we can do a feature release on the LTS branch. Users and distros just > shouldn't expect that to be a common thing. This inverts the current testing problem. Right now, r200 and i915 are poorly tested, but 965G through Sandybridge are very well tested. While I can totally test core changes on r200 and i915, how would I verify that those changes don't break, say, Ironlake? > --Jason > > On Tue, Mar 23, 2021 at 3:26 AM Ian Romanick wrote: >> >> I would like to wait a couple more releases to do this. I have a couple >> things that I've been gradually working on for some of the non-i965 >> classic drivers that I'd like to land before they're put out to pasture. >> I talked to ajax about this a few weeks ago, and he was amenable at the >> time. >> >> I can step up on testing at least r200 to make sure core changes aren't >> making things explode. That should also cover most of the problems that >> could hit i915. i965 gets good coverage in the Intel CI, so I don't >> think that's as big of a problem. >> >> On 3/22/21 3:15 PM, Dylan Baker wrote: >>> Hi list, >>> >>> We've talked about it a number of times, but I think it's time time to >>> discuss splitting the classic drivers off of the main development branch >>> again, although this time I have a concrete plan for how this would >>> work. >>> >>> First, why? Basically, all of the classic drivers are in maintanence >>> mode (even i965). Second, many of them rely on code that no one works >>> on, and very few people still understand. There is no CI for most of >>> them, and the Intel CI is not integrated with gitlab, so it's easy to >>> unintentionally break them, and this breakage usually isn't noticed >>> until just before or just after a release. 21.0 was held up (in small >>> part, also me just getting behind) because of such breakages. >>> >>> I konw there is some interest in getting i915g in good enough shape that >>> it could replace i915c, at least for the common case. I also am aware >>> that Dave, Ilia, and Eric (with some pointers from Ken) have been >>> working on a gallium driver to replace i965. Neither of those things are >>> ready yet, but I've taken them into account. >>> >>> Here's the plan: >>> >>> 1) 21.1 release happens >>> 2) we remove classic from master >>> 3) 21.1 reaches EOL because of 21.2 >>> 4) we fork the 21.1 branch into a "classic-lts"¹ branch >>> 5) we disable all vulkan and gallium drivers in said branch, at least at >>>the Meson level >>> 6) We change the name and precidence of the glvnd loader file >>> 7) apply any build fixups (turn of intel generators for versions >= 7.5, >>>for example >>> 8) maintain that branch with build and critical bug fixes only >>> >>> This gives ditros and end users two options. >>> 1) then can build *only* the legacy branch in the a normal Mesa provides >>>libGL interfaces fashion >>> 2) They can use glvnd and install current mesa and the legacy
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Thu., Mar. 25, 2021, 12:14 Dylan Baker, wrote: > By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from > Meson. Maybe it makes sense to keep gallium for r300? But how many r300 > breakages have we had in recent memory? > We don't have any recent information on the status of r300. Splitting it would be wise. Same thinking could be applied to other gallium drivers for old hardware that don't receive new development and are becoming more and more irrelevant every year due to their age. Marek > On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: > > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote: > > > > > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker > wrote: > > > > > > > > Hi list, > > > > > > > > We've talked about it a number of times, but I think it's time time > to > > > > discuss splitting the classic drivers off of the main development > branch > > > > again, although this time I have a concrete plan for how this would > > > > work. > > > > > > > > First, why? Basically, all of the classic drivers are in maintanence > > > > mode (even i965). Second, many of them rely on code that no one works > > > > on, and very few people still understand. There is no CI for most of > > > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > > > unintentionally break them, and this breakage usually isn't noticed > > > > until just before or just after a release. 21.0 was held up (in small > > > > part, also me just getting behind) because of such breakages. > > > > > > > > I konw there is some interest in getting i915g in good enough shape > that > > > > it could replace i915c, at least for the common case. I also am aware > > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > > > working on a gallium driver to replace i965. Neither of those things > are > > > > ready yet, but I've taken them into account. > > > > > > > > Here's the plan: > > > > > > > > 1) 21.1 release happens > > > > 2) we remove classic from master > > > > 3) 21.1 reaches EOL because of 21.2 > > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > > > 5) we disable all vulkan and gallium drivers in said branch, at > least at > > > >the Meson level > > > > > > I'm +1 for the -lts branch.. the layering between mesa "classic" and > > > gallium is already starting to get poked thru in the name of > > > performance, and we've already discovered cases of classic drivers > > > being broken for multiple months with no one noticing. I think a > > > slower moving -lts branch is the best approach to keeping things > > > working for folks with older hw. > > > > > > But possibly there is some value in not completely disabling gallium > > > completely in the -lts branch. We do have some older gallium drivers > > > which do not have CI coverage and I think are not used frequently by > > > developers who are tracking the latest main/master branch. I'm not > > > suggesting that we remove them from the main (non-lts) branch but it > > > might be useful to be able to recommend users of those drivers stick > > > with the -lts version for better stability? > > > > I agree with this. Generally, I don't think we should delete anything > > from the -lts branch. Doing so only risks more breakage. We probably > > want to change some meson build defaults to not build anything but old > > drivers but that's it. > > > > --Jason > > > > > BR, > > > -R > > > > > > > 6) We change the name and precidence of the glvnd loader file > > > > 7) apply any build fixups (turn of intel generators for versions >= > 7.5, > > > >for example > > > > 8) maintain that branch with build and critical bug fixes only > > > > > > > > This gives ditros and end users two options. > > > > 1) then can build *only* the legacy branch in the a normal Mesa > provides > > > >libGL interfaces fashion > > > > 2) They can use glvnd and install current mesa and the legacy branch > in > > > >parallel > > > > > > > > Because of glvnd, we can control which driver will get loaded first, > and > > > > thus if we decide i915g or the i965 replacement is ready and turn it > on > > > > by default it will be loaded by default. An end user who doesn't like > > > > this can add a new glvnd loader file that makes the classic drivers > > > > higher precident and continue to use them. > > > > > > > > Why fork from 21.1 instead of master? > > > > > > > > First, it allows us to delete classic immediately, which will allow > > > > refactoring to happen earlier in the cycle, and for any fallout to be > > > > caught and hopefully fixed before the release. Second, it means that > > > > when a user is switched from 21.1 to the new classic-lts branch, > there > > > > will be no regressions, and no one has to spend time figuring out > what > > > > broke and fixing the lts branch. > > > > > > > > When you say "build and critical bug fixes", what do you mean? > > > > > > > > I mean update Meson if we rely on something that in
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
Can you be more specific? Also, is there a reason why that work can't or shouldn't be done directly in the LTS branch? As Ken pointed out, I'm not sure we want to totally declare those drivers dead. People can still do feature or enhancement development of they want to, it just happens in a different branch. I think we need to be more clear about what "LTS mode" means for developers and users here. It isn't that they can never change our be improved. It's that we've gotten to the point where what they're getting from being in the active development tree is breakage, not "free" improvements. We're suggesting changing the social contract with users, so to speak, from "these drivers still pick up improvements from core" to "we won't break these drivers when we make improvements to core in master." So, unless there's a solid reason why such work needs to happen in the master branch, I don't see a reason to hold this up for it. As long as you're committed to test r200 and i915 when you make said changes, we can do a feature release on the LTS branch. Users and distros just shouldn't expect that to be a common thing. --Jason On Tue, Mar 23, 2021 at 3:26 AM Ian Romanick wrote: > > I would like to wait a couple more releases to do this. I have a couple > things that I've been gradually working on for some of the non-i965 > classic drivers that I'd like to land before they're put out to pasture. > I talked to ajax about this a few weeks ago, and he was amenable at the > time. > > I can step up on testing at least r200 to make sure core changes aren't > making things explode. That should also cover most of the problems that > could hit i915. i965 gets good coverage in the Intel CI, so I don't > think that's as big of a problem. > > On 3/22/21 3:15 PM, Dylan Baker wrote: > > Hi list, > > > > We've talked about it a number of times, but I think it's time time to > > discuss splitting the classic drivers off of the main development branch > > again, although this time I have a concrete plan for how this would > > work. > > > > First, why? Basically, all of the classic drivers are in maintanence > > mode (even i965). Second, many of them rely on code that no one works > > on, and very few people still understand. There is no CI for most of > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > unintentionally break them, and this breakage usually isn't noticed > > until just before or just after a release. 21.0 was held up (in small > > part, also me just getting behind) because of such breakages. > > > > I konw there is some interest in getting i915g in good enough shape that > > it could replace i915c, at least for the common case. I also am aware > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > working on a gallium driver to replace i965. Neither of those things are > > ready yet, but I've taken them into account. > > > > Here's the plan: > > > > 1) 21.1 release happens > > 2) we remove classic from master > > 3) 21.1 reaches EOL because of 21.2 > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > 5) we disable all vulkan and gallium drivers in said branch, at least at > >the Meson level > > 6) We change the name and precidence of the glvnd loader file > > 7) apply any build fixups (turn of intel generators for versions >= 7.5, > >for example > > 8) maintain that branch with build and critical bug fixes only > > > > This gives ditros and end users two options. > > 1) then can build *only* the legacy branch in the a normal Mesa provides > >libGL interfaces fashion > > 2) They can use glvnd and install current mesa and the legacy branch in > >parallel > > > > Because of glvnd, we can control which driver will get loaded first, and > > thus if we decide i915g or the i965 replacement is ready and turn it on > > by default it will be loaded by default. An end user who doesn't like > > this can add a new glvnd loader file that makes the classic drivers > > higher precident and continue to use them. > > > > Why fork from 21.1 instead of master? > > > > First, it allows us to delete classic immediately, which will allow > > refactoring to happen earlier in the cycle, and for any fallout to be > > caught and hopefully fixed before the release. Second, it means that > > when a user is switched from 21.1 to the new classic-lts branch, there > > will be no regressions, and no one has to spend time figuring out what > > broke and fixing the lts branch. > > > > When you say "build and critical bug fixes", what do you mean? > > > > I mean update Meson if we rely on something that in the future is > > deprecated and removed, and would prevent building the branch or an > > relying on some compiler behavior that changes, gaping exploitable > > security holes, that kind of thing. > > > > footnotes > > ¹Or whatever color you like your bikeshed > > > > > > ___ > > mesa-dev mailing list > >
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
Other than the minor detail that we don't have pci-id's to differentiate between adreno generations, I might suggest a2xx users to use -lts BR, -R On Thu, Mar 25, 2021 at 9:14 AM Dylan Baker wrote: > > By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. > Maybe it makes sense to keep gallium for r300? But how many r300 breakages > have we had in recent memory? > > On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: > > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote: > > > > > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote: > > > > > > > > Hi list, > > > > > > > > We've talked about it a number of times, but I think it's time time to > > > > discuss splitting the classic drivers off of the main development branch > > > > again, although this time I have a concrete plan for how this would > > > > work. > > > > > > > > First, why? Basically, all of the classic drivers are in maintanence > > > > mode (even i965). Second, many of them rely on code that no one works > > > > on, and very few people still understand. There is no CI for most of > > > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > > > unintentionally break them, and this breakage usually isn't noticed > > > > until just before or just after a release. 21.0 was held up (in small > > > > part, also me just getting behind) because of such breakages. > > > > > > > > I konw there is some interest in getting i915g in good enough shape that > > > > it could replace i915c, at least for the common case. I also am aware > > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > > > working on a gallium driver to replace i965. Neither of those things are > > > > ready yet, but I've taken them into account. > > > > > > > > Here's the plan: > > > > > > > > 1) 21.1 release happens > > > > 2) we remove classic from master > > > > 3) 21.1 reaches EOL because of 21.2 > > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > > > 5) we disable all vulkan and gallium drivers in said branch, at least at > > > >the Meson level > > > > > > I'm +1 for the -lts branch.. the layering between mesa "classic" and > > > gallium is already starting to get poked thru in the name of > > > performance, and we've already discovered cases of classic drivers > > > being broken for multiple months with no one noticing. I think a > > > slower moving -lts branch is the best approach to keeping things > > > working for folks with older hw. > > > > > > But possibly there is some value in not completely disabling gallium > > > completely in the -lts branch. We do have some older gallium drivers > > > which do not have CI coverage and I think are not used frequently by > > > developers who are tracking the latest main/master branch. I'm not > > > suggesting that we remove them from the main (non-lts) branch but it > > > might be useful to be able to recommend users of those drivers stick > > > with the -lts version for better stability? > > > > I agree with this. Generally, I don't think we should delete anything > > from the -lts branch. Doing so only risks more breakage. We probably > > want to change some meson build defaults to not build anything but old > > drivers but that's it. > > > > --Jason > > > > > BR, > > > -R > > > > > > > 6) We change the name and precidence of the glvnd loader file > > > > 7) apply any build fixups (turn of intel generators for versions >= 7.5, > > > >for example > > > > 8) maintain that branch with build and critical bug fixes only > > > > > > > > This gives ditros and end users two options. > > > > 1) then can build *only* the legacy branch in the a normal Mesa provides > > > >libGL interfaces fashion > > > > 2) They can use glvnd and install current mesa and the legacy branch in > > > >parallel > > > > > > > > Because of glvnd, we can control which driver will get loaded first, and > > > > thus if we decide i915g or the i965 replacement is ready and turn it on > > > > by default it will be loaded by default. An end user who doesn't like > > > > this can add a new glvnd loader file that makes the classic drivers > > > > higher precident and continue to use them. > > > > > > > > Why fork from 21.1 instead of master? > > > > > > > > First, it allows us to delete classic immediately, which will allow > > > > refactoring to happen earlier in the cycle, and for any fallout to be > > > > caught and hopefully fixed before the release. Second, it means that > > > > when a user is switched from 21.1 to the new classic-lts branch, there > > > > will be no regressions, and no one has to spend time figuring out what > > > > broke and fixing the lts branch. > > > > > > > > When you say "build and critical bug fixes", what do you mean? > > > > > > > > I mean update Meson if we rely on something that in the future is > > > > deprecated and removed, and would prevent building the branch or an > > > > relying on some compiler behavior that changes, gaping
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. Maybe it makes sense to keep gallium for r300? But how many r300 breakages have we had in recent memory? On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote: > > > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote: > > > > > > Hi list, > > > > > > We've talked about it a number of times, but I think it's time time to > > > discuss splitting the classic drivers off of the main development branch > > > again, although this time I have a concrete plan for how this would > > > work. > > > > > > First, why? Basically, all of the classic drivers are in maintanence > > > mode (even i965). Second, many of them rely on code that no one works > > > on, and very few people still understand. There is no CI for most of > > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > > unintentionally break them, and this breakage usually isn't noticed > > > until just before or just after a release. 21.0 was held up (in small > > > part, also me just getting behind) because of such breakages. > > > > > > I konw there is some interest in getting i915g in good enough shape that > > > it could replace i915c, at least for the common case. I also am aware > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > > working on a gallium driver to replace i965. Neither of those things are > > > ready yet, but I've taken them into account. > > > > > > Here's the plan: > > > > > > 1) 21.1 release happens > > > 2) we remove classic from master > > > 3) 21.1 reaches EOL because of 21.2 > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > > 5) we disable all vulkan and gallium drivers in said branch, at least at > > >the Meson level > > > > I'm +1 for the -lts branch.. the layering between mesa "classic" and > > gallium is already starting to get poked thru in the name of > > performance, and we've already discovered cases of classic drivers > > being broken for multiple months with no one noticing. I think a > > slower moving -lts branch is the best approach to keeping things > > working for folks with older hw. > > > > But possibly there is some value in not completely disabling gallium > > completely in the -lts branch. We do have some older gallium drivers > > which do not have CI coverage and I think are not used frequently by > > developers who are tracking the latest main/master branch. I'm not > > suggesting that we remove them from the main (non-lts) branch but it > > might be useful to be able to recommend users of those drivers stick > > with the -lts version for better stability? > > I agree with this. Generally, I don't think we should delete anything > from the -lts branch. Doing so only risks more breakage. We probably > want to change some meson build defaults to not build anything but old > drivers but that's it. > > --Jason > > > BR, > > -R > > > > > 6) We change the name and precidence of the glvnd loader file > > > 7) apply any build fixups (turn of intel generators for versions >= 7.5, > > >for example > > > 8) maintain that branch with build and critical bug fixes only > > > > > > This gives ditros and end users two options. > > > 1) then can build *only* the legacy branch in the a normal Mesa provides > > >libGL interfaces fashion > > > 2) They can use glvnd and install current mesa and the legacy branch in > > >parallel > > > > > > Because of glvnd, we can control which driver will get loaded first, and > > > thus if we decide i915g or the i965 replacement is ready and turn it on > > > by default it will be loaded by default. An end user who doesn't like > > > this can add a new glvnd loader file that makes the classic drivers > > > higher precident and continue to use them. > > > > > > Why fork from 21.1 instead of master? > > > > > > First, it allows us to delete classic immediately, which will allow > > > refactoring to happen earlier in the cycle, and for any fallout to be > > > caught and hopefully fixed before the release. Second, it means that > > > when a user is switched from 21.1 to the new classic-lts branch, there > > > will be no regressions, and no one has to spend time figuring out what > > > broke and fixing the lts branch. > > > > > > When you say "build and critical bug fixes", what do you mean? > > > > > > I mean update Meson if we rely on something that in the future is > > > deprecated and removed, and would prevent building the branch or an > > > relying on some compiler behavior that changes, gaping exploitable > > > security holes, that kind of thing. > > > > > > footnotes > > > ¹Or whatever color you like your > > > bikeshed___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > > mesa-dev mailing list > >
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
Maybe I could have been clearer, but I meant "We only guarantee that we'll keep the build working and that major security problems get fixed", If you or someone else wants to fix other issues that's fine, but I meant if someone says "i915c is too slow for some workload", we reserve the right to close that as EWONTFIX. On Tue, Mar 23, 2021, at 01:26, Ian Romanick wrote: > I would like to wait a couple more releases to do this. I have a couple > things that I've been gradually working on for some of the non-i965 > classic drivers that I'd like to land before they're put out to pasture. > I talked to ajax about this a few weeks ago, and he was amenable at the > time. > > I can step up on testing at least r200 to make sure core changes aren't > making things explode. That should also cover most of the problems that > could hit i915. i965 gets good coverage in the Intel CI, so I don't > think that's as big of a problem. > > On 3/22/21 3:15 PM, Dylan Baker wrote: > > Hi list, > > > > We've talked about it a number of times, but I think it's time time to > > discuss splitting the classic drivers off of the main development branch > > again, although this time I have a concrete plan for how this would > > work. > > > > First, why? Basically, all of the classic drivers are in maintanence > > mode (even i965). Second, many of them rely on code that no one works > > on, and very few people still understand. There is no CI for most of > > them, and the Intel CI is not integrated with gitlab, so it's easy to > > unintentionally break them, and this breakage usually isn't noticed > > until just before or just after a release. 21.0 was held up (in small > > part, also me just getting behind) because of such breakages. > > > > I konw there is some interest in getting i915g in good enough shape that > > it could replace i915c, at least for the common case. I also am aware > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > working on a gallium driver to replace i965. Neither of those things are > > ready yet, but I've taken them into account. > > > > Here's the plan: > > > > 1) 21.1 release happens > > 2) we remove classic from master > > 3) 21.1 reaches EOL because of 21.2 > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > 5) we disable all vulkan and gallium drivers in said branch, at least at > >the Meson level > > 6) We change the name and precidence of the glvnd loader file > > 7) apply any build fixups (turn of intel generators for versions >= 7.5, > >for example > > 8) maintain that branch with build and critical bug fixes only > > > > This gives ditros and end users two options. > > 1) then can build *only* the legacy branch in the a normal Mesa provides > >libGL interfaces fashion > > 2) They can use glvnd and install current mesa and the legacy branch in > >parallel > > > > Because of glvnd, we can control which driver will get loaded first, and > > thus if we decide i915g or the i965 replacement is ready and turn it on > > by default it will be loaded by default. An end user who doesn't like > > this can add a new glvnd loader file that makes the classic drivers > > higher precident and continue to use them. > > > > Why fork from 21.1 instead of master? > > > > First, it allows us to delete classic immediately, which will allow > > refactoring to happen earlier in the cycle, and for any fallout to be > > caught and hopefully fixed before the release. Second, it means that > > when a user is switched from 21.1 to the new classic-lts branch, there > > will be no regressions, and no one has to spend time figuring out what > > broke and fixing the lts branch. > > > > When you say "build and critical bug fixes", what do you mean? > > > > I mean update Meson if we rely on something that in the future is > > deprecated and removed, and would prevent building the branch or an > > relying on some compiler behavior that changes, gaping exploitable > > security holes, that kind of thing. > > > > footnotes > > ¹Or whatever color you like your bikeshed > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > -- Dylan Baker dy...@pnwbakers.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On Thu, Mar 25, 2021 at 9:41 AM Rob Clark wrote: > > On Wed, Mar 24, 2021 at 9:15 PM Jason Ekstrand wrote: > > > > On March 24, 2021 22:25:10 Rob Clark wrote: > > > >> On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen > >> wrote: > >>> > >>> > >>> On 2021-03-23 09:38:59, Eric Anholt wrote: > > On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand > wrote: > > > > > > Trying to pick this discussion back up. Daniel Stone thinks it's a > > half hour of API bashing to retarget all the MRs so, if the fd.o > > admins have some heads up, it should be tractable. Should we do this > > right after branching 21.1 along with the LTS branch? > > > +1 > >>> > >>> > >>> Jason, > >>> > >>> I opened a related Mesa issue: > >>> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 > >>> > >>> I made this change in crucible, and used a script to update the 7 MR > >>> target branches: > >>> https://gitlab.freedesktop.org/mesa/crucible/-/issues/5 > >>> > >>> As mentioned in the Mesa issue, I think we should use piglit as > >>> another test run before changing Mesa: > >>> https://gitlab.freedesktop.org/mesa/piglit/-/issues/50 > >>> > >>> Piglit currently has 60 open merge requests. > >> > >> > >> I'm in favor of branch rename, but was in the camp of "hope gitlab > >> comes up with a way to make this easy for us".. but as far as fallback > >> plan, converting trees with fewer outstanding MRs first seems like a > >> pretty good idea so solid +1 for that > > > > > > If you read enough off the things, you'll see that Jordan wrote a python > > script that re-targets all the open MRs so that's not a manual process. > > It's not a GitLab-sanctioned solution but it's the next best thing. The one > > downside is that all the MRs will get their last updated timestamp reset > > but that seems like a pretty small price to pay. > > > > yeah, I meant to convert a repo w/ more MRs than 7 but less than mesa > using the script to beta test that, wasn't suggesting to do it by hand Plan is to convert piglit next. It's sitting at about 60 open MRs. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On Wed, Mar 24, 2021 at 9:15 PM Jason Ekstrand wrote: > > On March 24, 2021 22:25:10 Rob Clark wrote: > >> On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen >> wrote: >>> >>> >>> On 2021-03-23 09:38:59, Eric Anholt wrote: On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote: > > > Trying to pick this discussion back up. Daniel Stone thinks it's a > half hour of API bashing to retarget all the MRs so, if the fd.o > admins have some heads up, it should be tractable. Should we do this > right after branching 21.1 along with the LTS branch? +1 >>> >>> >>> Jason, >>> >>> I opened a related Mesa issue: >>> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 >>> >>> I made this change in crucible, and used a script to update the 7 MR >>> target branches: >>> https://gitlab.freedesktop.org/mesa/crucible/-/issues/5 >>> >>> As mentioned in the Mesa issue, I think we should use piglit as >>> another test run before changing Mesa: >>> https://gitlab.freedesktop.org/mesa/piglit/-/issues/50 >>> >>> Piglit currently has 60 open merge requests. >> >> >> I'm in favor of branch rename, but was in the camp of "hope gitlab >> comes up with a way to make this easy for us".. but as far as fallback >> plan, converting trees with fewer outstanding MRs first seems like a >> pretty good idea so solid +1 for that > > > If you read enough off the things, you'll see that Jordan wrote a python > script that re-targets all the open MRs so that's not a manual process. It's > not a GitLab-sanctioned solution but it's the next best thing. The one > downside is that all the MRs will get their last updated timestamp reset but > that seems like a pretty small price to pay. > yeah, I meant to convert a repo w/ more MRs than 7 but less than mesa using the script to beta test that, wasn't suggesting to do it by hand BR, -R > Jordan, is there any way you can make the script sort by last updated before > it re-targets the MRs so they at least stay in the same order? Updating them > in MR # order wouldn't be bad either, I guess. > > --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On 2021-03-24 21:14:57, Jason Ekstrand wrote: > > Jordan, is there any way you can make the script sort by last updated before > it > re-targets the MRs so they at least stay in the same order? Updating them in > MR > # order wouldn't be bad either, I guess. > It already does process them sorting by the oldest "update time" first, so roughly speaking the order sorted by update time should be the same. I don't know what might happen if 2 MRs were updated within the same second. But, the updates are actually a bit slow (maybe ~1 update per second), so there doesn't seem to be much risk, as far as I can see, of, for instance, 10 updates happening within the same second. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
