From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Das, Nirmoy" <nirmoy.das@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Satyajit Sahu" <satyajit.sahu@amd.com>,
amd-gfx@lists.freedesktop.org
Cc: leo.liu@amd.com, Alexander.Deucher@amd.com, shashank.sharma@amd.com
Subject: Re: [PATCH 1/5] drm/sched:add new priority level
Date: Tue, 24 Aug 2021 15:18:57 +0200 [thread overview]
Message-ID: <6223bf14-653c-12c5-d871-483d43aca98f@gmail.com> (raw)
In-Reply-To: <89f6e6e7-662d-995f-a281-7e5712fff772@amd.com>
Am 24.08.21 um 14:39 schrieb Das, Nirmoy:
>
> On 8/24/2021 2:07 PM, Christian König wrote:
>> Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
>>> Hi Christian,
>>>
>>> On 8/24/2021 8:10 AM, Christian König wrote:
>>>> I haven't followed the previous discussion, but that looks like
>>>> this change is based on a misunderstanding.
>>>
>>>
>>> In previous discussion I sort of suggested to have new DRM prio as I
>>> didn't see any other way to map priority provided by the userspace
>>> to this new 3rd hw priority.
>>>
>>> Do you think we should use other information from userspace like
>>> queue id to determine hardware priority ?
>>
>> If I'm not completely mistaken we have dropped the concept of
>> exposing multiple queues/instances completely.
>
>
> Yes, that is my understanding too.
>
>>
>> What we should probably do is to use the (cleaned up) UAPI enum for
>> init_priority and override_priority instead of the drm scheduler enums.
>
>
> I went through the drm code, now I see what you mean. So what we are
> now doing is: mapping AMDGPU_CTX_PRIORITY_* to
> DRM_SCHED_PRIORITY_* and then to hw priority which is not nice.
>
> We should rather map AMDGPU_CTX_PRIORITY_* to hw priority directly.
Exactly that's my idea, yes.
If you want feel free to put this on your TODO for a potential cleanup.
Christian.
>
>
> Regards,
>
> Nirmoy
>
>
>>
>> Regards,
>> Christian.
>>
>>>
>>>
>>> Regards,
>>>
>>> Nirmoy
>>>
>>>>
>>>> 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@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,
>>>>
>>
next prev parent reply other threads:[~2021-08-24 13:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 5:55 [PATCH 1/5] drm/sched:add new priority level Satyajit Sahu
2021-08-24 5:55 ` [PATCH 2/5] drm/amdgpu: map user set priority to drm sched priority Satyajit Sahu
2021-08-24 5:55 ` [PATCH 3/5] drm/amdgpu/vce:set vce ring priority level Satyajit Sahu
2021-08-24 6:09 ` Christian König
2021-08-24 5:55 ` [PATCH 4/5] drm/amdgpu/vcn:set vcn encode " Satyajit Sahu
2021-08-24 5:55 ` [PATCH 5/5] drm/amdgpu/vcn/vce:schedule encode job based on priorrity Satyajit Sahu
2021-08-24 6:14 ` Christian König
2021-08-24 6:10 ` [PATCH 1/5] drm/sched:add new priority level Christian König
2021-08-24 8:32 ` Sharma, Shashank
2021-08-24 8:55 ` Christian König
2021-08-24 9:45 ` Sharma, Shashank
2021-08-24 11:56 ` Christian König
2021-08-24 11:57 ` Das, Nirmoy
2021-08-24 12:07 ` Christian König
2021-08-24 12:39 ` Das, Nirmoy
2021-08-24 13:18 ` Christian König [this message]
2021-08-24 13:23 ` Das, Nirmoy
-- strict thread matches above, loose matches on Subject: below --
2021-08-24 5:52 Satyajit Sahu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6223bf14-653c-12c5-d871-483d43aca98f@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=Alexander.Deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=leo.liu@amd.com \
--cc=nirmoy.das@amd.com \
--cc=satyajit.sahu@amd.com \
--cc=shashank.sharma@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox