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

[Marek Olšák]

On Fri, Sep 26, 2014 at 3:04 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> 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.

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