Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Fri, Sep 26, 2014 at 3:04 PM, Alex Deucher wrote: > On Thu, Sep 25, 2014 at 3:02 PM, Tom Stellard wrote: >> On Mon, Sep 22, 2014 at 09:48:43PM +0200, Marek Olšák wrote: >>> No, we cannot detect compute-only contexts yet. We need to add a new >>> parameter to pipe_context::context_create which says that a context is >>> compute-only. That should be OpenCL but not OpenGL. >>> >>> Also, some code paths like resource_copy_region use the graphics >>> engine for copying, which cannot be used with compute rings and must >>> be implemented with either DMA or compute-based blits. DMA isn't >>> flexible enough, so some additional work for compute-based blits might >>> be needed. We can also use the graphics ring for copying only and the >>> compute ring for compute stuff. >>> >> >> If possible, I think I would prefer continuing to use the graphic ring >> for blits and only submit compute specific packets to the compute ring. >> I'm a little concerned that adding a compute-flag to context create >> might make it harder to share code between compute and graphics, which >> I think is important. >> >> What are the downsides of using both rings at once? Will we need to add >> synchronization code for the two rings? I think the last time I >> looked into doing this, the biggest problem was that fences were >> submitted via the graphics ring even though they were meant for jobs >> on the compute ring. Is there are good solution to this? > > It would be nice to not have any dependencies on the gfx ring. That > way compute jobs can run on the compute rings without requiring the > gfx ring which should avoid any latency issues with desktop gfx jobs. In that case we have to rewrite resource_copy_region and make it use compute shaders only. The ideal time for that would be after ARB_compute_shader (from GL4.3) has been implemented. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Thu, Sep 25, 2014 at 3:02 PM, Tom Stellard wrote:
> On Mon, Sep 22, 2014 at 09:48:43PM +0200, Marek Olšák wrote:
>> No, we cannot detect compute-only contexts yet. We need to add a new
>> parameter to pipe_context::context_create which says that a context is
>> compute-only. That should be OpenCL but not OpenGL.
>>
>> Also, some code paths like resource_copy_region use the graphics
>> engine for copying, which cannot be used with compute rings and must
>> be implemented with either DMA or compute-based blits. DMA isn't
>> flexible enough, so some additional work for compute-based blits might
>> be needed. We can also use the graphics ring for copying only and the
>> compute ring for compute stuff.
>>
>
> If possible, I think I would prefer continuing to use the graphic ring
> for blits and only submit compute specific packets to the compute ring.
> I'm a little concerned that adding a compute-flag to context create
> might make it harder to share code between compute and graphics, which
> I think is important.
>
> What are the downsides of using both rings at once? Will we need to add
> synchronization code for the two rings? I think the last time I
> looked into doing this, the biggest problem was that fences were
> submitted via the graphics ring even though they were meant for jobs
> on the compute ring. Is there are good solution to this?
It would be nice to not have any dependencies on the gfx ring. That
way compute jobs can run on the compute rings without requiring the
gfx ring which should avoid any latency issues with desktop gfx jobs.
Alex
>
> -Tom
>
>> Marek
>>
>> On Mon, Sep 22, 2014 at 8:03 PM, Niels Ole Salscheider
>> wrote:
>> > On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
>> >> On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
>> >> > From: Marek Olšák
>> >>
>> >> Looks good. Tom should probably take a look as well. As a further
>> >> improvement, it would be nice to be able to use the compute rings for
>> >> compute rather than gfx, but I'm not sure how much additional effort
>> >> it would take to clean that up.
>> >
>> > This is completely untested but now that we can detect compute contexts
>> > something like the attached patches might be sufficient...
>> >
>> >> Reviewed-by: Alex Deucher
>> >>
>> >> > ---
>> >> >
>> >> > src/gallium/drivers/radeonsi/si_compute.c | 6 +-
>> >> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> >> > b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182
>> >> > 100644
>> >> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> >> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> >> > @@ -168,6 +168,7 @@ static void si_launch_grid(
>> >> >
>> >> > uint32_t pc, const void *input)
>> >> >
>> >> > {
>> >> >
>> >> > struct si_context *sctx = (struct si_context*)ctx;
>> >> >
>> >> > + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
>> >> >
>> >> > struct si_compute *program = sctx->cs_shader_state.program;
>> >> > struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
>> >> > struct r600_resource *input_buffer = program->input_buffer;
>> >> >
>> >> > @@ -184,8 +185,11 @@ static void si_launch_grid(
>> >> >
>> >> > unsigned lds_blocks;
>> >> > unsigned num_waves_for_scratch;
>> >> >
>> >> > + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
>> >> > PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x8000);
>> >> > + radeon_emit(cs, 0x8000);
>> >> > +
>> >> >
>> >> > pm4->compute_pkt = true;
>> >> >
>> >> > - si_cmd_context_control(pm4);
>> >> >
>> >> > si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
>> >> > si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
>> >> >
>> >> > --
>> >> > 1.9.1
>> >> >
>> >> > ___
>> >> > mesa-dev mailing list
>> >> > mesa-dev@lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >>
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
How about assuming for each CS that it can use the compute ring and as
soon as we submit a PM4 command that can only be executed on the
graphics ring note that this CS needs to be executed on the graphics ring?
Just an idea,
Christian.
Am 25.09.2014 um 21:02 schrieb Tom Stellard:
On Mon, Sep 22, 2014 at 09:48:43PM +0200, Marek Olšák wrote:
No, we cannot detect compute-only contexts yet. We need to add a new
parameter to pipe_context::context_create which says that a context is
compute-only. That should be OpenCL but not OpenGL.
Also, some code paths like resource_copy_region use the graphics
engine for copying, which cannot be used with compute rings and must
be implemented with either DMA or compute-based blits. DMA isn't
flexible enough, so some additional work for compute-based blits might
be needed. We can also use the graphics ring for copying only and the
compute ring for compute stuff.
If possible, I think I would prefer continuing to use the graphic ring
for blits and only submit compute specific packets to the compute ring.
I'm a little concerned that adding a compute-flag to context create
might make it harder to share code between compute and graphics, which
I think is important.
What are the downsides of using both rings at once? Will we need to add
synchronization code for the two rings? I think the last time I
looked into doing this, the biggest problem was that fences were
submitted via the graphics ring even though they were meant for jobs
on the compute ring. Is there are good solution to this?
-Tom
Marek
On Mon, Sep 22, 2014 at 8:03 PM, Niels Ole Salscheider
wrote:
On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
From: Marek Olšák
Looks good. Tom should probably take a look as well. As a further
improvement, it would be nice to be able to use the compute rings for
compute rather than gfx, but I'm not sure how much additional effort
it would take to clean that up.
This is completely untested but now that we can detect compute contexts
something like the attached patches might be sufficient...
Reviewed-by: Alex Deucher
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -168,6 +168,7 @@ static void si_launch_grid(
uint32_t pc, const void *input)
{
struct si_context *sctx = (struct si_context*)ctx;
+ struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
struct si_compute *program = sctx->cs_shader_state.program;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
struct r600_resource *input_buffer = program->input_buffer;
@@ -184,8 +185,11 @@ static void si_launch_grid(
unsigned lds_blocks;
unsigned num_waves_for_scratch;
+ radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x8000);
+ radeon_emit(cs, 0x8000);
+
pm4->compute_pkt = true;
- si_cmd_context_control(pm4);
si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Mon, Sep 22, 2014 at 09:48:43PM +0200, Marek Olšák wrote:
> No, we cannot detect compute-only contexts yet. We need to add a new
> parameter to pipe_context::context_create which says that a context is
> compute-only. That should be OpenCL but not OpenGL.
>
> Also, some code paths like resource_copy_region use the graphics
> engine for copying, which cannot be used with compute rings and must
> be implemented with either DMA or compute-based blits. DMA isn't
> flexible enough, so some additional work for compute-based blits might
> be needed. We can also use the graphics ring for copying only and the
> compute ring for compute stuff.
>
If possible, I think I would prefer continuing to use the graphic ring
for blits and only submit compute specific packets to the compute ring.
I'm a little concerned that adding a compute-flag to context create
might make it harder to share code between compute and graphics, which
I think is important.
What are the downsides of using both rings at once? Will we need to add
synchronization code for the two rings? I think the last time I
looked into doing this, the biggest problem was that fences were
submitted via the graphics ring even though they were meant for jobs
on the compute ring. Is there are good solution to this?
-Tom
> Marek
>
> On Mon, Sep 22, 2014 at 8:03 PM, Niels Ole Salscheider
> wrote:
> > On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
> >> On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
> >> > From: Marek Olšák
> >>
> >> Looks good. Tom should probably take a look as well. As a further
> >> improvement, it would be nice to be able to use the compute rings for
> >> compute rather than gfx, but I'm not sure how much additional effort
> >> it would take to clean that up.
> >
> > This is completely untested but now that we can detect compute contexts
> > something like the attached patches might be sufficient...
> >
> >> Reviewed-by: Alex Deucher
> >>
> >> > ---
> >> >
> >> > src/gallium/drivers/radeonsi/si_compute.c | 6 +-
> >> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> >> > b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182 100644
> >> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> >> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> >> > @@ -168,6 +168,7 @@ static void si_launch_grid(
> >> >
> >> > uint32_t pc, const void *input)
> >> >
> >> > {
> >> >
> >> > struct si_context *sctx = (struct si_context*)ctx;
> >> >
> >> > + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
> >> >
> >> > struct si_compute *program = sctx->cs_shader_state.program;
> >> > struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
> >> > struct r600_resource *input_buffer = program->input_buffer;
> >> >
> >> > @@ -184,8 +185,11 @@ static void si_launch_grid(
> >> >
> >> > unsigned lds_blocks;
> >> > unsigned num_waves_for_scratch;
> >> >
> >> > + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
> >> > PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x8000);
> >> > + radeon_emit(cs, 0x8000);
> >> > +
> >> >
> >> > pm4->compute_pkt = true;
> >> >
> >> > - si_cmd_context_control(pm4);
> >> >
> >> > si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
> >> > si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
> >> >
> >> > --
> >> > 1.9.1
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Sat, Sep 20, 2014 at 12:11:02PM +0200, Marek Olšák wrote:
> From: Marek Olšák
Patches 1-3 are:
Reviewed-by: Tom Stellard
>
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 4b2662d..3ad9182 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -168,6 +168,7 @@ static void si_launch_grid(
> uint32_t pc, const void *input)
> {
> struct si_context *sctx = (struct si_context*)ctx;
> + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
> struct si_compute *program = sctx->cs_shader_state.program;
> struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
> struct r600_resource *input_buffer = program->input_buffer;
> @@ -184,8 +185,11 @@ static void si_launch_grid(
> unsigned lds_blocks;
> unsigned num_waves_for_scratch;
>
> + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
> PKT3_SHADER_TYPE_S(1));
> + radeon_emit(cs, 0x8000);
> + radeon_emit(cs, 0x8000);
> +
> pm4->compute_pkt = true;
> - si_cmd_context_control(pm4);
>
> si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
> si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
No, we cannot detect compute-only contexts yet. We need to add a new
parameter to pipe_context::context_create which says that a context is
compute-only. That should be OpenCL but not OpenGL.
Also, some code paths like resource_copy_region use the graphics
engine for copying, which cannot be used with compute rings and must
be implemented with either DMA or compute-based blits. DMA isn't
flexible enough, so some additional work for compute-based blits might
be needed. We can also use the graphics ring for copying only and the
compute ring for compute stuff.
Marek
On Mon, Sep 22, 2014 at 8:03 PM, Niels Ole Salscheider
wrote:
> On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
>> On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
>> > From: Marek Olšák
>>
>> Looks good. Tom should probably take a look as well. As a further
>> improvement, it would be nice to be able to use the compute rings for
>> compute rather than gfx, but I'm not sure how much additional effort
>> it would take to clean that up.
>
> This is completely untested but now that we can detect compute contexts
> something like the attached patches might be sufficient...
>
>> Reviewed-by: Alex Deucher
>>
>> > ---
>> >
>> > src/gallium/drivers/radeonsi/si_compute.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> > b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -168,6 +168,7 @@ static void si_launch_grid(
>> >
>> > uint32_t pc, const void *input)
>> >
>> > {
>> >
>> > struct si_context *sctx = (struct si_context*)ctx;
>> >
>> > + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
>> >
>> > struct si_compute *program = sctx->cs_shader_state.program;
>> > struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
>> > struct r600_resource *input_buffer = program->input_buffer;
>> >
>> > @@ -184,8 +185,11 @@ static void si_launch_grid(
>> >
>> > unsigned lds_blocks;
>> > unsigned num_waves_for_scratch;
>> >
>> > + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
>> > PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x8000);
>> > + radeon_emit(cs, 0x8000);
>> > +
>> >
>> > pm4->compute_pkt = true;
>> >
>> > - si_cmd_context_control(pm4);
>> >
>> > si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
>> > si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
>> >
>> > --
>> > 1.9.1
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
> On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
> > From: Marek Olšák
>
> Looks good. Tom should probably take a look as well. As a further
> improvement, it would be nice to be able to use the compute rings for
> compute rather than gfx, but I'm not sure how much additional effort
> it would take to clean that up.
This is completely untested but now that we can detect compute contexts
something like the attached patches might be sufficient...
> Reviewed-by: Alex Deucher
>
> > ---
> >
> > src/gallium/drivers/radeonsi/si_compute.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> > b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -168,6 +168,7 @@ static void si_launch_grid(
> >
> > uint32_t pc, const void *input)
> >
> > {
> >
> > struct si_context *sctx = (struct si_context*)ctx;
> >
> > + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
> >
> > struct si_compute *program = sctx->cs_shader_state.program;
> > struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
> > struct r600_resource *input_buffer = program->input_buffer;
> >
> > @@ -184,8 +185,11 @@ static void si_launch_grid(
> >
> > unsigned lds_blocks;
> > unsigned num_waves_for_scratch;
> >
> > + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
> > PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x8000);
> > + radeon_emit(cs, 0x8000);
> > +
> >
> > pm4->compute_pkt = true;
> >
> > - si_cmd_context_control(pm4);
> >
> > si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
> > si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
> >
> > --
> > 1.9.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>From 9714d3ee55ee0ddb0bcf63934b552df641b866a2 Mon Sep 17 00:00:00 2001
From: Niels Ole Salscheider
Date: Mon, 22 Sep 2014 19:41:20 +0200
Subject: [PATCH 1/2] radeon: submit compute packets to the compute ring
They have been submitted to the gfx ring since
764502b481e2288cb5e751de739253fdee886e3e.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeon/r600_pipe_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c b/src/gallium/drivers/radeon/r600_pipe_common.c
index ae203b6..0d9ce17 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -174,6 +174,9 @@ static void r600_flush_from_st(struct pipe_context *ctx,
if (flags & PIPE_FLUSH_END_OF_FRAME)
rflags |= RADEON_FLUSH_END_OF_FRAME;
+ if (rctx->flags & R600_CONTEXT_FLAG_COMPUTE)
+ rflags |= RADEON_FLUSH_COMPUTE;
+
if (rctx->rings.dma.cs) {
rctx->rings.dma.flush(rctx, rflags, NULL);
}
--
2.1.0
>From e578f9c067de68e9401f798a78c1ed785ceb1137 Mon Sep 17 00:00:00 2001
From: Niels Ole Salscheider
Date: Mon, 22 Sep 2014 19:57:52 +0200
Subject: [PATCH 2/2] r600: set R600_CONTEXT_FLAG_COMPUTE in compute_emit_cs
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/r600/evergreen_compute.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c b/src/gallium/drivers/r600/evergreen_compute.c
index 38b78c7..03118e1 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -420,7 +420,9 @@ static void compute_emit_cs(struct r600_context *ctx, const uint *block_layout,
*/
r600_emit_command_buffer(cs, &ctx->start_compute_cs_cmd);
- ctx->b.flags |= R600_CONTEXT_WAIT_3D_IDLE | R600_CONTEXT_FLUSH_AND_INV;
+ ctx->b.flags |= R600_CONTEXT_WAIT_3D_IDLE |
+ R600_CONTEXT_FLUSH_AND_INV |
+ R600_CONTEXT_FLAG_COMPUTE;
r600_flush_emit(ctx);
/* Emit colorbuffers. */
@@ -485,7 +487,8 @@ static void compute_emit_cs(struct r600_context *ctx, const uint *block_layout,
*/
ctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE |
R600_CONTEXT_INV_VERTEX_CACHE |
- R600_CONTEXT_INV_TEX_CACHE;
+ R600_CONTEXT_INV_TEX_CACHE |
+ R600_CONTEXT_FLAG_COMPUTE;
r600_flush_emit(ctx);
ctx->b.flags = 0;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák wrote:
> From: Marek Olšák
>
Looks good. Tom should probably take a look as well. As a further
improvement, it would be nice to be able to use the compute rings for
compute rather than gfx, but I'm not sure how much additional effort
it would take to clean that up.
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 4b2662d..3ad9182 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -168,6 +168,7 @@ static void si_launch_grid(
> uint32_t pc, const void *input)
> {
> struct si_context *sctx = (struct si_context*)ctx;
> + struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
> struct si_compute *program = sctx->cs_shader_state.program;
> struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
> struct r600_resource *input_buffer = program->input_buffer;
> @@ -184,8 +185,11 @@ static void si_launch_grid(
> unsigned lds_blocks;
> unsigned num_waves_for_scratch;
>
> + radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
> PKT3_SHADER_TYPE_S(1));
> + radeon_emit(cs, 0x8000);
> + radeon_emit(cs, 0x8000);
> +
> pm4->compute_pkt = true;
> - si_cmd_context_control(pm4);
>
> si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
> si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
The series looks good to me, but Tom should probably take a look as well. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 4b2662d..3ad9182 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -168,6 +168,7 @@ static void si_launch_grid(
uint32_t pc, const void *input)
{
struct si_context *sctx = (struct si_context*)ctx;
+ struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
struct si_compute *program = sctx->cs_shader_state.program;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
struct r600_resource *input_buffer = program->input_buffer;
@@ -184,8 +185,11 @@ static void si_launch_grid(
unsigned lds_blocks;
unsigned num_waves_for_scratch;
+ radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
PKT3_SHADER_TYPE_S(1));
+ radeon_emit(cs, 0x8000);
+ radeon_emit(cs, 0x8000);
+
pm4->compute_pkt = true;
- si_cmd_context_control(pm4);
si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
