On 2017-04-17 03:17 PM, Alex Deucher wrote:
On Thu, Apr 13, 2017 at 6:30 PM, Andres Rodriguez <[email protected]> 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
