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 <i...@freedesktop.org> 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
