From: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
To: "Zeng, Oak" <Oak.Zeng-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Keely, Sean" <Sean.Keely-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 7/8] drm/amdkfd: New IOCTL to allocate queue GWS
Date: Fri, 10 May 2019 20:28:18 +0000 [thread overview]
Message-ID: <c76522c2-115e-a6b6-f136-44fa2a45be2b@amd.com> (raw)
In-Reply-To: <1557504063-1559-7-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
On 2019-05-10 12:01 p.m., Zeng, Oak wrote:
> Add a new kfd ioctl to allocate queue GWS. Queue
> GWS is released on queue destroy.
>
> Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
> Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 45 ++++++++++++++++++++++++++++++++
> include/uapi/linux/kfd_ioctl.h | 19 +++++++++++++-
> 2 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 38ae53f..17dd970 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -338,6 +338,11 @@ static int kfd_ioctl_destroy_queue(struct file *filp, struct kfd_process *p,
>
> mutex_lock(&p->mutex);
>
> + if (pqm_get_gws(&p->pqm, args->queue_id)) {
> + amdgpu_amdkfd_remove_gws_from_process(p->kgd_process_info,
> + pqm_get_gws(&p->pqm, args->queue_id));
> + pqm_set_gws(&p->pqm, args->queue_id, NULL);
> + }
It would be more robust if this was done inside pqm_destroy_queue. That
way you'd handle other potential code paths that destroy queues (not
sure there are any) and you wouldn't need pqm_get_gws exported from PQM.
> retval = pqm_destroy_queue(&p->pqm, args->queue_id);
>
> mutex_unlock(&p->mutex);
> @@ -1559,6 +1564,44 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file *filep,
> return err;
> }
>
> +static int kfd_ioctl_alloc_queue_gws(struct file *filep,
> + struct kfd_process *p, void *data)
> +{
> + int retval;
> + struct kfd_ioctl_alloc_queue_gws_args *args = data;
> + struct kfd_dev *dev = NULL;
> + struct kgd_mem *mem;
> +
> + if (args->num_gws == 0)
> + return -EINVAL;
> +
> + if (!hws_gws_support ||
> + dev->dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS)
> + return -EINVAL;
> +
> + dev = kfd_device_by_id(args->gpu_id);
> + if (!dev) {
> + pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
> + return -EINVAL;
> + }
> +
> + retval = amdgpu_amdkfd_add_gws_to_process(p->kgd_process_info,
> + dev->gws, &mem);
> + if (unlikely(retval))
> + return retval;
> +
> + mutex_lock(&p->mutex);
> + retval = pqm_set_gws(&p->pqm, args->queue_id, mem);
> + mutex_unlock(&p->mutex);
> +
> + if (unlikely(retval))
> + amdgpu_amdkfd_remove_gws_from_process(p->kgd_process_info, mem);
> +
> + /* The gws_array parameter is reserved for future extension*/
> + args->gws_array[0] = 0;
> + return retval;
> +}
> +
> static int kfd_ioctl_get_dmabuf_info(struct file *filep,
> struct kfd_process *p, void *data)
> {
> @@ -1761,6 +1804,8 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
> AMDKFD_IOCTL_DEF(AMDKFD_IOC_IMPORT_DMABUF,
> kfd_ioctl_import_dmabuf, 0),
>
> + AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
> + kfd_ioctl_alloc_queue_gws, 0),
> };
>
> #define AMDKFD_CORE_IOCTL_COUNT ARRAY_SIZE(amdkfd_ioctls)
> diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
> index 20917c5..1964ab2 100644
> --- a/include/uapi/linux/kfd_ioctl.h
> +++ b/include/uapi/linux/kfd_ioctl.h
> @@ -410,6 +410,20 @@ struct kfd_ioctl_unmap_memory_from_gpu_args {
> __u32 n_success; /* to/from KFD */
> };
>
> +/* Allocate GWS for specific queue
> + *
> + * @gpu_id: device identifier
> + * @queue_id: queue's id that GWS is allocated for
> + * @num_gws: how many GWS to allocate
> + * @gws_array: used to return the allocated gws
> + */
> +struct kfd_ioctl_alloc_queue_gws_args {
> + __u32 gpu_id; /* to KFD */
> + __u32 queue_id; /* to KFD */
> + __u32 num_gws; /* to KFD */
> + __u32 *gws_array; /* from KFD */
Don't use pointers in ioctl structures. Use uint64_t. Accessing user
mode pointers requires copy_to/from_user or similar.
Also prefer to move 64-bit elements to the first element to ensure
proper alignment, and pad the structure to 64-bit for ABI compatibility.
I'm not sure what your plan is for that gws_array. If it's a pointer to
a user mode array, then that array needs be allocated by user mode. And
user mode should probably pass down the size of the array it allocated
in another parameter.
That said, I think what we want is not an array, but just the index of
the first GWS entry that was allocated for the queue, which is currently
always 0. So I'm not sure why you're calling this an "array".
> +};
> +
> struct kfd_ioctl_get_dmabuf_info_args {
> __u64 size; /* from KFD */
> __u64 metadata_ptr; /* to KFD */
> @@ -529,7 +543,10 @@ enum kfd_mmio_remap {
> #define AMDKFD_IOC_IMPORT_DMABUF \
> AMDKFD_IOWR(0x1D, struct kfd_ioctl_import_dmabuf_args)
>
> +#define AMDKFD_IOC_ALLOC_QUEUE_GWS \
> + AMDKFD_IOWR(0x1E, struct kfd_ioctl_alloc_queue_gws_args)
> +
This will force us to move some ioctl numbers in amd-kfd-staging and the
DKMS branch, which will break the ABI of our ROCm releases. Not sure
there is a good way to avoid that other than leaving a whole in the
upstream ioctl space. I got push-back on that kind of thing when I
originally upstreamed KFD. So this is just an FYI.
Regards,
Felix
> #define AMDKFD_COMMAND_START 0x01
> -#define AMDKFD_COMMAND_END 0x1E
> +#define AMDKFD_COMMAND_END 0x1F
>
> #endif
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-05-10 20:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 16:01 [PATCH 1/8] drm/amdkfd: Add gws number to kfd topology node properties Zeng, Oak
[not found] ` <1557504063-1559-1-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-05-10 16:01 ` [PATCH 2/8] drm/amdgpu: Remove GWS barriers pre-reservation for gfx Zeng, Oak
[not found] ` <1557504063-1559-2-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-05-10 17:41 ` Christian König
2019-05-10 16:01 ` [PATCH 3/8] drm/amdkfd: Add interface to alloc gws from amdgpu Zeng, Oak
2019-05-10 16:01 ` [PATCH 4/8] drm/amdkfd: Allocate gws on device initialization Zeng, Oak
2019-05-10 16:01 ` [PATCH 5/8] drm/amdkfd: Add function to set queue gws Zeng, Oak
2019-05-10 16:01 ` [PATCH 6/8] drm/amdkfd: Add function to add/remove gws to kfd process Zeng, Oak
[not found] ` <1557504063-1559-6-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-05-10 20:17 ` Kuehling, Felix
2019-05-10 16:01 ` [PATCH 7/8] drm/amdkfd: New IOCTL to allocate queue GWS Zeng, Oak
[not found] ` <1557504063-1559-7-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-05-10 20:28 ` Kuehling, Felix [this message]
[not found] ` <c76522c2-115e-a6b6-f136-44fa2a45be2b-5C7GfCeVMHo@public.gmane.org>
2019-05-13 16:03 ` Zeng, Oak
[not found] ` <BL0PR12MB258003620CDCE779957C845B800F0-b4cIHhjg/p/XzH18dTCKOgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-05-13 18:12 ` Kuehling, Felix
[not found] ` <83257525-4d46-acbd-5853-eeb6913fa398-5C7GfCeVMHo@public.gmane.org>
2019-05-13 19:14 ` Christian König
2019-05-10 16:01 ` [PATCH 8/8] drm/amdkfd: PM4 packets change to support GWS Zeng, Oak
-- strict thread matches above, loose matches on Subject: below --
2019-05-13 18:50 [PATCH 5/8] drm/amdkfd: Add function to set queue gws Zeng, Oak
[not found] ` <1557773393-13707-1-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-05-13 18:50 ` [PATCH 7/8] drm/amdkfd: New IOCTL to allocate queue GWS Zeng, Oak
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=c76522c2-115e-a6b6-f136-44fa2a45be2b@amd.com \
--to=felix.kuehling-5c7gfcevmho@public.gmane.org \
--cc=Oak.Zeng-5C7GfCeVMHo@public.gmane.org \
--cc=Sean.Keely-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/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