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. > >
