[Mesa-dev] [PATCH 1/4] radeonsi/compute: directly emit CONTEXT_CONTROL

[Alex Deucher]

On Thu, Sep 25, 2014 at 3:02 PM, Tom Stellard <tom at stellard.net> 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
>> <niels_ole at salscheider-online.de> wrote:
>> > On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
>> >> On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> >> > From: Marek Olšák <marek.olsak at amd.com>
>> >>
>> >> 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 <alexander.deucher at amd.com>
>> >>
>> >> > ---
>> >> >
>> >> >  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, 0x80000000);
>> >> > +       radeon_emit(cs, 0x80000000);
>> >> > +
>> >> >
>> >> >         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 at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >>
>> >> _______________________________________________
>> >> mesa-dev mailing list
>> >> mesa-dev at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev