Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
Hi Jason & Daniel, maybe I should explain once more where the problem with this approach is and why I think we need to get that fixed before we can do something like this here. To summarize what this patch here does is that it copies the exclusive fence and/or the shared fences into a sync_file. This alone is totally unproblematic. The problem is what this implies. When you need to copy the exclusive fence to a sync_file then this means that the driver is at some point ignoring the exclusive fence on a buffer object. When you combine that with complex drivers which use TTM and buffer moves underneath you can construct an information leak using this and give userspace access to memory which is allocated to the driver, but not yet initialized. This way you can leak things like page tables, passwords, kernel data etc... in large amounts to userspace and is an absolutely no-go for security. That's why I'm said we need to get this fixed before we upstream this patch set here and especially the driver change which is using that. Regards, Christian. Am 10.06.21 um 23:09 schrieb Jason Ekstrand: Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König Cc: Michel Dänzer Cc: Dave Airlie Cc: Bas Nieuwenhuizen Cc: Daniel Stone Cc: mesa-dev@lists.freedesktop.org Cc: wayland-de...@lists.freedesktop.org Test-with: 20210524205225.872316-1-ja...@jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c| 103 + drivers/dma-buf/dma-fence-array.c| 27 +++ drivers/dma-buf/dma-resv.c | 110 +++ include/linux/dma-fence-array.h | 17 + include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 - 7 files changed, 369
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
I'm bringing this up via e-mail so it gets a wider audience. Given how will crocus is working at this point, is like to propose we hold off for about three more releases before we drop classic. This next release, 21.2, we'll have crocus as an option with i965 as the default. There will also be a -Dprefer-crocus meson options so distros or individuals can attempt to flip it on. The release after that, 21.3, we'll keep i965 in the tree but have crocus be the default (assuming things are going well.) Some time in 2022, probably after the 22.2 release or so, we'll delete classic. Why wait so long? Well, it just landed and we don't have a Cherryview story yet so I'm hesitant to make it the default too quickly. Even if it were the default in 21.2, it's already too late, likely, to hit the fall 2021 distro release cycle. If we flip it to the default before the end of the year, that'll get crocus into spring distros. This is good because 22.04 is an Ubuntu LTS release and I think they'd rather bump crocus versions to fix bugs than backport on top of i965. But that's really fort Ubuntu to decide. In any case, we won't see broad-spread usage and the flood of bug reports until next spring so we may want to wait until then to stay deleting code. If we wanted to accelerate things, one option, once we're ready, would be to ask the person who manages the oibaf PPA to switch to crocus early. That may get some early adopters on board. Thoughts? --Jason On April 9, 2021 22:09:14 Dylan Baker wrote: Quoting Dylan Baker (2021-03-22 15:15:30) 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 Here is a merge request to remove classic: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153 Dylan ___ 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 6/16/21 11:03 AM, Jason Ekstrand wrote: I'm bringing this up via e-mail so it gets a wider audience. Given how will crocus is working at this point, is like to propose we hold off for about three more releases before we drop classic. This next release, 21.2, we'll have crocus as an option with i965 as the default. There will also be a -Dprefer-crocus meson options so distros or individuals can attempt to flip it on. The release after that, 21.3, we'll keep i965 in the tree but have crocus be the default (assuming things are going well.) Some time in 2022, probably after the 22.2 release or so, we'll delete classic. Why wait so long? Well, it just landed and we don't have a Cherryview story yet so I'm hesitant to make it the default too quickly. Even if it were the default in 21.2, it's already too late, likely, to hit the fall 2021 distro release cycle. If we flip it to the default before the end of the year, that'll get crocus into spring distros. This is good because 22.04 is an Ubuntu LTS release and I think they'd rather bump crocus versions to fix bugs than backport on top of i965. But that's really fort Ubuntu to decide. In any case, we won't see broad-spread usage and the flood of bug reports until next spring so we may want to wait until then to stay deleting code. If we wanted to accelerate things, one option, once we're ready, would be to ask the person who manages the oibaf PPA to switch to crocus early. That may get some early adopters on board. Thoughts? I though the idea was to put everything in a classic branch and let distros run "classic" hardware from that. What happens after 3 releases does i965 still go to the classic branch with the other classic drivers? If so is it really worth waiting just because Ubuntu might have to back-port a bug fix? --Jason On April 9, 2021 22:09:14 Dylan Baker wrote: Quoting Dylan Baker (2021-03-22 15:15:30) 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 Here is a merge request to remove classic: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153 Dylan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote: > > On 6/16/21 11:03 AM, Jason Ekstrand wrote: > > I'm bringing this up via e-mail so it gets a wider audience. Given how will > crocus is working at this point, is like to propose we hold off for about > three more releases before we drop classic. This next release, 21.2, we'll > have crocus as an option with i965 as the default. There will also be a > -Dprefer-crocus meson options so distros or individuals can attempt to flip > it on. The release after that, 21.3, we'll keep i965 in the tree but have > crocus be the default (assuming things are going well.) Some time in 2022, > probably after the 22.2 release or so, we'll delete classic. > > Why wait so long? Well, it just landed and we don't have a Cherryview story > yet so I'm hesitant to make it the default too quickly. Even if it were the > default in 21.2, it's already too late, likely, to hit the fall 2021 distro > release cycle. If we flip it to the default before the end of the year, > that'll get crocus into spring distros. This is good because 22.04 is an > Ubuntu LTS release and I think they'd rather bump crocus versions to fix bugs > than backport on top of i965. But that's really fort Ubuntu to decide. In any > case, we won't see broad-spread usage and the flood of bug reports until next > spring so we may want to wait until then to stay deleting code. > > If we wanted to accelerate things, one option, once we're ready, would be to > ask the person who manages the oibaf PPA to switch to crocus early. That may > get some early adopters on board. > > Thoughts? > > I though the idea was to put everything in a classic branch and let distros > run "classic" hardware from that. What happens after 3 releases does i965 > still go to the classic branch with the other classic drivers? If so is it > really worth waiting just because Ubuntu might have to back-port a bug fix? Yeah, that was the idea. However, with crocus in good shape and Emma Anholt working on i915g, it may be that the actual answer is we just throw away the classic drivers and the only thing you really need the old branch for is r200 and ancient nouveau. --Jason > --Jason > > On April 9, 2021 22:09:14 Dylan Baker wrote: > >> Quoting Dylan Baker (2021-03-22 15:15:30) >>> >>> 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. >>> >
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
On 6/16/21 1:16 PM, Jason Ekstrand wrote: On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote: On 6/16/21 11:03 AM, Jason Ekstrand wrote: I'm bringing this up via e-mail so it gets a wider audience. Given how will crocus is working at this point, is like to propose we hold off for about three more releases before we drop classic. This next release, 21.2, we'll have crocus as an option with i965 as the default. There will also be a -Dprefer-crocus meson options so distros or individuals can attempt to flip it on. The release after that, 21.3, we'll keep i965 in the tree but have crocus be the default (assuming things are going well.) Some time in 2022, probably after the 22.2 release or so, we'll delete classic. Why wait so long? Well, it just landed and we don't have a Cherryview story yet so I'm hesitant to make it the default too quickly. Even if it were the default in 21.2, it's already too late, likely, to hit the fall 2021 distro release cycle. If we flip it to the default before the end of the year, that'll get crocus into spring distros. This is good because 22.04 is an Ubuntu LTS release and I think they'd rather bump crocus versions to fix bugs than backport on top of i965. But that's really fort Ubuntu to decide. In any case, we won't see broad-spread usage and the flood of bug reports until next spring so we may want to wait until then to stay deleting code. If we wanted to accelerate things, one option, once we're ready, would be to ask the person who manages the oibaf PPA to switch to crocus early. That may get some early adopters on board. Thoughts? I though the idea was to put everything in a classic branch and let distros run "classic" hardware from that. What happens after 3 releases does i965 still go to the classic branch with the other classic drivers? If so is it really worth waiting just because Ubuntu might have to back-port a bug fix? Yeah, that was the idea. However, with crocus in good shape and Emma Anholt working on i915g, it may be that the actual answer is we just throw away the classic drivers and the only thing you really need the old branch for is r200 and ancient nouveau. Fair enough. I don't really have any stake in these drivers, but I am eager to get to work on clean ups once we drop the classic drivers. I would be disappointed if we were forced to wait another year just to have the Intel drivers kept in the classic branch anyway. Going on past experience we can pretty much guarantee that someone will at least ask we keep them. Anyway up to you guys I guess. ___ 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 Tue, Jun 15, 2021 at 8:16 PM Jason Ekstrand wrote: > > On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote: > > > > On 6/16/21 11:03 AM, Jason Ekstrand wrote: > > > > I'm bringing this up via e-mail so it gets a wider audience. Given how will > > crocus is working at this point, is like to propose we hold off for about > > three more releases before we drop classic. This next release, 21.2, we'll > > have crocus as an option with i965 as the default. There will also be a > > -Dprefer-crocus meson options so distros or individuals can attempt to flip > > it on. The release after that, 21.3, we'll keep i965 in the tree but have > > crocus be the default (assuming things are going well.) Some time in 2022, > > probably after the 22.2 release or so, we'll delete classic. > > > > Why wait so long? Well, it just landed and we don't have a Cherryview story > > yet so I'm hesitant to make it the default too quickly. Even if it were the > > default in 21.2, it's already too late, likely, to hit the fall 2021 distro > > release cycle. If we flip it to the default before the end of the year, > > that'll get crocus into spring distros. This is good because 22.04 is an > > Ubuntu LTS release and I think they'd rather bump crocus versions to fix > > bugs than backport on top of i965. But that's really fort Ubuntu to decide. > > In any case, we won't see broad-spread usage and the flood of bug reports > > until next spring so we may want to wait until then to stay deleting code. > > > > If we wanted to accelerate things, one option, once we're ready, would be > > to ask the person who manages the oibaf PPA to switch to crocus early. That > > may get some early adopters on board. > > > > Thoughts? It certainly is tempting to just throw away classic without going through this LTS branch adventure (I might say "charade") for distros. I really think that people with i8xx/r200/r100 are better served with swrast than HW GL in an otherwise-current world of software, and for an old-distro snapshot where lots of software *would* work on that hardware, what we do in current Mesa doesn't matter. i915's right at the cusp of usefulness in my opinion, and I'd put r300 pretty close to it. If we're acting like this LTS branch is a serious thing, though, then I don't see a good reason to wait until 2022. Let "did they build crocus" be the switch between current Mesa and LTS i965. I really want !8044 and garbage-collecting huge swaths of the GLSL compiler, and while 2022 may realistically be when we can do that by, I think we'll be slower about pushing on it if people are thinking "well, we can't delete anything till next year anyway". > > I though the idea was to put everything in a classic branch and let distros > > run "classic" hardware from that. What happens after 3 releases does i965 > > still go to the classic branch with the other classic drivers? If so is it > > really worth waiting just because Ubuntu might have to back-port a bug fix? > > Yeah, that was the idea. However, with crocus in good shape and Emma > Anholt working on i915g, it may be that the actual answer is we just > throw away the classic drivers and the only thing you really need the > old branch for is r200 and ancient nouveau. i915g still has major issues: large vertex count crashes, lack of link failures, and crashes on compile failures being the top ones. Once I get driver-produced link failures plumbed through gallium somehow (feels possible now that we precompile, and vc4 really needs it for conformance too) and the NIR stuff landed, I think it'll be a pretty plausible driver, and probably on average better for users than the bitrotted stuff we've shipped for the last decade. Regression-free would be a long road, though, and given a different compiler pipeline that might schedule differently plus the texture phase limits, possibly not tractable in practice. By far the limiting factor for i915g progress now that I've got some CI rigged up is review. My preference would be that we all agree that nobody wants to look at i915, and some responsible folks (ajax and a couple Intel volunteers, perhaps?) bless me to merge without review once an i915g-only MR has been up for a week. ___ 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
Why not proceed with splitting the classic drivers including i965 as was discussed previously? Then, when you feel that crocus and i915g are ready to be default, you can simply delete i965 from the classic branch and tell users they can use mesa main once again. On Tue, 2021-06-15 at 20:03 -0500, Jason Ekstrand wrote: > I'm bringing this up via e-mail so it gets a wider audience. Given > how will crocus is working at this point, is like to propose we hold > off for about three more releases before we drop classic. This next > release, 21.2, we'll have crocus as an option with i965 as the > default. There will also be a -Dprefer-crocus meson options so > distros or individuals can attempt to flip it on. The release after > that, 21.3, we'll keep i965 in the tree but have crocus be the > default (assuming things are going well.) Some time in 2022, probably > after the 22.2 release or so, we'll delete classic. > > Why wait so long? Well, it just landed and we don't have a Cherryview > story yet so I'm hesitant to make it the default too quickly. Even if > it were the default in 21.2, it's already too late, likely, to hit > the fall 2021 distro release cycle. If we flip it to the default > before the end of the year, that'll get crocus into spring distros. > This is good because 22.04 is an Ubuntu LTS release and I think > they'd rather bump crocus versions to fix bugs than backport on top > of i965. But that's really fort Ubuntu to decide. In any case, we > won't see broad-spread usage and the flood of bug reports until next > spring so we may want to wait until then to stay deleting code. > > If we wanted to accelerate things, one option, once we're ready, > would be to ask the person who manages the oibaf PPA to switch to > crocus early. That may get some early adopters on board. > > Thoughts? > > --Jason > > On April 9, 2021 22:09:14 Dylan Baker wrote: > > > Quoting Dylan Baker (2021-03-22 15:15:30) > > > 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 Meso
