Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches
On 2019-12-07 12:56 a.m., Rob Clark wrote: > On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen > wrote: >> >> On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer wrote: >>> >>> >>> I just merged >>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which >>> affects people who want to run the CI pipeline on personal Mesa branches: >>> >>> Pushing changes to a personal branch now always creates a pipeline, but >>> none of the jobs in it run by default. (There are no longer any special >>> branch names affecting this, because creating MRs from such special >>> branches resulted in duplicate CI job runs) >>> >>> The container stage jobs can be triggered manually from the GitLab UI >>> (and maybe also via the GitLab API, for people who'd like to automate >>> this? I haven't looked into that). The build/test stage jobs run >>> automatically once all their dependencies have passed. >>> >>> As an example, in order to run one of the "piglit-*" test jobs, one has >>> to manually trigger the "x86_build" and "x86_test" jobs. >>> >>> The pipelines created for merge requests still run all jobs by default >>> as before. >>> >>> >>> The main motivation for these changes is to avoid wasting CI runner >>> resources. In that same spirit, please also cancel any unneeded >>> build/test jobs. This can be done already before those jobs start >>> running, e.g. while the container stage jobs run. >> >> No complaint about not running the pipelines by default in personal >> repositories, but expecting people to cancel automatically spawned CI >> jobs as normal part of their workflow seems incredibly fiddly and >> fragile to me. I'm not sure what you mean by fragile, but maybe my wording was too strong. It's not really "expected", I just want people to be aware that CI runner resources are finite, and wasting them affects others as well as oneself. >> Are we *that* constrained? We are a bit privileged here in Europe, as things are usually calm during our mornings. For people in North America, it tends to be pretty painful to merge an MR. (If we had a merge bot, that should mostly eliminate that pain tough) > It would be nice if there was some way to setup some conservative > filters to exclude groups of tests, ie. if only paths changed were > under src/freedreno or src/gallium/drivers/freedreno, then no need to > run panfrost CI, and visa versa. We probably shouldn't try to fine > tune that *too* much at this risk of skipping tests that should have > run, but seems like there should be same safe low hanging fruit to cut > down on CI runs in common cases. Lots of people suggest something like this, but most of them probably imagine it to be easier than it actually is. :) See https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Moving v3d_format to broadcom
Anyone objecting to moving struct v3d_format and native defines from Gallium to Broadcom? I think it would make sense to use it similarly in Vulkan. Cheers Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths
From: Roland Scheidegger Braces mismatch (flagged by CI, untested). Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" --- src/util/u_atomic.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 9cbc6dd1eaa..1ad87c8feb1 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -89,7 +89,7 @@ #define p_atomic_dec_zero(_v) (p_atomic_dec_return(_v) == 0) #define p_atomic_inc(_v) ((void) p_atomic_inc_return(_v)) #define p_atomic_dec(_v) ((void) p_atomic_dec_return(_v)) -#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) +#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_inc_return(_v) (++(*(_v))) #define p_atomic_dec_return(_v) (--(*(_v))) #define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) @@ -146,7 +146,7 @@ (assert(!"should not get here"), 0)) #define p_atomic_add(_v, _i) \ - ((void) p_atomic_add_return((_v), (_i)) + ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_add_return(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths
Reviewed-by: Brian Paul On 12/09/2019 10:49 AM, srol...@vmware.com wrote: From: Roland Scheidegger Braces mismatch (flagged by CI, untested). Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" --- src/util/u_atomic.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 9cbc6dd1eaa..1ad87c8feb1 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -89,7 +89,7 @@ #define p_atomic_dec_zero(_v) (p_atomic_dec_return(_v) == 0) #define p_atomic_inc(_v) ((void) p_atomic_inc_return(_v)) #define p_atomic_dec(_v) ((void) p_atomic_dec_return(_v)) -#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) +#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_inc_return(_v) (++(*(_v))) #define p_atomic_dec_return(_v) (--(*(_v))) #define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) @@ -146,7 +146,7 @@ (assert(!"should not get here"), 0)) #define p_atomic_add(_v, _i) \ - ((void) p_atomic_add_return((_v), (_i)) + ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_add_return(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths
Reviewed-by: Jose Fonseca From: srol...@vmware.com Sent: Monday, December 9, 2019 17:49 To: Jose Fonseca ; ja...@jlekstrand.net ; mesa-dev@lists.freedesktop.org Cc: Roland Scheidegger Subject: [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths From: Roland Scheidegger Braces mismatch (flagged by CI, untested). Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" --- src/util/u_atomic.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 9cbc6dd1eaa..1ad87c8feb1 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -89,7 +89,7 @@ #define p_atomic_dec_zero(_v) (p_atomic_dec_return(_v) == 0) #define p_atomic_inc(_v) ((void) p_atomic_inc_return(_v)) #define p_atomic_dec(_v) ((void) p_atomic_dec_return(_v)) -#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) +#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_inc_return(_v) (++(*(_v))) #define p_atomic_dec_return(_v) (--(*(_v))) #define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) @@ -146,7 +146,7 @@ (assert(!"should not get here"), 0)) #define p_atomic_add(_v, _i) \ - ((void) p_atomic_add_return((_v), (_i)) + ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_add_return(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Is it time to stop using the mailing list for patch review?
Hi everyone, I think its time we discussed whether we're going to continue to do patch review on the mailing list, or if it it should all go through gitlab. I think we should stop using the mailing list, here are some reasons: 1) Most development is happening on gitlab at this point, patches on the mailing list are often overlooked 2) The mailing list bypasses CI which potentially breaks the build 3) Probably more reasons I'm forgetting. Please discuss, Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
So, I'm guilty of being one of the few still using the mailing list... But in any case, certainly I can switch to using MRs if everybody prefers that now (meaning, I'm really indifferent to this). Roland Am 10.12.19 um 00:07 schrieb Dylan Baker: > Hi everyone, > > I think its time we discussed whether we're going to continue to do patch > review > on the mailing list, or if it it should all go through gitlab. I think we > should > stop using the mailing list, here are some reasons: > > 1) Most development is happening on gitlab at this point, patches on the > mailing >list are often overlooked > 2) The mailing list bypasses CI which potentially breaks the build > 3) Probably more reasons I'm forgetting. > > Please discuss, > Dylan > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C1cb75dae042b4427ab2408d77cfc9cdc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637115296743272638&sdata=BmiwnAd%2BBZaZqqTwIYn0zqPOQ8jQ1pIzOqtyGhxuEN0%3D&reserved=0 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches
On Mon, Dec 9, 2019 at 2:27 AM Michel Dänzer wrote: > > On 2019-12-07 12:56 a.m., Rob Clark wrote: > > > It would be nice if there was some way to setup some conservative > > filters to exclude groups of tests, ie. if only paths changed were > > under src/freedreno or src/gallium/drivers/freedreno, then no need to > > run panfrost CI, and visa versa. We probably shouldn't try to fine > > tune that *too* much at this risk of skipping tests that should have > > run, but seems like there should be same safe low hanging fruit to cut > > down on CI runs in common cases. > > Lots of people suggest something like this, but most of them probably > imagine it to be easier than it actually is. :) > > See https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 . > yeah, it does seem like it is more complex than it sounds.. I'm glad to see there is some work on that. There are a lot more CI jobs that I'd *like* to be able to run (maybe some can be scheduled jobs rather than per-MR).. for example modern adreno can be both an IMR and a tiler, so we really have two different render paths which could have their own bugs.. I'd love to be able to test both forcing tiling and sysmem render paths.. maybe don't have to happen on every MR, but freeing up CI runner bandwidth to run additional tests seems useful. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
Do we plan to remove the patchwork action on push? Marek On Mon, Dec 9, 2019 at 9:10 PM Roland Scheidegger wrote: > So, I'm guilty of being one of the few still using the mailing list... > But in any case, certainly I can switch to using MRs if everybody > prefers that now (meaning, I'm really indifferent to this). > > Roland > > > Am 10.12.19 um 00:07 schrieb Dylan Baker: > > Hi everyone, > > > > I think its time we discussed whether we're going to continue to do > patch review > > on the mailing list, or if it it should all go through gitlab. I think > we should > > stop using the mailing list, here are some reasons: > > > > 1) Most development is happening on gitlab at this point, patches on the > mailing > >list are often overlooked > > 2) The mailing list bypasses CI which potentially breaks the build > > 3) Probably more reasons I'm forgetting. > > > > Please discuss, > > Dylan > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C1cb75dae042b4427ab2408d77cfc9cdc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637115296743272638&sdata=BmiwnAd%2BBZaZqqTwIYn0zqPOQ8jQ1pIzOqtyGhxuEN0%3D&reserved=0 > > > > ___ > 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
