Re: [Mesa-dev] [RFC] Concrete proposal to split classic
+1 We still have some CPU overhead performance targets we haven't reached. One of them is to decrease CPU overhead for one benchmark 4 times compared to everything we already have in master. I don't know how we are going to do that, but we'll try. Marek On Mon, Mar 22, 2021 at 6: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 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
On Tue, Mar 23, 2021 at 2:06 PM Simon Ser wrote: > > From a user-space point-of-view, this looks super useful! The uAPI sounds > good to me. > > Acked-by: Simon Ser > > Would be nice to have some short docs as well. Here's an example of a > patch adding some docs for an ioctl [1], if you aren't familiar with > that. I think just some basic stuff (description, which parameters are > in/out, what the flags are) would be great. Good call. v9 will have docs. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
>From a user-space point-of-view, this looks super useful! The uAPI sounds good to me. Acked-by: Simon Ser Would be nice to have some short docs as well. Here's an example of a patch adding some docs for an ioctl [1], if you aren't familiar with that. I think just some basic stuff (description, which parameters are in/out, what the flags are) would be great. [1]: https://patchwork.freedesktop.org/patch/401951/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
Adding mesa-dev and wayland-devel for broader circulation.
On Wed, Mar 17, 2021 at 5:19 PM Jason Ekstrand wrote:
>
> 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.
>
> v2 (Jason Ekstrand):
> - Use a wrapper dma_fence_array of all fences including the new one
>when importing an exclusive fence.
>
> v3 (Jason Ekstrand):
> - Lock around setting shared fences as well as exclusive
> - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> - Initialize ret to 0 in dma_buf_wait_sync_file
>
> v4 (Jason Ekstrand):
> - Use the new dma_resv_get_singleton helper
>
> v5 (Jason Ekstrand):
> - Rename the IOCTLs to import/export rather than wait/signal
> - Drop the WRITE flag and always get/set the exclusive fence
>
> v6 (Jason Ekstrand):
> - Drop the sync_file import as it was all-around sketchy and not nearly
>as useful as import.
> - Re-introduce READ/WRITE flag support for export
> - Rework the commit message
>
> v7 (Jason Ekstrand):
> - Require at least one sync flag
> - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
> - Use _rcu helpers since we're accessing the dma_resv read-only
>
> v8 (Jason Ekstrand):
> - Return -ENOMEM if the sync_file_create fails
> - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/dma-buf/dma-buf.c| 62
> include/uapi/linux/dma-buf.h | 6
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb..a5e4b0b6a049c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -362,6 +363,62 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> const char __user *buf)
> return ret;
> }
>
> +#if IS_ENABLED(CONFIG_SYNC_FILE)
> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
> +void __user *user_data)
> +{
> + struct dma_buf_sync_file arg;
> + struct dma_fence *fence = NULL;
> + struct sync_file *sync_file;
> + int fd, ret;
> +
> + if (copy_from_user(, user_data, sizeof(arg)))
> + return -EFAULT;
> +
> + if (arg.flags & ~DMA_BUF_SYNC_RW)
> + return -EINVAL;
> +
> + if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
> + return -EINVAL;
> +
> + fd = get_unused_fd_flags(O_CLOEXEC);
> + if (fd < 0)
> + return fd;
> +
> + if (arg.flags & DMA_BUF_SYNC_WRITE) {
> + ret = dma_resv_get_singleton_rcu(dmabuf->resv, );
> + if (ret)
> + goto err_put_fd;
> + } else if (arg.flags & DMA_BUF_SYNC_READ) {
> + fence = dma_resv_get_excl_rcu(dmabuf->resv);
> + }
> +
> + if (!fence)
> + fence = dma_fence_get_stub();
> +
> + sync_file = sync_file_create(fence);
> +
> + dma_fence_put(fence);
> +
> + if (!sync_file) {
> + ret = -ENOMEM;
> + goto err_put_fd;
> + }
> +
> + fd_install(fd, sync_file->file);
> +
> + arg.fd = fd;
> + if (copy_to_user(user_data, , sizeof(arg)))
> + return -EFAULT;
> +
> +
Re: [Mesa-dev] Rename "master" branch to "main"?
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 ___ 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, Mar 23, 2021 at 8:39 AM Kenneth Graunke wrote: > > On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote: > > On March 23, 2021 01:46:54 Kenneth Graunke wrote: > [snip] > > > One extra thought: can we also fork off anv Gen7.x support at the same > > > time? If distros are already going to be building i965 for Gen7.x from > > > that branch, building Vulkan from there should be easy as well. > > > > I'm not sure how I feel about that one. Here are some thoughts: > > > > 1. I'd love to have it out of the way > > 2. Unlike i965, it is still picking up features. Part of what makes > > dropping i965 a reasonable idea is that OpenGL is also in maintenance mode. > > Vulkan isn't. > > 3. Generally, things are architected well enough that relocations aren't a > > problem. > > 4. Being able to always do batch chaining would be nice. > > 5. The only new feature still in development for i965 is > > GL_EXT_external_objects. That would be more reliable if Gen7 ANV and i965 > > were in the same branch. > > 6. If crocus gets GL_EXT_external_objects, it'll be better if Gen7 ANV is > > in the master branch. > > 7. I'd love to stop caring about vec4. > > Point 2 is true. I'm not sure I agree about 3, the anv execbuf handling > is a lot more complicated than I think it needs to be. It's not great, I'll grant. But it's not too awful and, until we get rid of VM_BIND, we have to at least keep BO usage tracking even if we were able to drop relocations. > It would be really nice to cull vec4 and MRF support from the compiler > as well---and all of the vec4/fs code sharing and base classes. That > would be really nice. But, I guess that if crocus comes into existence, > then we need all that again. That's unfortunate :( Me too. There is some stuff I think we can drop. We can drop shader_time, for instance, as well as the param array and all the push constant re-arranging code. And, yeah, I'd love to drop vec4 but yeah... One advantage to keeping vec4 in the tree for some stuff is that it means we have full-featured hardware able to test vec4 NIR. That seems like a feature. --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 3/23/21 7:26 PM, 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. Is there any reason these could not just land in the forked classic branch? The consensus seems to be we would still be making the odd release of these forked drivers, unlike how the DRI1 drivers were put out to pasture. Ken already outlined a desire to still be able to add occasional features to i965. There is real momentum around cleaning up and optimising core Mesa at the moment, I'd really hate to see that slow down just because of a self imposed rule on what changes can land in a forked classic branch. I can't see there being to many MRs and releases required whether we applied a strict "build and critical bug fixes only" policy or just let any reasonable MR be accepted. I mean its not like there are MR flowing in for classic drivers now. Just to be clear I'm +1 for forking 21.1. 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 ___ 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] Rename "master" branch to "main"?
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? --Jason On Fri, Aug 7, 2020 at 3:38 AM Timur Kristóf wrote: > > On Thu, 2020-08-06 at 14:17 +0200, Eric Engestrom wrote: > > > > There is an upstream issue about having gitlab handle the branch > > renaming and provide redirections, MR re-targeting, etc. > > > > https://gitlab.com/gitlab-org/gitlab/-/issues/233427 > > > > If we wait for this feature instead of doing it by hand, it could be > > much less disruptive to devs and everyone downstream from us, but > > there's also no telling how long this will take. > > Sounds like this would save us a lot of hassle. If we are not in a > hurry, I think the best option for us is to wait for this upstream > issue. > > > ___ 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 Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote: > On March 23, 2021 01:46:54 Kenneth Graunke wrote: [snip] > > One extra thought: can we also fork off anv Gen7.x support at the same > > time? If distros are already going to be building i965 for Gen7.x from > > that branch, building Vulkan from there should be easy as well. > > I'm not sure how I feel about that one. Here are some thoughts: > > 1. I'd love to have it out of the way > 2. Unlike i965, it is still picking up features. Part of what makes > dropping i965 a reasonable idea is that OpenGL is also in maintenance mode. > Vulkan isn't. > 3. Generally, things are architected well enough that relocations aren't a > problem. > 4. Being able to always do batch chaining would be nice. > 5. The only new feature still in development for i965 is > GL_EXT_external_objects. That would be more reliable if Gen7 ANV and i965 > were in the same branch. > 6. If crocus gets GL_EXT_external_objects, it'll be better if Gen7 ANV is > in the master branch. > 7. I'd love to stop caring about vec4. Point 2 is true. I'm not sure I agree about 3, the anv execbuf handling is a lot more complicated than I think it needs to be. It would be really nice to cull vec4 and MRF support from the compiler as well---and all of the vec4/fs code sharing and base classes. That would be really nice. But, I guess that if crocus comes into existence, then we need all that again. That's unfortunate :( --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 March 23, 2021 01:46:54 Kenneth Graunke wrote: On Monday, March 22, 2021 3:15:30 PM PDT 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 Hi Dylan, I largely like this plan. i915 and r200 and novueau_vieux definitely need to be forked off, to keep them working as we do core refactors. In the past, we weren't working on core much, and so they largely kept working with some pain, but not -too- much effort. But these days, we're seeing a lot of work from Marek and others to clean up and rework a lot of core drawing code, state upload code, and so on. I remember all the work Tim did to rework uniform handling and ancient classic was a pain point for him as well. I had to track down like 5 overlapping Piglit regressions on i915 this release cycle, just to get the driver working...no worse than it was before. And i915 is tested regularly in the Intel CI. r200 isn't tested regularly. Doubtful about vieux. I had thought about also forking other old drivers like i915g or r300g. But it sounds like there's still some interest in i915g, and those tend to get fixed up as the Gallium infrastructure is still actively being maintained (unlike things like swrast and tnl). So I guess we can leave those in mainline. I'm hesitant about i965. One thing I will say is that, if i965 is included in the plan, there would probably be more interest in working on that branch than mere "critical bug fixes" as you defined. We might discover new games that don't work; people might write bug fixes for i965, at which point we should merge and ship them. But we could still do on-demand releases when enough interesting bug fixes have piled up, rather than doing them on a schedule. That should hopefully not be too burdensome. While a part of me hates the idea of forking i965 off, I think it may actually be the best call. We haven't done any new interesting feature development on those platforms in ages, and they're complete in terms of OpenGL spec support. We aren't spending any time optimizing performance on those platforms. They're pretty much in bug-fix-only mode already. Whether that bug fixing happens on master or on a "classic-lts" branch doesn't matter; it
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
I'd like to see it happen, though I don't understand how to make these coexist for distros. Would like to hear from the Debian/etc maintainers of mesa. Then again I *think* classic-lts doesn't need to be built for armhf/arm64 at all, so I suppose I'm personally unaffected :-P On Mon, Mar 22, 2021 at 03:15:30PM -0700, 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 ___ 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
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 > ___ 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 Monday, March 22, 2021 3:15:30 PM PDT 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 Hi Dylan, I largely like this plan. i915 and r200 and novueau_vieux definitely need to be forked off, to keep them working as we do core refactors. In the past, we weren't working on core much, and so they largely kept working with some pain, but not -too- much effort. But these days, we're seeing a lot of work from Marek and others to clean up and rework a lot of core drawing code, state upload code, and so on. I remember all the work Tim did to rework uniform handling and ancient classic was a pain point for him as well. I had to track down like 5 overlapping Piglit regressions on i915 this release cycle, just to get the driver working...no worse than it was before. And i915 is tested regularly in the Intel CI. r200 isn't tested regularly. Doubtful about vieux. I had thought about also forking other old drivers like i915g or r300g. But it sounds like there's still some interest in i915g, and those tend to get fixed up as the Gallium infrastructure is still actively being maintained (unlike things like swrast and tnl). So I guess we can leave those in mainline. I'm hesitant about i965. One thing I will say is that, if i965 is included in the plan, there would probably be more interest in working on that branch than mere "critical bug fixes" as you defined. We might discover new games that don't work; people might write bug fixes for i965, at which point we should merge and ship them. But we could still do on-demand releases when enough interesting bug fixes have piled up, rather than doing them on a schedule. That should hopefully not be too burdensome. While a part of me hates the idea of forking i965 off, I think it may actually be the best call. We haven't done any new interesting feature development on those platforms in ages, and they're complete in terms of OpenGL spec support. We aren't spending any time optimizing performance on those platforms. They're pretty much in bug-fix-only mode already. Whether
