Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
There is a fix for queries on the mailing list somewhere.
Marek
Marek
On Thu, May 16, 2019, 7:08 PM Jan Vesely wrote:
> On Tue, 2019-02-12 at 13:12 -0500, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > initialize all non-compute context functions to NULL.
> >
> > v2: fix SI
> > ---
> > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
> > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > 11 files changed, 130 insertions(+), 75 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> b/src/gallium/drivers/radeonsi/si_blit.c
> > index bb8d1cbd12d..f39cb5d143f 100644
> > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> pipe_context *ctx,
> >
> > if (separate_dcc_dirty) {
> > tex->separate_dcc_dirty = false;
> > vi_separate_dcc_process_and_reset_stats(ctx, tex);
> > }
> > }
> > }
> >
> > void si_decompress_dcc(struct si_context *sctx, struct si_texture *tex)
> > {
> > - if (!tex->dcc_offset)
> > + /* If graphics is disabled, we can't decompress DCC, but it
> shouldn't
> > + * be compressed either. The caller should simply discard it.
> > + */
> > + if (!tex->dcc_offset || !sctx->has_graphics)
> > return;
> >
> > si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
> >0, util_max_layer(&tex->buffer.b.b, 0),
> >true);
> > }
> >
> > void si_init_blit_functions(struct si_context *sctx)
> > {
> > sctx->b.resource_copy_region = si_resource_copy_region;
> > - sctx->b.blit = si_blit;
> > - sctx->b.flush_resource = si_flush_resource;
> > - sctx->b.generate_mipmap = si_generate_mipmap;
> > +
> > + if (sctx->has_graphics) {
> > + sctx->b.blit = si_blit;
> > + sctx->b.flush_resource = si_flush_resource;
> > + sctx->b.generate_mipmap = si_generate_mipmap;
> > + }
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> b/src/gallium/drivers/radeonsi/si_clear.c
> > index 9a00bb73b94..e1805f2a1c9 100644
> > --- a/src/gallium/drivers/radeonsi/si_clear.c
> > +++ b/src/gallium/drivers/radeonsi/si_clear.c
> > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
> *pipe,
> > util_clear_render_target(pipe, sf, &color,
> >box->x, box->y,
> >box->width, box->height);
> > }
> > }
> > pipe_surface_reference(&sf, NULL);
> > }
> >
> > void si_init_clear_functions(struct si_context *sctx)
> > {
> > - sctx->b.clear = si_clear;
> > sctx->b.clear_render_target = si_clear_render_target;
> > - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> > sctx->b.clear_texture = si_clear_texture;
> > +
> > + if (sctx->has_graphics) {
> > + sctx->b.clear = si_clear;
> > + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> > + }
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> > index 1a62b3e0844..87addd53976 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -880,26 +880,28 @@ static void si_launch_grid(
> > info->block[0] * info->block[1] * info->block[2] > 256;
> >
> > if (cs_regalloc_hang)
> > sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> >SI_CONTEXT_CS_PARTIAL_FLUSH;
> >
> > if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
> > program->shader.compilation_failed)
> > return;
> >
> > - if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> > - si_update_fb_dirtiness_after_rendering(sctx);
> > - sctx->last_num_draw_calls = sctx->num_draw_calls;
> > - }
> > + if (sctx->has_graphics) {
> > + if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> > + si_update_fb_dirtiness_after_rendering(sctx);
> > + sctx->last_num_draw_calls = sctx->num_draw_calls;
> > + }
> >
> > - si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
> > +
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Tue, 2019-02-12 at 13:12 -0500, Marek Olšák wrote:
> From: Marek Olšák
>
> initialize all non-compute context functions to NULL.
>
> v2: fix SI
> ---
> src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
> src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> src/gallium/drivers/radeonsi/si_state.c | 3 +-
> src/gallium/drivers/radeonsi/si_state.h | 1 +
> src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> src/gallium/drivers/radeonsi/si_texture.c | 3 +
> 11 files changed, 130 insertions(+), 75 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> b/src/gallium/drivers/radeonsi/si_blit.c
> index bb8d1cbd12d..f39cb5d143f 100644
> --- a/src/gallium/drivers/radeonsi/si_blit.c
> +++ b/src/gallium/drivers/radeonsi/si_blit.c
> @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct pipe_context
> *ctx,
>
> if (separate_dcc_dirty) {
> tex->separate_dcc_dirty = false;
> vi_separate_dcc_process_and_reset_stats(ctx, tex);
> }
> }
> }
>
> void si_decompress_dcc(struct si_context *sctx, struct si_texture *tex)
> {
> - if (!tex->dcc_offset)
> + /* If graphics is disabled, we can't decompress DCC, but it shouldn't
> + * be compressed either. The caller should simply discard it.
> + */
> + if (!tex->dcc_offset || !sctx->has_graphics)
> return;
>
> si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
>0, util_max_layer(&tex->buffer.b.b, 0),
>true);
> }
>
> void si_init_blit_functions(struct si_context *sctx)
> {
> sctx->b.resource_copy_region = si_resource_copy_region;
> - sctx->b.blit = si_blit;
> - sctx->b.flush_resource = si_flush_resource;
> - sctx->b.generate_mipmap = si_generate_mipmap;
> +
> + if (sctx->has_graphics) {
> + sctx->b.blit = si_blit;
> + sctx->b.flush_resource = si_flush_resource;
> + sctx->b.generate_mipmap = si_generate_mipmap;
> + }
> }
> diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> b/src/gallium/drivers/radeonsi/si_clear.c
> index 9a00bb73b94..e1805f2a1c9 100644
> --- a/src/gallium/drivers/radeonsi/si_clear.c
> +++ b/src/gallium/drivers/radeonsi/si_clear.c
> @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context *pipe,
> util_clear_render_target(pipe, sf, &color,
>box->x, box->y,
>box->width, box->height);
> }
> }
> pipe_surface_reference(&sf, NULL);
> }
>
> void si_init_clear_functions(struct si_context *sctx)
> {
> - sctx->b.clear = si_clear;
> sctx->b.clear_render_target = si_clear_render_target;
> - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> sctx->b.clear_texture = si_clear_texture;
> +
> + if (sctx->has_graphics) {
> + sctx->b.clear = si_clear;
> + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> + }
> }
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 1a62b3e0844..87addd53976 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -880,26 +880,28 @@ static void si_launch_grid(
> info->block[0] * info->block[1] * info->block[2] > 256;
>
> if (cs_regalloc_hang)
> sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
>SI_CONTEXT_CS_PARTIAL_FLUSH;
>
> if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
> program->shader.compilation_failed)
> return;
>
> - if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> - si_update_fb_dirtiness_after_rendering(sctx);
> - sctx->last_num_draw_calls = sctx->num_draw_calls;
> - }
> + if (sctx->has_graphics) {
> + if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> + si_update_fb_dirtiness_after_rendering(sctx);
> + sctx->last_num_draw_calls = sctx->num_draw_calls;
> + }
>
> - si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
> + si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
> + }
>
> /* Add buffer sizes for memory checking in need_cs_space. */
> si_context_add_resource_size(sctx, &program->shader.bo->b.b);
> /* TODO: add the scratch buffer */
>
> if (info->indirect) {
> si_context_add_re
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Mon, Apr 8, 2019 at 10:46 AM Michel Dänzer wrote: > > On 2019-04-02 4:00 p.m., Michel Dänzer wrote: > > On 2019-04-02 2:57 p.m., Marek Olšák wrote: > >> On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: > >>> On 2019-04-02 12:39 a.m., Marek Olšák wrote: > On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely > >>> wrote: > > On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > >> Does the attached patch fix the copy-buffer test? > > > > it does thanks. > > Won't the compute only context still need some synchronization? > > Is there anything else to guarantee that the data is in place after > > return from resource_copy_region ? > > The synchronization is the same on gfx and compute rings. > >>> > >>> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 > >>> ? It does indicate some kind of synchronization issue between > >>> si_resource_copy_region using a compute ring and other operations using > >>> a GFX ring. > >> > >> Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. > > > > That bugzilla comment is about the GTK menu issue, not about xterm. > > Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it > > was probably an invalid bisect result then. > > Apparently not, after all: > > https://bugs.freedesktop.org/110355 > > Looks like there is some issue with si_compute_copy_image, even if it > doesn't use a compute ring. Then there's also the old problem of SI hangs when using compute shared clears: https://bugs.freedesktop.org/show_bug.cgi?id=108879 Jan > > > -- > Earthling Michel Dänzer | https://www.amd.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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On 2019-04-02 4:00 p.m., Michel Dänzer wrote: > On 2019-04-02 2:57 p.m., Marek Olšák wrote: >> On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: >>> On 2019-04-02 12:39 a.m., Marek Olšák wrote: On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely >>> wrote: > On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: >> Does the attached patch fix the copy-buffer test? > > it does thanks. > Won't the compute only context still need some synchronization? > Is there anything else to guarantee that the data is in place after > return from resource_copy_region ? The synchronization is the same on gfx and compute rings. >>> >>> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 >>> ? It does indicate some kind of synchronization issue between >>> si_resource_copy_region using a compute ring and other operations using >>> a GFX ring. >> >> Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. > > That bugzilla comment is about the GTK menu issue, not about xterm. > Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it > was probably an invalid bisect result then. Apparently not, after all: https://bugs.freedesktop.org/110355 Looks like there is some issue with si_compute_copy_image, even if it doesn't use a compute ring. -- Earthling Michel Dänzer | https://www.amd.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] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On 2019-04-02 2:57 p.m., Marek Olšák wrote: > On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: >> On 2019-04-02 12:39 a.m., Marek Olšák wrote: >>> On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely >> wrote: On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > Does the attached patch fix the copy-buffer test? it does thanks. Won't the compute only context still need some synchronization? Is there anything else to guarantee that the data is in place after return from resource_copy_region ? >>> >>> The synchronization is the same on gfx and compute rings. >> >> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 >> ? It does indicate some kind of synchronization issue between >> si_resource_copy_region using a compute ring and other operations using >> a GFX ring. > > Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. That bugzilla comment is about the GTK menu issue, not about xterm. Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it was probably an invalid bisect result then. Thanks, -- Earthling Michel Dänzer | https://www.amd.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] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: > On 2019-04-02 12:39 a.m., Marek Olšák wrote: > > On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely > wrote: > >> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > >>> Does the attached patch fix the copy-buffer test? > >> > >> it does thanks. > >> Won't the compute only context still need some synchronization? > >> Is there anything else to guarantee that the data is in place after > >> return from resource_copy_region ? > > > > The synchronization is the same on gfx and compute rings. > > BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 > ? It does indicate some kind of synchronization issue between > si_resource_copy_region using a compute ring and other operations using > a GFX ring. > Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On 2019-04-02 12:39 a.m., Marek Olšák wrote: > On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely wrote: >> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: >>> Does the attached patch fix the copy-buffer test? >> >> it does thanks. >> Won't the compute only context still need some synchronization? >> Is there anything else to guarantee that the data is in place after >> return from resource_copy_region ? > > The synchronization is the same on gfx and compute rings. BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 ? It does indicate some kind of synchronization issue between si_resource_copy_region using a compute ring and other operations using a GFX ring. -- Earthling Michel Dänzer | https://www.amd.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] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely wrote: > On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > > Does the attached patch fix the copy-buffer test? > > it does thanks. > Won't the compute only context still need some synchronization? > Is there anything else to guarantee that the data is in place after > return from resource_copy_region ? > The synchronization is the same on gfx and compute rings. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote:
> Does the attached patch fix the copy-buffer test?
it does thanks.
Won't the compute only context still need some synchronization?
Is there anything else to guarantee that the data is in place after
return from resource_copy_region ?
thanks,
Jan
>
> Thanks,
> Marek
>
> On Sat, Mar 2, 2019 at 10:58 PM Jan Vesely wrote:
>
> > On Thu, 2019-02-28 at 17:48 -0500, Marek Olšák wrote:
> > > On Thu, Feb 28, 2019 at 4:44 AM Jan Vesely
> > wrote:
> > > > On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> > > > > I ran a simple test verifying that compute is working properly on the
> > > > > compute ring.
> > > >
> > > > I guess this was not on raven? With his patch I no loner see gfx
> > > > timeout but the apps still hang. anyway that's a separate issue.
> > > >
> > >
> > > If clover hangs, gfx timeouts are now compute timeouts, which might not
> > be
> > > printed in dmesg. It's still a hang, it just doesn't always affect gfx.
> >
> > thanks, that one has been bisected and identified [0].
> > This patch however causes hangs in cl-api-enqueue-copy-buffer on all
> > GCN hw I got to test (raven, carrizo, iceland).
> >
> > Jan
> >
> > [0]
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109649&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C76649a348e53469404b208d6b6bf74eb%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636897330772678063&sdata=WqP9bVyGbJjYcY9RKOjC2AWmEZMN8px0PBocRlkGYPA%3D&reserved=0
> >
> > > Marek
> > >
> > >
> > > > > When clover is using compute rings, it doesn't stall/block graphics
> > > > > operations.
> > > >
> > > > I'd be nice to include this information in the commit message.
> > > >
> > > > Jan
> > > >
> > > > > Marek
> > > > >
> > > > > On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely
> > > >
> > > > wrote:
> > > > > > Can you add a bit of background why clover should/should not use
> > other
> > > > > > rings?
> > > > > >
> > > > > > I planned to test this, but my raven system can't run clover since
> > > >
> > > > kernel
> > > > > > 4.20 release (BZ 109649), so I need to bisect that first.
> > > > > > Can this patch help address the soft lockup issue on CIK (BZ
> > 108879)?
> > > > > > presumably, it was tested using clover on CIK, right?
> > > > > >
> > > > > > Jan
> > > > > >
> > > > > > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák
> > wrote:
> > > > > > > I'll just push it.
> > > > > > >
> > > > > > > Marek
> > > > > > >
> > > > > > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel <
> > die...@nuetzel-hh.de>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello Marek,
> > > > > > > >
> > > > > > > > this series need a rebase (if you have some time).
> > > > > > > >
> > > > > > > > Dieter
> > > > > > > >
> > > > > > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > > > > > From: Marek Olšák
> > > > > > > > >
> > > > > > > > > initialize all non-compute context functions to NULL.
> > > > > > > > >
> > > > > > > > > v2: fix SI
> > > > > > > > > ---
> > > > > > > > > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > > > > > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > > > > > > > > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > > > > > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > > > > > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > > > > > > > > src/gallium/drivers/radeonsi/si_pipe.c| 95
> > > >
> > > > +++
> > > > > > > > > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > > > > > > > > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > > > > > > > > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > > > > > > > > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > > > > > > > > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > > > > > > > > 11 files changed, 130 insertions(+), 75 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > > > > > pipe_context *ctx,
> > > > > > > > >
> > > > > > > > > if (separate_dcc_dirty) {
> > > > > > > > > tex->separate_dcc_dirty = false;
> > > > > > > > >
> > > >
> > > > vi_separate_dcc_process_and_reset_stats(ctx,
> > > > > > > > tex);
> > > > > > > > > }
> > > > > > > > > }
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > void si_decompress_dcc(struct si_context *sctx, struct
> > > >
> > > > si_texture
> > > > > > > > > *tex)
> > > > > > > > > {
> > > > > > > > > - if (!tex->dcc_offset)
> > > > > >
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Thu, 2019-02-28 at 17:48 -0500, Marek Olšák wrote:
> On Thu, Feb 28, 2019 at 4:44 AM Jan Vesely wrote:
>
> > On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> > > I ran a simple test verifying that compute is working properly on the
> > > compute ring.
> >
> > I guess this was not on raven? With his patch I no loner see gfx
> > timeout but the apps still hang. anyway that's a separate issue.
> >
>
> If clover hangs, gfx timeouts are now compute timeouts, which might not be
> printed in dmesg. It's still a hang, it just doesn't always affect gfx.
thanks, that one has been bisected and identified [0].
This patch however causes hangs in cl-api-enqueue-copy-buffer on all
GCN hw I got to test (raven, carrizo, iceland).
Jan
[0] https://bugs.freedesktop.org/show_bug.cgi?id=109649
>
> Marek
>
>
> >
> > >
> > > When clover is using compute rings, it doesn't stall/block graphics
> > > operations.
> >
> > I'd be nice to include this information in the commit message.
> >
> > Jan
> >
> > >
> > > Marek
> > >
> > > On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely
> >
> > wrote:
> > >
> > > > Can you add a bit of background why clover should/should not use other
> > > > rings?
> > > >
> > > > I planned to test this, but my raven system can't run clover since
> >
> > kernel
> > > > 4.20 release (BZ 109649), so I need to bisect that first.
> > > > Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> > > > presumably, it was tested using clover on CIK, right?
> > > >
> > > > Jan
> > > >
> > > > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák wrote:
> > > >
> > > > > I'll just push it.
> > > > >
> > > > > Marek
> > > > >
> > > > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel
> > > > > wrote:
> > > > >
> > > > > > Hello Marek,
> > > > > >
> > > > > > this series need a rebase (if you have some time).
> > > > > >
> > > > > > Dieter
> > > > > >
> > > > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > > > From: Marek Olšák
> > > > > > >
> > > > > > > initialize all non-compute context functions to NULL.
> > > > > > >
> > > > > > > v2: fix SI
> > > > > > > ---
> > > > > > > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > > > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > > > > > > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > > > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > > > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > > > > > > src/gallium/drivers/radeonsi/si_pipe.c| 95
> >
> > +++
> > > > > > > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > > > > > > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > > > > > > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > > > > > > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > > > > > > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > > > > > > 11 files changed, 130 insertions(+), 75 deletions(-)
> > > > > > >
> > > > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > > > pipe_context *ctx,
> > > > > > >
> > > > > > > if (separate_dcc_dirty) {
> > > > > > > tex->separate_dcc_dirty = false;
> > > > > > >
> >
> > vi_separate_dcc_process_and_reset_stats(ctx,
> > > > > >
> > > > > > tex);
> > > > > > > }
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > void si_decompress_dcc(struct si_context *sctx, struct
> >
> > si_texture
> > > > > > > *tex)
> > > > > > > {
> > > > > > > - if (!tex->dcc_offset)
> > > > > > > + /* If graphics is disabled, we can't decompress DCC, but it
> > > > > >
> > > > > > shouldn't
> > > > > > > + * be compressed either. The caller should simply discard
> >
> > it.
> > > > > > > + */
> > > > > > > + if (!tex->dcc_offset || !sctx->has_graphics)
> > > > > > > return;
> > > > > > >
> > > > > > > si_blit_decompress_color(sctx, tex, 0,
> > > > > >
> > > > > > tex->buffer.b.b.last_level,
> > > > > > >0,
> >
> > util_max_layer(&tex->buffer.b.b, 0),
> > > > > > >true);
> > > > > > > }
> > > > > > >
> > > > > > > void si_init_blit_functions(struct si_context *sctx)
> > > > > > > {
> > > > > > > sctx->b.resource_copy_region = si_resource_copy_region;
> > > > > > > - sctx->b.blit = si_blit;
> > > > > > > - sctx->b.flush_resource = si_flush_resource;
> > > > > > > - sctx->b.generate_mipmap = si_generate_mipmap;
> > > > > > > +
> > > > > > > + if (sctx->has_graphics) {
> > > > > > > + sctx->b.blit = si_blit;
> > > > > >
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Thu, Feb 28, 2019 at 4:44 AM Jan Vesely wrote:
> On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> > I ran a simple test verifying that compute is working properly on the
> > compute ring.
>
> I guess this was not on raven? With his patch I no loner see gfx
> timeout but the apps still hang. anyway that's a separate issue.
>
If clover hangs, gfx timeouts are now compute timeouts, which might not be
printed in dmesg. It's still a hang, it just doesn't always affect gfx.
Marek
>
> >
> > When clover is using compute rings, it doesn't stall/block graphics
> > operations.
>
> I'd be nice to include this information in the commit message.
>
> Jan
>
> >
> > Marek
> >
> > On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely
> wrote:
> >
> > > Can you add a bit of background why clover should/should not use other
> > > rings?
> > >
> > > I planned to test this, but my raven system can't run clover since
> kernel
> > > 4.20 release (BZ 109649), so I need to bisect that first.
> > > Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> > > presumably, it was tested using clover on CIK, right?
> > >
> > > Jan
> > >
> > > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák wrote:
> > >
> > > > I'll just push it.
> > > >
> > > > Marek
> > > >
> > > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel
> > > > wrote:
> > > >
> > > > > Hello Marek,
> > > > >
> > > > > this series need a rebase (if you have some time).
> > > > >
> > > > > Dieter
> > > > >
> > > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > > From: Marek Olšák
> > > > > >
> > > > > > initialize all non-compute context functions to NULL.
> > > > > >
> > > > > > v2: fix SI
> > > > > > ---
> > > > > > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > > > > > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > > > > > src/gallium/drivers/radeonsi/si_pipe.c| 95
> +++
> > > > > > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > > > > > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > > > > > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > > > > > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > > > > > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > > > > > 11 files changed, 130 insertions(+), 75 deletions(-)
> > > > > >
> > > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > > pipe_context *ctx,
> > > > > >
> > > > > > if (separate_dcc_dirty) {
> > > > > > tex->separate_dcc_dirty = false;
> > > > > >
> vi_separate_dcc_process_and_reset_stats(ctx,
> > > > >
> > > > > tex);
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > void si_decompress_dcc(struct si_context *sctx, struct
> si_texture
> > > > > > *tex)
> > > > > > {
> > > > > > - if (!tex->dcc_offset)
> > > > > > + /* If graphics is disabled, we can't decompress DCC, but it
> > > > >
> > > > > shouldn't
> > > > > > + * be compressed either. The caller should simply discard
> it.
> > > > > > + */
> > > > > > + if (!tex->dcc_offset || !sctx->has_graphics)
> > > > > > return;
> > > > > >
> > > > > > si_blit_decompress_color(sctx, tex, 0,
> > > > >
> > > > > tex->buffer.b.b.last_level,
> > > > > >0,
> util_max_layer(&tex->buffer.b.b, 0),
> > > > > >true);
> > > > > > }
> > > > > >
> > > > > > void si_init_blit_functions(struct si_context *sctx)
> > > > > > {
> > > > > > sctx->b.resource_copy_region = si_resource_copy_region;
> > > > > > - sctx->b.blit = si_blit;
> > > > > > - sctx->b.flush_resource = si_flush_resource;
> > > > > > - sctx->b.generate_mipmap = si_generate_mipmap;
> > > > > > +
> > > > > > + if (sctx->has_graphics) {
> > > > > > + sctx->b.blit = si_blit;
> > > > > > + sctx->b.flush_resource = si_flush_resource;
> > > > > > + sctx->b.generate_mipmap = si_generate_mipmap;
> > > > > > + }
> > > > > > }
> > > > > > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> > > > > > b/src/gallium/drivers/radeonsi/si_clear.c
> > > > > > index 9a00bb73b94..e1805f2a1c9 100644
> > > > > > --- a/src/gallium/drivers/radeonsi/si_clear.c
> > > > > > +++ b/src/gallium/drivers/radeonsi/si_clear.c
> > > > > > @@ -764,15 +764,18 @@ static void si_clear_texture(struct
> pipe_context
> > > > > > *pipe,
> > > > > > util_clear_render_tar
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Tue, 2019-02-26 at 18:34 -0500, Marek Olšák wrote:
> I ran a simple test verifying that compute is working properly on the
> compute ring.
I guess this was not on raven? With his patch I no loner see gfx
timeout but the apps still hang. anyway that's a separate issue.
>
> When clover is using compute rings, it doesn't stall/block graphics
> operations.
I'd be nice to include this information in the commit message.
Jan
>
> Marek
>
> On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely wrote:
>
> > Can you add a bit of background why clover should/should not use other
> > rings?
> >
> > I planned to test this, but my raven system can't run clover since kernel
> > 4.20 release (BZ 109649), so I need to bisect that first.
> > Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> > presumably, it was tested using clover on CIK, right?
> >
> > Jan
> >
> > On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák wrote:
> >
> > > I'll just push it.
> > >
> > > Marek
> > >
> > > On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel
> > > wrote:
> > >
> > > > Hello Marek,
> > > >
> > > > this series need a rebase (if you have some time).
> > > >
> > > > Dieter
> > > >
> > > > Am 12.02.2019 19:12, schrieb Marek Olšák:
> > > > > From: Marek Olšák
> > > > >
> > > > > initialize all non-compute context functions to NULL.
> > > > >
> > > > > v2: fix SI
> > > > > ---
> > > > > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > > > > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > > > > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > > > > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > > > > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > > > > src/gallium/drivers/radeonsi/si_pipe.c| 95
> > > > > +++
> > > > > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > > > > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > > > > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > > > > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > > > > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > > > > 11 files changed, 130 insertions(+), 75 deletions(-)
> > > > >
> > > > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > index bb8d1cbd12d..f39cb5d143f 100644
> > > > > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > > > > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > > > > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > > > > pipe_context *ctx,
> > > > >
> > > > > if (separate_dcc_dirty) {
> > > > > tex->separate_dcc_dirty = false;
> > > > > vi_separate_dcc_process_and_reset_stats(ctx,
> > > >
> > > > tex);
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > void si_decompress_dcc(struct si_context *sctx, struct si_texture
> > > > > *tex)
> > > > > {
> > > > > - if (!tex->dcc_offset)
> > > > > + /* If graphics is disabled, we can't decompress DCC, but it
> > > >
> > > > shouldn't
> > > > > + * be compressed either. The caller should simply discard it.
> > > > > + */
> > > > > + if (!tex->dcc_offset || !sctx->has_graphics)
> > > > > return;
> > > > >
> > > > > si_blit_decompress_color(sctx, tex, 0,
> > > >
> > > > tex->buffer.b.b.last_level,
> > > > >0, util_max_layer(&tex->buffer.b.b, 0),
> > > > >true);
> > > > > }
> > > > >
> > > > > void si_init_blit_functions(struct si_context *sctx)
> > > > > {
> > > > > sctx->b.resource_copy_region = si_resource_copy_region;
> > > > > - sctx->b.blit = si_blit;
> > > > > - sctx->b.flush_resource = si_flush_resource;
> > > > > - sctx->b.generate_mipmap = si_generate_mipmap;
> > > > > +
> > > > > + if (sctx->has_graphics) {
> > > > > + sctx->b.blit = si_blit;
> > > > > + sctx->b.flush_resource = si_flush_resource;
> > > > > + sctx->b.generate_mipmap = si_generate_mipmap;
> > > > > + }
> > > > > }
> > > > > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> > > > > b/src/gallium/drivers/radeonsi/si_clear.c
> > > > > index 9a00bb73b94..e1805f2a1c9 100644
> > > > > --- a/src/gallium/drivers/radeonsi/si_clear.c
> > > > > +++ b/src/gallium/drivers/radeonsi/si_clear.c
> > > > > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
> > > > > *pipe,
> > > > > util_clear_render_target(pipe, sf, &color,
> > > > >box->x, box->y,
> > > > >box->width,
> > > >
> > > > box->height);
> > > > > }
> > > > > }
> > > > > pipe_surface_reference(&sf, NULL);
> > > > > }
> > > > >
> > > > > void si_init_clear_functions(struct si_context *sctx)
> > > > > {
> > > > > - sc
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
I ran a simple test verifying that compute is working properly on the
compute ring.
When clover is using compute rings, it doesn't stall/block graphics
operations.
Marek
On Tue, Feb 26, 2019 at 4:10 PM Jan Vesely wrote:
> Can you add a bit of background why clover should/should not use other
> rings?
>
> I planned to test this, but my raven system can't run clover since kernel
> 4.20 release (BZ 109649), so I need to bisect that first.
> Can this patch help address the soft lockup issue on CIK (BZ 108879)?
> presumably, it was tested using clover on CIK, right?
>
> Jan
>
> On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák wrote:
>
>> I'll just push it.
>>
>> Marek
>>
>> On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel
>> wrote:
>>
>>> Hello Marek,
>>>
>>> this series need a rebase (if you have some time).
>>>
>>> Dieter
>>>
>>> Am 12.02.2019 19:12, schrieb Marek Olšák:
>>> > From: Marek Olšák
>>> >
>>> > initialize all non-compute context functions to NULL.
>>> >
>>> > v2: fix SI
>>> > ---
>>> > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
>>> > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
>>> > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
>>> > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
>>> > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
>>> > src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
>>> > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
>>> > src/gallium/drivers/radeonsi/si_state.c | 3 +-
>>> > src/gallium/drivers/radeonsi/si_state.h | 1 +
>>> > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
>>> > src/gallium/drivers/radeonsi/si_texture.c | 3 +
>>> > 11 files changed, 130 insertions(+), 75 deletions(-)
>>> >
>>> > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
>>> > b/src/gallium/drivers/radeonsi/si_blit.c
>>> > index bb8d1cbd12d..f39cb5d143f 100644
>>> > --- a/src/gallium/drivers/radeonsi/si_blit.c
>>> > +++ b/src/gallium/drivers/radeonsi/si_blit.c
>>> > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
>>> > pipe_context *ctx,
>>> >
>>> > if (separate_dcc_dirty) {
>>> > tex->separate_dcc_dirty = false;
>>> > vi_separate_dcc_process_and_reset_stats(ctx,
>>> tex);
>>> > }
>>> > }
>>> > }
>>> >
>>> > void si_decompress_dcc(struct si_context *sctx, struct si_texture
>>> > *tex)
>>> > {
>>> > - if (!tex->dcc_offset)
>>> > + /* If graphics is disabled, we can't decompress DCC, but it
>>> shouldn't
>>> > + * be compressed either. The caller should simply discard it.
>>> > + */
>>> > + if (!tex->dcc_offset || !sctx->has_graphics)
>>> > return;
>>> >
>>> > si_blit_decompress_color(sctx, tex, 0,
>>> tex->buffer.b.b.last_level,
>>> >0, util_max_layer(&tex->buffer.b.b, 0),
>>> >true);
>>> > }
>>> >
>>> > void si_init_blit_functions(struct si_context *sctx)
>>> > {
>>> > sctx->b.resource_copy_region = si_resource_copy_region;
>>> > - sctx->b.blit = si_blit;
>>> > - sctx->b.flush_resource = si_flush_resource;
>>> > - sctx->b.generate_mipmap = si_generate_mipmap;
>>> > +
>>> > + if (sctx->has_graphics) {
>>> > + sctx->b.blit = si_blit;
>>> > + sctx->b.flush_resource = si_flush_resource;
>>> > + sctx->b.generate_mipmap = si_generate_mipmap;
>>> > + }
>>> > }
>>> > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
>>> > b/src/gallium/drivers/radeonsi/si_clear.c
>>> > index 9a00bb73b94..e1805f2a1c9 100644
>>> > --- a/src/gallium/drivers/radeonsi/si_clear.c
>>> > +++ b/src/gallium/drivers/radeonsi/si_clear.c
>>> > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
>>> > *pipe,
>>> > util_clear_render_target(pipe, sf, &color,
>>> >box->x, box->y,
>>> >box->width,
>>> box->height);
>>> > }
>>> > }
>>> > pipe_surface_reference(&sf, NULL);
>>> > }
>>> >
>>> > void si_init_clear_functions(struct si_context *sctx)
>>> > {
>>> > - sctx->b.clear = si_clear;
>>> > sctx->b.clear_render_target = si_clear_render_target;
>>> > - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>>> > sctx->b.clear_texture = si_clear_texture;
>>> > +
>>> > + if (sctx->has_graphics) {
>>> > + sctx->b.clear = si_clear;
>>> > + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>>> > + }
>>> > }
>>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>>> > b/src/gallium/drivers/radeonsi/si_compute.c
>>> > index 1a62b3e0844..87addd53976 100644
>>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>>> > @@ -880,26 +880,28 @@ static void si_launch_grid(
>>> > info->block[
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
Can you add a bit of background why clover should/should not use other
rings?
I planned to test this, but my raven system can't run clover since kernel
4.20 release (BZ 109649), so I need to bisect that first.
Can this patch help address the soft lockup issue on CIK (BZ 108879)?
presumably, it was tested using clover on CIK, right?
Jan
On Tue, Feb 26, 2019 at 3:00 PM Marek Olšák wrote:
> I'll just push it.
>
> Marek
>
> On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel
> wrote:
>
>> Hello Marek,
>>
>> this series need a rebase (if you have some time).
>>
>> Dieter
>>
>> Am 12.02.2019 19:12, schrieb Marek Olšák:
>> > From: Marek Olšák
>> >
>> > initialize all non-compute context functions to NULL.
>> >
>> > v2: fix SI
>> > ---
>> > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
>> > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
>> > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
>> > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
>> > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
>> > src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
>> > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
>> > src/gallium/drivers/radeonsi/si_state.c | 3 +-
>> > src/gallium/drivers/radeonsi/si_state.h | 1 +
>> > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
>> > src/gallium/drivers/radeonsi/si_texture.c | 3 +
>> > 11 files changed, 130 insertions(+), 75 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
>> > b/src/gallium/drivers/radeonsi/si_blit.c
>> > index bb8d1cbd12d..f39cb5d143f 100644
>> > --- a/src/gallium/drivers/radeonsi/si_blit.c
>> > +++ b/src/gallium/drivers/radeonsi/si_blit.c
>> > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
>> > pipe_context *ctx,
>> >
>> > if (separate_dcc_dirty) {
>> > tex->separate_dcc_dirty = false;
>> > vi_separate_dcc_process_and_reset_stats(ctx, tex);
>> > }
>> > }
>> > }
>> >
>> > void si_decompress_dcc(struct si_context *sctx, struct si_texture
>> > *tex)
>> > {
>> > - if (!tex->dcc_offset)
>> > + /* If graphics is disabled, we can't decompress DCC, but it
>> shouldn't
>> > + * be compressed either. The caller should simply discard it.
>> > + */
>> > + if (!tex->dcc_offset || !sctx->has_graphics)
>> > return;
>> >
>> > si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
>> >0, util_max_layer(&tex->buffer.b.b, 0),
>> >true);
>> > }
>> >
>> > void si_init_blit_functions(struct si_context *sctx)
>> > {
>> > sctx->b.resource_copy_region = si_resource_copy_region;
>> > - sctx->b.blit = si_blit;
>> > - sctx->b.flush_resource = si_flush_resource;
>> > - sctx->b.generate_mipmap = si_generate_mipmap;
>> > +
>> > + if (sctx->has_graphics) {
>> > + sctx->b.blit = si_blit;
>> > + sctx->b.flush_resource = si_flush_resource;
>> > + sctx->b.generate_mipmap = si_generate_mipmap;
>> > + }
>> > }
>> > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
>> > b/src/gallium/drivers/radeonsi/si_clear.c
>> > index 9a00bb73b94..e1805f2a1c9 100644
>> > --- a/src/gallium/drivers/radeonsi/si_clear.c
>> > +++ b/src/gallium/drivers/radeonsi/si_clear.c
>> > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
>> > *pipe,
>> > util_clear_render_target(pipe, sf, &color,
>> >box->x, box->y,
>> >box->width, box->height);
>> > }
>> > }
>> > pipe_surface_reference(&sf, NULL);
>> > }
>> >
>> > void si_init_clear_functions(struct si_context *sctx)
>> > {
>> > - sctx->b.clear = si_clear;
>> > sctx->b.clear_render_target = si_clear_render_target;
>> > - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>> > sctx->b.clear_texture = si_clear_texture;
>> > +
>> > + if (sctx->has_graphics) {
>> > + sctx->b.clear = si_clear;
>> > + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
>> > + }
>> > }
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> > b/src/gallium/drivers/radeonsi/si_compute.c
>> > index 1a62b3e0844..87addd53976 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -880,26 +880,28 @@ static void si_launch_grid(
>> > info->block[0] * info->block[1] * info->block[2] > 256;
>> >
>> > if (cs_regalloc_hang)
>> > sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
>> >SI_CONTEXT_CS_PARTIAL_FLUSH;
>> >
>> > if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
>> > program->shader.compilation_failed)
>> > return;
>> >
>> > -
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
I'll just push it.
Marek
On Mon, Feb 25, 2019 at 9:37 PM Dieter Nützel wrote:
> Hello Marek,
>
> this series need a rebase (if you have some time).
>
> Dieter
>
> Am 12.02.2019 19:12, schrieb Marek Olšák:
> > From: Marek Olšák
> >
> > initialize all non-compute context functions to NULL.
> >
> > v2: fix SI
> > ---
> > src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
> > src/gallium/drivers/radeonsi/si_clear.c | 7 +-
> > src/gallium/drivers/radeonsi/si_compute.c | 15 +--
> > src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
> > src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
> > src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
> > src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
> > src/gallium/drivers/radeonsi/si_state.c | 3 +-
> > src/gallium/drivers/radeonsi/si_state.h | 1 +
> > src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
> > src/gallium/drivers/radeonsi/si_texture.c | 3 +
> > 11 files changed, 130 insertions(+), 75 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_blit.c
> > b/src/gallium/drivers/radeonsi/si_blit.c
> > index bb8d1cbd12d..f39cb5d143f 100644
> > --- a/src/gallium/drivers/radeonsi/si_blit.c
> > +++ b/src/gallium/drivers/radeonsi/si_blit.c
> > @@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
> > pipe_context *ctx,
> >
> > if (separate_dcc_dirty) {
> > tex->separate_dcc_dirty = false;
> > vi_separate_dcc_process_and_reset_stats(ctx, tex);
> > }
> > }
> > }
> >
> > void si_decompress_dcc(struct si_context *sctx, struct si_texture
> > *tex)
> > {
> > - if (!tex->dcc_offset)
> > + /* If graphics is disabled, we can't decompress DCC, but it
> shouldn't
> > + * be compressed either. The caller should simply discard it.
> > + */
> > + if (!tex->dcc_offset || !sctx->has_graphics)
> > return;
> >
> > si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
> >0, util_max_layer(&tex->buffer.b.b, 0),
> >true);
> > }
> >
> > void si_init_blit_functions(struct si_context *sctx)
> > {
> > sctx->b.resource_copy_region = si_resource_copy_region;
> > - sctx->b.blit = si_blit;
> > - sctx->b.flush_resource = si_flush_resource;
> > - sctx->b.generate_mipmap = si_generate_mipmap;
> > +
> > + if (sctx->has_graphics) {
> > + sctx->b.blit = si_blit;
> > + sctx->b.flush_resource = si_flush_resource;
> > + sctx->b.generate_mipmap = si_generate_mipmap;
> > + }
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> > b/src/gallium/drivers/radeonsi/si_clear.c
> > index 9a00bb73b94..e1805f2a1c9 100644
> > --- a/src/gallium/drivers/radeonsi/si_clear.c
> > +++ b/src/gallium/drivers/radeonsi/si_clear.c
> > @@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
> > *pipe,
> > util_clear_render_target(pipe, sf, &color,
> >box->x, box->y,
> >box->width, box->height);
> > }
> > }
> > pipe_surface_reference(&sf, NULL);
> > }
> >
> > void si_init_clear_functions(struct si_context *sctx)
> > {
> > - sctx->b.clear = si_clear;
> > sctx->b.clear_render_target = si_clear_render_target;
> > - sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> > sctx->b.clear_texture = si_clear_texture;
> > +
> > + if (sctx->has_graphics) {
> > + sctx->b.clear = si_clear;
> > + sctx->b.clear_depth_stencil = si_clear_depth_stencil;
> > + }
> > }
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> > b/src/gallium/drivers/radeonsi/si_compute.c
> > index 1a62b3e0844..87addd53976 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -880,26 +880,28 @@ static void si_launch_grid(
> > info->block[0] * info->block[1] * info->block[2] > 256;
> >
> > if (cs_regalloc_hang)
> > sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> >SI_CONTEXT_CS_PARTIAL_FLUSH;
> >
> > if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
> > program->shader.compilation_failed)
> > return;
> >
> > - if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> > - si_update_fb_dirtiness_after_rendering(sctx);
> > - sctx->last_num_draw_calls = sctx->num_draw_calls;
> > - }
> > + if (sctx->has_graphics) {
> > + if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> > + si_update_fb_dirtiness_after_rendering(sctx);
> > + sctx->last_num_draw_calls = sctx->num_draw_calls;
> > + }
> >
> > - si_decompress_textures(
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
Hello Marek,
this series need a rebase (if you have some time).
Dieter
Am 12.02.2019 19:12, schrieb Marek Olšák:
From: Marek Olšák
initialize all non-compute context functions to NULL.
v2: fix SI
---
src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
src/gallium/drivers/radeonsi/si_clear.c | 7 +-
src/gallium/drivers/radeonsi/si_compute.c | 15 +--
src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
src/gallium/drivers/radeonsi/si_state.c | 3 +-
src/gallium/drivers/radeonsi/si_state.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
src/gallium/drivers/radeonsi/si_texture.c | 3 +
11 files changed, 130 insertions(+), 75 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index bb8d1cbd12d..f39cb5d143f 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
pipe_context *ctx,
if (separate_dcc_dirty) {
tex->separate_dcc_dirty = false;
vi_separate_dcc_process_and_reset_stats(ctx, tex);
}
}
}
void si_decompress_dcc(struct si_context *sctx, struct si_texture
*tex)
{
- if (!tex->dcc_offset)
+ /* If graphics is disabled, we can't decompress DCC, but it shouldn't
+* be compressed either. The caller should simply discard it.
+*/
+ if (!tex->dcc_offset || !sctx->has_graphics)
return;
si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
0, util_max_layer(&tex->buffer.b.b, 0),
true);
}
void si_init_blit_functions(struct si_context *sctx)
{
sctx->b.resource_copy_region = si_resource_copy_region;
- sctx->b.blit = si_blit;
- sctx->b.flush_resource = si_flush_resource;
- sctx->b.generate_mipmap = si_generate_mipmap;
+
+ if (sctx->has_graphics) {
+ sctx->b.blit = si_blit;
+ sctx->b.flush_resource = si_flush_resource;
+ sctx->b.generate_mipmap = si_generate_mipmap;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index 9a00bb73b94..e1805f2a1c9 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
*pipe,
util_clear_render_target(pipe, sf, &color,
box->x, box->y,
box->width, box->height);
}
}
pipe_surface_reference(&sf, NULL);
}
void si_init_clear_functions(struct si_context *sctx)
{
- sctx->b.clear = si_clear;
sctx->b.clear_render_target = si_clear_render_target;
- sctx->b.clear_depth_stencil = si_clear_depth_stencil;
sctx->b.clear_texture = si_clear_texture;
+
+ if (sctx->has_graphics) {
+ sctx->b.clear = si_clear;
+ sctx->b.clear_depth_stencil = si_clear_depth_stencil;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 1a62b3e0844..87addd53976 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -880,26 +880,28 @@ static void si_launch_grid(
info->block[0] * info->block[1] * info->block[2] > 256;
if (cs_regalloc_hang)
sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
SI_CONTEXT_CS_PARTIAL_FLUSH;
if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
program->shader.compilation_failed)
return;
- if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
- si_update_fb_dirtiness_after_rendering(sctx);
- sctx->last_num_draw_calls = sctx->num_draw_calls;
- }
+ if (sctx->has_graphics) {
+ if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
+ si_update_fb_dirtiness_after_rendering(sctx);
+ sctx->last_num_draw_calls = sctx->num_draw_calls;
+ }
- si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ }
/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, &program->shader.bo->b.b);
/* TODO: add the scratch buffer */
if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);
/* Indirect buffe
[Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
From: Marek Olšák
initialize all non-compute context functions to NULL.
v2: fix SI
---
src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
src/gallium/drivers/radeonsi/si_clear.c | 7 +-
src/gallium/drivers/radeonsi/si_compute.c | 15 +--
src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
src/gallium/drivers/radeonsi/si_state.c | 3 +-
src/gallium/drivers/radeonsi/si_state.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
src/gallium/drivers/radeonsi/si_texture.c | 3 +
11 files changed, 130 insertions(+), 75 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index bb8d1cbd12d..f39cb5d143f 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -1345,25 +1345,31 @@ static void si_flush_resource(struct pipe_context *ctx,
if (separate_dcc_dirty) {
tex->separate_dcc_dirty = false;
vi_separate_dcc_process_and_reset_stats(ctx, tex);
}
}
}
void si_decompress_dcc(struct si_context *sctx, struct si_texture *tex)
{
- if (!tex->dcc_offset)
+ /* If graphics is disabled, we can't decompress DCC, but it shouldn't
+* be compressed either. The caller should simply discard it.
+*/
+ if (!tex->dcc_offset || !sctx->has_graphics)
return;
si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
0, util_max_layer(&tex->buffer.b.b, 0),
true);
}
void si_init_blit_functions(struct si_context *sctx)
{
sctx->b.resource_copy_region = si_resource_copy_region;
- sctx->b.blit = si_blit;
- sctx->b.flush_resource = si_flush_resource;
- sctx->b.generate_mipmap = si_generate_mipmap;
+
+ if (sctx->has_graphics) {
+ sctx->b.blit = si_blit;
+ sctx->b.flush_resource = si_flush_resource;
+ sctx->b.generate_mipmap = si_generate_mipmap;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index 9a00bb73b94..e1805f2a1c9 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context *pipe,
util_clear_render_target(pipe, sf, &color,
box->x, box->y,
box->width, box->height);
}
}
pipe_surface_reference(&sf, NULL);
}
void si_init_clear_functions(struct si_context *sctx)
{
- sctx->b.clear = si_clear;
sctx->b.clear_render_target = si_clear_render_target;
- sctx->b.clear_depth_stencil = si_clear_depth_stencil;
sctx->b.clear_texture = si_clear_texture;
+
+ if (sctx->has_graphics) {
+ sctx->b.clear = si_clear;
+ sctx->b.clear_depth_stencil = si_clear_depth_stencil;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 1a62b3e0844..87addd53976 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -880,26 +880,28 @@ static void si_launch_grid(
info->block[0] * info->block[1] * info->block[2] > 256;
if (cs_regalloc_hang)
sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
SI_CONTEXT_CS_PARTIAL_FLUSH;
if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
program->shader.compilation_failed)
return;
- if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
- si_update_fb_dirtiness_after_rendering(sctx);
- sctx->last_num_draw_calls = sctx->num_draw_calls;
- }
+ if (sctx->has_graphics) {
+ if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
+ si_update_fb_dirtiness_after_rendering(sctx);
+ sctx->last_num_draw_calls = sctx->num_draw_calls;
+ }
- si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ }
/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, &program->shader.bo->b.b);
/* TODO: add the scratch buffer */
if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);
/* Indirect buffers use TC L2 on GFX9, but not older hw. */
if (sctx->chip_class <= VI &&
@@ -917,21 +919,22 @
