[Mesa-dev] [PATCH] radv: drop wrong initialization of COMPUTE_RESOURCE_LIMITS

[Marek Olšák]

On Tue, Aug 21, 2018 at 2:26 PM Andres Rodriguez <andresx7 at gmail.com> wrote:
>
>
>
> On 2018-08-21 01:54 PM, Marek Olšák wrote:
> > Note that WAVES_PER_SH should be 0x3ff on the compute ring for the
> > ring priorities to be applied.
>
> Correct, we would need to set WAVES_PER_SH during pipeline creation.
>
> > I don't know if you need to do the same
> > thing for the gfx ring. You can ask Andres for more info.
>
> The gfx side seems to be okay, I only borked the compute side it seems.
>
> This was probably working during tests since we have two mechanism to
> control scheduling priority at the hardware level. One is based on
> CP_HQD_*_PRIORITY and SPI_ARB_PRIORITY.PIPE_ORDER*.
>
> This approach has the advantage of not requiring driver opt-in, and it
> dynamically adjusts the resource split between different queues.
> However, it does not offer low latency when high priority compute
> initially pre-empts a gfx worload.
>
> The second approach uses SPI_SHADER_PGM_RSRC3_* and WAVES_PER_SH to
> indicate driver opt-in. Then when the kernel scheduler detects that we
> have some high priority work, it will create a static resource split
> between all clients using SPI_WCL_PIPE_PERCENT_*. Drivers that did not
> opt in will not be force to abide to the resource split by the hardware.
>
> This approach has the disadvantage of possibly leaving some resources
> idle since we have a static split. However, it does provide good latency
> for a high priority compute job pre-empting a heavy graphics workload.
>
> So even though we didn't opt-in for compute resource splits, we still
> had the first approach to fall back on.
>
> This sort of raises the question, should compute drivers really opt-in
> to static resource splits? Since we have the first approach that does a
> better job at managing compute/compute scheduling priorities, do we want
> to bring in the disadvantages of approach #2?

We can make approach 2 optional if needed, not mandatory. I like
approach 1 more. In Mesa, we may want a normal-priority gfx with
low-priority compute, but at the same time, we want compute to use
unoccupied CUs if possible.

Marek