On Tue, Aug 21, 2018 at 2:26 PM Andres Rodriguez <andre...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
