[PATCH split 3/3] Add support for high priority scheduling in amdgpu v9

[Andres Rodriguez]

On 2017-04-17 03:17 PM, Alex Deucher wrote:
> On Thu, Apr 13, 2017 at 6:30 PM, Andres Rodriguez <andresx7 at gmail.com> wrote:
>> Third part of the split of the series:
>> Add support for high priority scheduling in amdgpu v8
>>
>> This is the part of the series that is in a bit more murky water than the rest.
>>
>> Sending out this patch series mostly for completion. And maybe for discussion
>> purposes as well. There are still 2 issues open with this series:
>>
>>   1) Is the spinlock patch still okay? Should we pursue this differently?
>>
>> I'd rather not use a mutex here. That would mean that to program srbm registers
>> from an interrupt we'd need to dispatch a worker thread. That could mean extra
>> time that the CU reservation is in place which can impact performance.
>>
>> So my preferred (biased) alternative is to still move to a spinlock.
>>
>> Another alternative I'm not sure of: Can we take advantage of the KIQ FIFO
>> semantics to perform srbm writes atomically?
>>
>> Something like:
>>    ib_append(ib, PKT_WRITE_REG(SRBM_SELECT(...)))
>>    ib_append(ib, PKT_WRITE_REG(SOME_REG, VAL)
>>    ib_append(ib, PKT_WRITE_REG(SRBM_SELECT(0, 0, 0)))
>>    ib_sumbit(kiq_ring, ib)
>>
>> Something that makes this immediately feel wrong though is the possibility of a
>> race condition between an srbm operation on the KIQ and one through MMIO.
>
> GFX has its own interface to srbm so it should never conflict with
> MMIO for access to things like indexed registers.

Silly question. I'm assuming GFX here includes compute queues (i.e. your 
sentence referred to the GFX HW block which includes the KIQ). Correct?

Would I have to worry about submitting writes on two different pipes 
simultaneously? I think that working on the assumption that register 
programming would only happen on the KIQ should be enought

>
> Another possibility would be to switch from using static queues to
> using runlists (similar to what KFD does, but still kernel based).
> Then everything could be packet driven.  If you need to change the
> priority on a queue, you'd just adjust the value in the mqd before
> scheduling the runlist on the KIQ.  I think there is even a special
> packet for setting the CU reservation.

I took a quick look last time through the docs and couldn't find 
anything. Also a quick grep through the register headers and I didn't 
stumble into anything. If you do find it I would be interested.

>
> Alex
>
>>
>>   2) Alex suggested changing some MMIO writes to happen on the KIQ instead. I
>> still haven't addressed that.
>>
>> I'm not sure the full criteria for patches landing on -wip. But if these are good enough
>> to fix with some followup work, I wouldn't be oppossed to that idea.
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx