Re: [Mesa-dev] [PATCH] radeonsi: fix Segmentation fault during vaapi enc test
Hi James, We use gitlab for merge requests and pushing: https://www.mesa3d.org/submittingpatches.html Marek On Mon, Apr 6, 2020 at 2:12 PM James Zhu wrote: > Fix Segmentation fault duiring vaapi enc test on Arcturus. > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeonsi/si_compute_blit.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c > b/src/gallium/drivers/radeonsi/si_compute_blit.c > index 6e3b07c..a56676a 100644 > --- a/src/gallium/drivers/radeonsi/si_compute_blit.c > +++ b/src/gallium/drivers/radeonsi/si_compute_blit.c > @@ -63,7 +63,8 @@ static void si_launch_grid_internal(struct si_context > *sctx, struct pipe_grid_in > sctx->flags |= SI_CONTEXT_STOP_PIPELINE_STATS; > sctx->render_cond_force_off = true; > /* Skip decompression to prevent infinite recursion. */ > - sctx->blitter->running = true; > + if (sctx->blitter) > + blitter->running = true; > > /* Dispatch compute. */ > sctx->b.launch_grid(>b, info); > @@ -72,7 +73,8 @@ static void si_launch_grid_internal(struct si_context > *sctx, struct pipe_grid_in > sctx->flags &= ~SI_CONTEXT_STOP_PIPELINE_STATS; > sctx->flags |= SI_CONTEXT_START_PIPELINE_STATS; > sctx->render_cond_force_off = false; > - sctx->blitter->running = false; > + if (sctx->blitter) > + sctx->blitter->running = false; > } > > static void si_compute_clear_12bytes_buffer(struct si_context *sctx, > struct pipe_resource *dst, > -- > 2.7.4 > > ___ > 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] [PATCH v2] radeonsi: fix Segmentation fault during vaapi enc test
Fix Segmentation fault duiring vaapi enc test on Arcturus. v2: fix typo Signed-off-by: James Zhu --- src/gallium/drivers/radeonsi/si_compute_blit.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c b/src/gallium/drivers/radeonsi/si_compute_blit.c index 6e3b07c..0a81c68 100644 --- a/src/gallium/drivers/radeonsi/si_compute_blit.c +++ b/src/gallium/drivers/radeonsi/si_compute_blit.c @@ -63,7 +63,8 @@ static void si_launch_grid_internal(struct si_context *sctx, struct pipe_grid_in sctx->flags |= SI_CONTEXT_STOP_PIPELINE_STATS; sctx->render_cond_force_off = true; /* Skip decompression to prevent infinite recursion. */ - sctx->blitter->running = true; + if (sctx->blitter) + sctx->blitter->running = true; /* Dispatch compute. */ sctx->b.launch_grid(>b, info); @@ -72,7 +73,8 @@ static void si_launch_grid_internal(struct si_context *sctx, struct pipe_grid_in sctx->flags &= ~SI_CONTEXT_STOP_PIPELINE_STATS; sctx->flags |= SI_CONTEXT_START_PIPELINE_STATS; sctx->render_cond_force_off = false; - sctx->blitter->running = false; + if (sctx->blitter) + sctx->blitter->running = false; } static void si_compute_clear_12bytes_buffer(struct si_context *sctx, struct pipe_resource *dst, -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: fix Segmentation fault during vaapi enc test
Fix Segmentation fault duiring vaapi enc test on Arcturus. Signed-off-by: James Zhu --- src/gallium/drivers/radeonsi/si_compute_blit.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c b/src/gallium/drivers/radeonsi/si_compute_blit.c index 6e3b07c..a56676a 100644 --- a/src/gallium/drivers/radeonsi/si_compute_blit.c +++ b/src/gallium/drivers/radeonsi/si_compute_blit.c @@ -63,7 +63,8 @@ static void si_launch_grid_internal(struct si_context *sctx, struct pipe_grid_in sctx->flags |= SI_CONTEXT_STOP_PIPELINE_STATS; sctx->render_cond_force_off = true; /* Skip decompression to prevent infinite recursion. */ - sctx->blitter->running = true; + if (sctx->blitter) + blitter->running = true; /* Dispatch compute. */ sctx->b.launch_grid(>b, info); @@ -72,7 +73,8 @@ static void si_launch_grid_internal(struct si_context *sctx, struct pipe_grid_in sctx->flags &= ~SI_CONTEXT_STOP_PIPELINE_STATS; sctx->flags |= SI_CONTEXT_START_PIPELINE_STATS; sctx->render_cond_force_off = false; - sctx->blitter->running = false; + if (sctx->blitter) + sctx->blitter->running = false; } static void si_compute_clear_12bytes_buffer(struct si_context *sctx, struct pipe_resource *dst, -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > > to automatically trigger dependencies of that job (meson-arm64, and > > arm_build+arm_test). But not sure if that is a thing gitlab can do. > > Not that I know of. The dependency handling is still pretty rudimentary > in general. > > > > Triggering just the first container jobs and having everything from > > there run automatically would be ok if the current rules to filter out > > unneeded jobs still apply, ie. a panfrost change isn't triggering > > freedreno CI jobs and visa versa. But tbh I don't understand enough > > of what that MR is doing to understand if that is what it does. (It > > was suggested on IRC that this is probably what it does.) > > It is. Filtered jobs don't exist at all in the pipeline, so they can't > be triggered by any means. :) > ahh, ok, I didn't realize that.. thx for the explaination BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services
On 2020-04-06 6:34 p.m., Rob Clark wrote: > > The ideal thing would be to be able to click any jobs that we want to > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > to automatically trigger dependencies of that job (meson-arm64, and > arm_build+arm_test). But not sure if that is a thing gitlab can do. Not that I know of. The dependency handling is still pretty rudimentary in general. > Triggering just the first container jobs and having everything from > there run automatically would be ok if the current rules to filter out > unneeded jobs still apply, ie. a panfrost change isn't triggering > freedreno CI jobs and visa versa. But tbh I don't understand enough > of what that MR is doing to understand if that is what it does. (It > was suggested on IRC that this is probably what it does.) It is. Filtered jobs don't exist at all in the pipeline, so they can't be triggered by any means. :) -- 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
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > I think that's mostly a complaint about the conditionals we've written > so far, tbh. As I commented on the bug, when I clicked the container > job (which the rules happen to have evaluated to being "manual"), every > job (recursively) downstream of it got enqueued, which isn't what > you're describing. So I think if you can describe the UX you'd like we > can write rules to make that reality. Ok, I was fearing that we'd have to manually trigger each stage of dependencies in the pipeline. Which wouldn't be so bad except that gitlab makes you wait for the previous stage to complete before triggering the next one. The ideal thing would be to be able to click any jobs that we want to run, say "arm64_a630_gles31", and for gitlab to realize that it needs to automatically trigger dependencies of that job (meson-arm64, and arm_build+arm_test). But not sure if that is a thing gitlab can do. Triggering just the first container jobs and having everything from there run automatically would be ok if the current rules to filter out unneeded jobs still apply, ie. a panfrost change isn't triggering freedreno CI jobs and visa versa. But tbh I don't understand enough of what that MR is doing to understand if that is what it does. (It was suggested on IRC that this is probably what it does.) BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I *think* this should work though if you set up the right job dependencies. very simple example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128601 job1 is "when:manual", job2 has "needs: job1", job3 has "needs: job2". Nothing runs at first, if you trigger job1 it'll cascade down to job 2 and 3. The main limit you have here are the stages - where a job is part of a stage but does not have an explicit "needs:" it will wait for the previous stage to complete. That will never happen if one job in that stage has a manual dependency. See this pipeline as an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128605 So basically: if you set up all your jobs with the correct "needs" you could even have a noop stage for user interface purposes. Here's an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128606 It has a UI stage with "test-arm" and "test-x86" manual jobs. It has other stages with dependent jobs on those (cascading down) but it also has a set of autorun jobs that run independent of the manual triggers. When you push, the autorun jobs run. When you trigger "test-arm" manually, it triggers the various dependent jobs. So I think what you want to do is possible, it just requires some tweaking of the "needs" entries. Cheers, Peter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote: > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > strictly > > > > > pre-merge CI. > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > click first the container jobs.. then wait.. then the build jobs.. > > > then wait some more.. and then finally the actual runners. That would > > > be a real step back in terms of usefulness of CI.. one might call it a > > > regression :-( > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > As we use needs: between jobs, we could simply set the first job to > > manual (in our case it's a single job called manifest in your case it > > would be the N container jobs). This way you can have a manual pipeline > > that is triggered in single (or fewer) clicks. Here's an example: > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > That our post-merge pipelines, we only trigger then if we suspect a > > problem. > > > > I'm not sure that would work for mesa since the hierarchy of jobs > branches out pretty far.. ie. if I just clicked the arm64 build + test > container jobs, and everything else ran automatically after that, it > would end up running all the CI jobs for all the arm devices (or at > least all the 64b ones) generate your gitlab-ci from a template so each pipeline has its own job dependency. The duplication won't hurt you if it's expanded through templating and it gives you fine-grained running of the manual jobs. We're using this in ci-templates/libevdev/libinput for the various distributions and their versions so each distribution+version is effectively its own pipeline. But we only need to maintain one job in the actual template file. https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-ci-yml Cheers, Peter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
