AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Shashank Sharma <shashank.sharma@amd.com>
To: "Felix Kuehling" <felix.kuehling@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Yadav, Arvind" <arvyadav@amd.com>,
	"Alex Deucher" <alexdeucher@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	amd-gfx@lists.freedesktop.org, arvind.yadav@amd.com,
	arunpravin.paneerselvam@amd.com
Subject: Re: [RFC 3/7] drm/amdgpu: Create MQD for userspace queue
Date: Wed, 4 Jan 2023 15:41:30 +0100	[thread overview]
Message-ID: <38e4d463-9595-02f4-d79f-bb165e2eaa38@amd.com> (raw)
In-Reply-To: <b4a601d4-4d08-fea7-5eaa-772194fd6b1a@amd.com>


On 04/01/2023 15:35, Felix Kuehling wrote:
> Am 2023-01-04 um 04:23 schrieb Shashank Sharma:
>>
>> On 04/01/2023 10:17, Christian König wrote:
>>> Am 04.01.23 um 10:13 schrieb Shashank Sharma:
>>>>
>>>> On 04/01/2023 10:10, Christian König wrote:
>>>>> Am 04.01.23 um 07:21 schrieb Yadav, Arvind:
>>>>>>
>>>>>> On 1/4/2023 12:07 AM, Felix Kuehling wrote:
>>>>>>> Am 2023-01-03 um 04:36 schrieb Shashank Sharma:
>>>>>>>>>> /*MQD struct for usermode Queue*/
>>>>>>>>>> +struct amdgpu_usermode_queue_mqd
>>>>>>>>> This is specific to GC 11.  Every IP and version will have its 
>>>>>>>>> own MQD
>>>>>>>>> format.  That should live in the IP specific code, not the 
>>>>>>>>> generic
>>>>>>>>> code.  We already have the generic MQD parameters that we need 
>>>>>>>>> from
>>>>>>>>> the userq IOCTL.
>>>>>>>>
>>>>>>>> Noted, we can separate out the generic parameters from gen 
>>>>>>>> specific parameter, and will try to wrap it around the generic 
>>>>>>>> structure.
>>>>>>>>
>>>>>>>> - Shashank
>>>>>>>
>>>>>>> Is there a reason why you can't use "struct v11_compute_mqd" 
>>>>>>> from v11_structs.h?
>>>>>>
>>>>>> Hi Felix,
>>>>>>
>>>>>> Yes,  V11_compute_mqd does not have these below member which is 
>>>>>> needed for usermode queue.
>>>>>>
>>>>>>     uint32_t shadow_base_lo; // offset: 0  (0x0)
>>>>>>     uint32_t shadow_base_hi; // offset: 1  (0x1)
>>>>>>     uint32_t gds_bkup_base_lo ; // offset: 2  (0x2)
>>>>>>     uint32_t gds_bkup_base_hi ; // offset: 3  (0x3)
>>>>>>     uint32_t fw_work_area_base_lo; // offset: 4  (0x4)
>>>>>>     uint32_t fw_work_area_base_hi; // offset: 5  (0x5)
>>>>>>     uint32_t shadow_initialized; // offset: 6  (0x6)
>>>>>>     uint32_t ib_vmid; // offset: 7  (0x7)
>>>>>>
>>>>>> So we had to add new MQD structs.
>>>>>
>>>>> Would it make more sense to update the existing MQD structures 
>>>>> than adding new ones?
>>>>>
>>>> Imo, It might be a bit complicated in the bring-up state, but we 
>>>> can take a note of converting this structure into a union of two, 
>>>> or may be renaming it into a superset structure.
>>>
>>> Union? Does that mean we have stuff which is individual for both 
>>> versions of the struct?
>> So far it seems like Gfx MQD structure is a superset of two, but we 
>> have not compared them neck-to-neck yet, hence I feel like we can 
>> defer this task for sometime (but add into to-do list).
>
> v11_gfx_mqd has these fields reserved. Updating the definition with 
> the fields you need should not be a problem. v11_gfx_mqd is already 
> used in gfx_v11_0.c.
>
> The firmware shouldn't care much whether a queue is a kernel mode 
> queue or a user mode queue. The MQD layout should be the same. So 
> having two different structure definitions in two different places 
> doesn't make sense. I don't think it's wise to leave this for cleanup 
> later. That would only cause churn and ultimately more work than doing 
> the right thing in the first place.
>
> Regards,
>   Felix
>
Hey Felix, noted, we will try to reuse this same structure.

- Shashank

>
>
>>>
>>> BTW: Could we drop the "// offset:" stuff? This could cause problems 
>>> with automated checkers.
>>
>> Sure, we will do it.
>>
>> - Shashank
>>
>>>
>>> Christian.
>>>
>>>>
>>>> - Shashank
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> ~arvind
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>   Felix
>>>>>>>
>>>>>
>>>

  parent reply	other threads:[~2023-01-04 14:41 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-23 19:36 [RFC 0/7] RFC: Usermode queue for AMDGPU driver Shashank Sharma
2022-12-23 19:36 ` [RFC 1/7] drm/amdgpu: UAPI for user queue management Shashank Sharma
2022-12-24 20:20   ` Bas Nieuwenhuizen
2022-12-27 16:58     ` Alex Deucher
2023-01-02 11:27       ` Christian König
2023-01-03 19:51         ` Alex Deucher
2023-01-02 13:26   ` Christian König
2023-01-03 14:23     ` Alex Deucher
2023-01-03 18:29   ` Felix Kuehling
2023-01-03 19:17     ` Liu, Shaoyun
2023-01-03 19:22       ` Alex Deucher
2023-01-03 19:25         ` Liu, Shaoyun
2023-01-03 19:52           ` Alex Deucher
2023-01-03 20:05             ` Felix Kuehling
2023-01-03 19:18     ` Alex Deucher
2022-12-23 19:36 ` [RFC 2/7] drm/amdgpu: Add usermode queue for gfx work Shashank Sharma
2022-12-24 18:19   ` Oded Gabbay
2022-12-26 10:34     ` Shashank Sharma
2022-12-25 15:44   ` Christian König
2022-12-26 10:41     ` Shashank Sharma
2023-01-02 12:39       ` Christian König
2023-01-03  9:12         ` Shashank Sharma
2023-01-03  9:15           ` Christian König
2023-01-03  9:22             ` Shashank Sharma
2023-01-03  9:35               ` Christian König
2023-01-03 14:34                 ` Alex Deucher
2023-01-03 14:50                   ` Christian König
2022-12-29 17:41   ` Alex Deucher
2023-01-02 13:53     ` Christian König
2023-01-03  9:32       ` Shashank Sharma
2023-01-03  9:16     ` Shashank Sharma
2023-01-04  8:55   ` Zhu, Jiadong
2023-01-04  8:58     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 3/7] drm/amdgpu: Create MQD for userspace queue Shashank Sharma
2022-12-29 17:47   ` Alex Deucher
2023-01-03  9:36     ` Shashank Sharma
2023-01-03 18:37       ` Felix Kuehling
2023-01-04  6:21         ` Yadav, Arvind
2023-01-04  9:10           ` Christian König
2023-01-04  9:13             ` Shashank Sharma
2023-01-04  9:17               ` Christian König
2023-01-04  9:23                 ` Shashank Sharma
2023-01-04 14:35                   ` Felix Kuehling
2023-01-04 14:38                     ` Yadav, Arvind
2023-01-04 14:41                     ` Shashank Sharma [this message]
2023-01-04 14:28           ` Alex Deucher
2022-12-23 19:36 ` [RFC 4/7] drm/amdgpu: Allocate doorbell slot for user queue Shashank Sharma
2022-12-29 17:50   ` Alex Deucher
2023-01-03  9:37     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 5/7] drm/amdgpu: Create context for usermode queue Shashank Sharma
2022-12-29 17:54   ` Alex Deucher
2023-01-03  9:40     ` Shashank Sharma
2023-01-03 14:48       ` Alex Deucher
2022-12-23 19:36 ` [RFC 6/7] drm/amdgpu: Map userqueue into HW Shashank Sharma
2022-12-29 17:51   ` Alex Deucher
2023-01-03  9:38     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 7/7] drm/amdgpu: Secure semaphore for usermode queue Shashank Sharma
2022-12-25 10:07   ` Zhang, Yifan
2022-12-27  9:32     ` Arunpravin Paneer Selvam
2022-12-29 18:02 ` [RFC 0/7] RFC: Usermode queue for AMDGPU driver Alex Deucher
2023-01-03  9:43   ` Shashank Sharma
2023-01-03  9:47     ` Christian König
2023-01-03 10:00       ` Shashank Sharma
2023-01-03 10:02         ` Christian König

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=38e4d463-9595-02f4-d79f-bb165e2eaa38@amd.com \
    --to=shashank.sharma@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=arvind.yadav@amd.com \
    --cc=arvyadav@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=felix.kuehling@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