[PATCH 1/5] drm/sched:add new priority level

[Sharma, Shashank]

On 8/24/2021 2:25 PM, Christian König wrote:
> Nope that are two completely different things.
> 
> The DRM_SCHED_PRIORITY_* exposes a functionality of the software 
> scheduler. E.g. we try to serve kernel queues first and if those are 
> empty we use high priority etc....
> 
> But that functionality is completely independent from the hardware 
> priority handling. In other words you can different hardware queues with 
> priorities as well and each of them is served by a software scheduler.
> 
> In other words imagine the following setup: Two hardware queues, one 
> normal and one low latency. Each hardware queue is then feed by a 
> software scheduler with the priorities low,normal,high,kernel.
> 
> This configuration then gives you 8 different priorities to use.
> 

Thanks for the details, I was under quite a different impression, this 
explanation helps.

I guess this also means that the HW queues are completely left to be 
managed by the core driver (Like AMDGPU or I915 etc) as of now, and the 
DRM framework only provides SW schedulers ?

Does this suggest a scope of a common framework or abstraction layer for 
HW queues in DRM ? Most of the architectures/HW will atleast have a 
NORMAL and a higher priority work queue, and their drivers might be 
handling them in very similar ways.

- Shashank

> Regards,
> Christian.
> 
> Am 24.08.21 um 10:32 schrieb Sharma, Shashank:
>> Hi Christian,
>> I am a bit curious here.
>>
>> I thought it would be a good idea to add a new SW priority level, so 
>> that any other driver can also utilize this SW infrastructure.
>>
>> So it could be like, if you have a HW which matches with SW priority 
>> levels, directly map your HW queue to the SW priority level, like:
>>
>> DRM_SCHED_PRIORITY_VERY_HIGH: mapped to a queue in HW reserved for 
>> real time or very high priority tasks, which can't be missed
>>
>> DRM_SCHED_PRIORITY_HIGH : mapped to a queue of High priority tasks, 
>> for better experience, like encode/decode operations.
>>
>> DRM_SCHED_PRIORITY_NORMAL: default, mapped to a queue of tasks without 
>> a priority context specified
>>
>> DRM_SCHED_PRIORITY_MIN: queue for specifically mentioned low priority 
>> tasks
>>
>> Depending on the HW we are running on, we can map these SW queues to 
>> corresponding HW queues, isn't it ?
>>
>> Regards
>> Shashank
>>
>> On 8/24/2021 11:40 AM, Christian König wrote:
>>> I haven't followed the previous discussion, but that looks like this 
>>> change is based on a misunderstanding.
>>>
>>> Those here are the software priorities used in the scheduler, but 
>>> what you are working on are the hardware priorities.
>>>
>>> That are two completely different things which we shouldn't mix up.
>>>
>>> Regards,
>>> Christian.
>>>
>>> Am 24.08.21 um 07:55 schrieb Satyajit Sahu:
>>>> Adding a new priority level DRM_SCHED_PRIORITY_VERY_HIGH
>>>>
>>>> Signed-off-by: Satyajit Sahu <satyajit.sahu at amd.com>
>>>> ---
>>>>   include/drm/gpu_scheduler.h | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
>>>> index d18af49fd009..d0e5e234da5f 100644
>>>> --- a/include/drm/gpu_scheduler.h
>>>> +++ b/include/drm/gpu_scheduler.h
>>>> @@ -40,6 +40,7 @@ enum drm_sched_priority {
>>>>       DRM_SCHED_PRIORITY_MIN,
>>>>       DRM_SCHED_PRIORITY_NORMAL,
>>>>       DRM_SCHED_PRIORITY_HIGH,
>>>> +    DRM_SCHED_PRIORITY_VERY_HIGH,
>>>>       DRM_SCHED_PRIORITY_KERNEL,
>>>>       DRM_SCHED_PRIORITY_COUNT,
>>>
>