Hey Michel,
Sounds fair. I don't think we are in a rush to get this merged until it
actually can provide the guarantees that we need.
I've gotten some good feedback on code change improvements, and that
should be enough to get me to the next stage with HW support.
I'll send and updated patchset when I get new data on that.
Regards,
Andres
On 2017-01-05 02:15 AM, Michel Dänzer wrote:
On 05/01/17 05:51 AM, Andres Rodriguez wrote:
On 2017-01-04 06:54 AM, Mao, David wrote:
Hi Andres,
I did not follow the previous discussion, so please remind me if my
questions have been covered already~
- The priority should be the queue properties, and do we really want
to expose high priority on none-compute queue?
I exposing the concept across all queues is good for consistency. It
will probably end up staying as a SW-scheduler feature for all queues
except for compute.
However, if we do end up getting some HW features that enable priority
support on other engines, then the API will be ready, and we'll only
need a kernel side change to enable the support.
- Another question is we may need to do per submission priority tweak
if we don't reserve one compute queue ahead of time.
From the patch, it seems you only tweak the GPU scheduler's priority,
but I think it is still insufficient given we don't have OS preemption
supported,
Correct, the current patch is just to get an environment in place to
start doing measurements. With this framework in place we can start
adding HW support to increase the priorities.
Dynamic tweaking might be necessary depending on how CU reservation is
going to work.
It sounds like it's still too early to tell if this simple priority
mechanism will end up being useful. It's probably better to hold off on
merging this upstream until you have at least a proof of concept showing
that it's actually useful in practice.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
