From: "Christian König" <christian.koenig@amd.com>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Somalapuram, Amaranath" <Amaranath.Somalapuram@amd.com>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"Sharma, Shashank" <Shashank.Sharma@amd.com>
Subject: Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl
Date: Wed, 22 Mar 2023 15:29:21 +0100 [thread overview]
Message-ID: <ea9ce74c-664c-47de-c750-bd4f3893ac72@amd.com> (raw)
In-Reply-To: <CAAxE2A60VNbjKS3LpKjX=Y9gPD92gw4hBJpQApmcQKCu0UM4UQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7013 bytes --]
Well that sounds like being able to optionally set it after context
creation is actually the right approach.
VA-API could set it as soon as we know that this is a video codec
application.
Vulkan can set it depending on what features are used by the application.
But yes, Shashank (or whoever requested that) should come up with some
code for Mesa to actually use it. Otherwise we don't have the
justification to push it into the kernel driver.
Christian.
Am 22.03.23 um 15:24 schrieb Marek Olšák:
> The hint is static per API (one of graphics, video, compute, unknown).
> In the case of Vulkan, which exposes all queues, the hint is unknown,
> so Vulkan won't use it. (or make it based on the queue being used and
> not the uapi context state) GL won't use it because the default hint
> is already 3D. That makes VAAPI the only user that only sets the hint
> once, and maybe it's not worth even adding this uapi just for VAAPI.
>
> Marek
>
> On Wed, Mar 22, 2023 at 10:08 AM Christian König
> <christian.koenig@amd.com> wrote:
>
> Well completely agree that we shouldn't have unused API. That's
> why I said we should remove the getting the hint from the UAPI.
>
> But what's wrong with setting it after creating the context? Don't
> you know enough about the use case? I need to understand the
> background a bit better here.
>
> Christian.
>
> Am 22.03.23 um 15:05 schrieb Marek Olšák:
>> The option to change the hint after context creation and get the
>> hint would be unused uapi, and AFAIK we are not supposed to add
>> unused uapi. What I asked is to change it to a uapi that
>> userspace will actually use.
>>
>> Marek
>>
>> On Tue, Mar 21, 2023 at 9:54 AM Christian König
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>> Yes, I would like to avoid having multiple code paths for
>> context creation.
>>
>> Setting it later on should be equally to specifying it on
>> creation since we only need it during CS.
>>
>> Regards,
>> Christian.
>>
>> Am 21.03.23 um 14:00 schrieb Sharma, Shashank:
>>>
>>> [AMD Official Use Only - General]
>>>
>>> When we started this patch series, the workload hint was a
>>> part of the ctx_flag only,
>>>
>>> But we changed that after the design review, to make it more
>>> like how we are handling PSTATE.
>>>
>>> Details:
>>>
>>> https://patchwork.freedesktop.org/patch/496111/
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>> *From:*Marek Olšák <maraeo@gmail.com> <mailto:maraeo@gmail.com>
>>> *Sent:* 21 March 2023 04:05
>>> *To:* Sharma, Shashank <Shashank.Sharma@amd.com>
>>> <mailto:Shashank.Sharma@amd.com>
>>> *Cc:* amd-gfx@lists.freedesktop.org; Deucher, Alexander
>>> <Alexander.Deucher@amd.com>
>>> <mailto:Alexander.Deucher@amd.com>; Somalapuram, Amaranath
>>> <Amaranath.Somalapuram@amd.com>
>>> <mailto:Amaranath.Somalapuram@amd.com>; Koenig, Christian
>>> <Christian.Koenig@amd.com> <mailto:Christian.Koenig@amd.com>
>>> *Subject:* Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for
>>> workload hints to ctx ioctl
>>>
>>> I think we should do it differently because this interface
>>> will be mostly unused by open source userspace in its
>>> current form.
>>>
>>> Let's set the workload hint in drm_amdgpu_ctx_in::flags, and
>>> that will be immutable for the lifetime of the context. No
>>> other interface is needed.
>>>
>>> Marek
>>>
>>> On Mon, Sep 26, 2022 at 5:41 PM Shashank Sharma
>>> <shashank.sharma@amd.com> wrote:
>>>
>>> Allow the user to specify a workload hint to the kernel.
>>> We can use these to tweak the dpm heuristics to better match
>>> the workload for improved performance.
>>>
>>> V3: Create only set() workload UAPI (Christian)
>>>
>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com>
>>> ---
>>> include/uapi/drm/amdgpu_drm.h | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/amdgpu_drm.h
>>> b/include/uapi/drm/amdgpu_drm.h
>>> index c2c9c674a223..23d354242699 100644
>>> --- a/include/uapi/drm/amdgpu_drm.h
>>> +++ b/include/uapi/drm/amdgpu_drm.h
>>> @@ -212,6 +212,7 @@ union drm_amdgpu_bo_list {
>>> #define AMDGPU_CTX_OP_QUERY_STATE2 4
>>> #define AMDGPU_CTX_OP_GET_STABLE_PSTATE 5
>>> #define AMDGPU_CTX_OP_SET_STABLE_PSTATE 6
>>> +#define AMDGPU_CTX_OP_SET_WORKLOAD_PROFILE 7
>>>
>>> /* GPU reset status */
>>> #define AMDGPU_CTX_NO_RESET 0
>>> @@ -252,6 +253,17 @@ union drm_amdgpu_bo_list {
>>> #define AMDGPU_CTX_STABLE_PSTATE_MIN_MCLK 3
>>> #define AMDGPU_CTX_STABLE_PSTATE_PEAK 4
>>>
>>> +/* GPU workload hints, flag bits 8-15 */
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_SHIFT 8
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_MASK (0xff <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_NONE (0 <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_3D (1 <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_VIDEO (2 <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_VR (3 <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_COMPUTE (4 <<
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +#define AMDGPU_CTX_WORKLOAD_HINT_MAX
>>> AMDGPU_CTX_WORKLOAD_HINT_COMPUTE
>>> +#define AMDGPU_CTX_WORKLOAD_INDEX(n) (n >>
>>> AMDGPU_CTX_WORKLOAD_HINT_SHIFT)
>>> +
>>> struct drm_amdgpu_ctx_in {
>>> /** AMDGPU_CTX_OP_* */
>>> __u32 op;
>>> @@ -281,6 +293,11 @@ union drm_amdgpu_ctx_out {
>>> __u32 flags;
>>> __u32 _pad;
>>> } pstate;
>>> +
>>> + struct {
>>> + __u32 flags;
>>> + __u32 _pad;
>>> + } workload;
>>> };
>>>
>>> union drm_amdgpu_ctx {
>>> --
>>> 2.34.1
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 16354 bytes --]
next prev parent reply other threads:[~2023-03-22 14:29 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 21:40 [PATCH v3 0/5] GPU workload hints for better performance Shashank Sharma
2022-09-26 21:40 ` [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl Shashank Sharma
2022-09-27 6:07 ` Christian König
2022-09-27 14:28 ` Felix Kuehling
2023-03-21 3:05 ` Marek Olšák
2023-03-21 13:00 ` Sharma, Shashank
2023-03-21 13:54 ` Christian König
2023-03-22 14:05 ` Marek Olšák
2023-03-22 14:08 ` Christian König
2023-03-22 14:24 ` Marek Olšák
2023-03-22 14:29 ` Christian König [this message]
2023-03-22 14:36 ` Marek Olšák
2023-03-22 14:52 ` Alex Deucher
2023-03-22 15:11 ` Marek Olšák
2023-03-22 14:38 ` Sharma, Shashank
2022-09-26 21:40 ` [PATCH v3 2/5] drm/amdgpu: add new functions to set GPU power profile Shashank Sharma
2022-09-27 2:14 ` Quan, Evan
2022-09-27 7:29 ` Sharma, Shashank
2022-09-27 9:29 ` Quan, Evan
2022-09-27 10:00 ` Sharma, Shashank
2022-09-27 6:08 ` Christian König
2022-09-27 9:58 ` Lazar, Lijo
2022-09-27 11:41 ` Sharma, Shashank
2022-09-27 12:10 ` Lazar, Lijo
2022-09-27 12:23 ` Sharma, Shashank
2022-09-27 12:39 ` Lazar, Lijo
2022-09-27 12:53 ` Sharma, Shashank
2022-09-27 13:29 ` Lazar, Lijo
2022-09-27 13:47 ` Sharma, Shashank
2022-09-27 14:00 ` Lazar, Lijo
2022-09-27 14:20 ` Sharma, Shashank
2022-09-27 14:34 ` Lazar, Lijo
2022-09-27 14:50 ` Sharma, Shashank
2022-09-27 15:20 ` Felix Kuehling
2022-09-26 21:40 ` [PATCH v3 3/5] drm/amdgpu: set GPU workload via ctx IOCTL Shashank Sharma
2022-09-27 6:09 ` Christian König
2022-09-26 21:40 ` [PATCH v3 4/5] drm/amdgpu: switch GPU workload profile Shashank Sharma
2022-09-27 6:11 ` Christian König
2022-09-27 10:03 ` Lazar, Lijo
2022-09-27 11:47 ` Sharma, Shashank
2022-09-27 12:20 ` Lazar, Lijo
2022-09-27 12:25 ` Sharma, Shashank
2022-09-27 16:33 ` Michel Dänzer
2022-09-27 17:06 ` Sharma, Shashank
2022-09-27 17:29 ` Michel Dänzer
2022-09-26 21:40 ` [PATCH v3 5/5] drm/amdgpu: switch workload context to/from compute Shashank Sharma
2022-09-27 6:12 ` Christian König
2022-09-27 14:48 ` Felix Kuehling
2022-09-27 14:58 ` Sharma, Shashank
2022-09-27 15:23 ` Felix Kuehling
2022-09-27 15:38 ` Sharma, Shashank
2022-09-27 20:40 ` Alex Deucher
2022-09-28 7:05 ` Lazar, Lijo
2022-09-28 8:56 ` Sharma, Shashank
2022-09-28 9:00 ` Sharma, Shashank
2022-09-28 21:51 ` Alex Deucher
2022-09-29 8:48 ` Sharma, Shashank
2022-09-29 11:10 ` Lazar, Lijo
2022-09-29 13:20 ` Sharma, Shashank
2022-09-29 13:37 ` Lazar, Lijo
2022-09-29 14:00 ` Sharma, Shashank
2022-09-29 14:14 ` Lazar, Lijo
2022-09-29 14:40 ` Sharma, Shashank
2022-09-29 18:32 ` Alex Deucher
2022-09-30 5:08 ` Lazar, Lijo
2022-09-30 8:37 ` Sharma, Shashank
2022-09-30 9:13 ` Lazar, Lijo
2022-09-30 9:22 ` Sharma, Shashank
2022-09-30 9:54 ` Lazar, Lijo
2022-09-30 10:09 ` Sharma, Shashank
2022-09-29 18:07 ` Felix Kuehling
2022-09-30 4:46 ` Lazar, Lijo
2022-09-27 16:24 ` [PATCH v3 0/5] GPU workload hints for better performance Michel Dänzer
2022-09-27 16:59 ` Sharma, Shashank
2022-09-27 17:13 ` Michel Dänzer
2022-09-27 17:25 ` Sharma, Shashank
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=ea9ce74c-664c-47de-c750-bd4f3893ac72@amd.com \
--to=christian.koenig@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Amaranath.Somalapuram@amd.com \
--cc=Shashank.Sharma@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=maraeo@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.