Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: vitaly prosyak <vprosyak@amd.com>
To: Sunil Khatri <sunil.khatri@amd.com>, igt-dev@lists.freedesktop.org
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Vitaly Prosyak" <vitaly.prosyak@amd.com>,
	"Zhang, Jesse(Jie)" <Jesse.Zhang@amd.com>
Subject: Re: [PATCH v3 02/19] drm-uapi/amdgpu: sync with drm-next
Date: Mon, 31 Mar 2025 15:11:52 -0400	[thread overview]
Message-ID: <9c9978cb-0193-447a-935a-2f146a84f9a1@amd.com> (raw)
In-Reply-To: <20250328082416.1469810-2-sunil.khatri@amd.com>

[-- Attachment #1: Type: text/plain, Size: 5955 bytes --]


On 2025-03-28 04:23, Sunil Khatri wrote:
> Sync with drm-next commit ("866fc4f7e772c4a397f9459754ed1b1872b3a3c6")
>
> Added support of UAPI for user queue secure semaphore.
> The semaphore is used to synchronize between the caller and
> the gpu hw and user wait for the semaphore.
>
> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
> ---
>  include/drm-uapi/amdgpu_drm.h | 117 ++++++++++++++++++++++++++++++++++
>  1 file changed, 117 insertions(+)
>
> diff --git a/include/drm-uapi/amdgpu_drm.h b/include/drm-uapi/amdgpu_drm.h
> index d780e1f2a..fed39c9b4 100644
> --- a/include/drm-uapi/amdgpu_drm.h
> +++ b/include/drm-uapi/amdgpu_drm.h
> @@ -55,6 +55,8 @@ extern "C" {
>  #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>  #define DRM_AMDGPU_SCHED		0x15
>  #define DRM_AMDGPU_USERQ		0x16
> +#define DRM_AMDGPU_USERQ_SIGNAL		0x17
> +#define DRM_AMDGPU_USERQ_WAIT		0x18
>  
>  #define DRM_IOCTL_AMDGPU_GEM_CREATE	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
>  #define DRM_IOCTL_AMDGPU_GEM_MMAP	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
> @@ -73,6 +75,8 @@ extern "C" {
>  #define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
>  #define DRM_IOCTL_AMDGPU_SCHED		DRM_IOW(DRM_COMMAND_BASE + DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
>  #define DRM_IOCTL_AMDGPU_USERQ		DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_USERQ, union drm_amdgpu_userq)
> +#define DRM_IOCTL_AMDGPU_USERQ_SIGNAL	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_USERQ_SIGNAL, struct drm_amdgpu_userq_signal)
> +#define DRM_IOCTL_AMDGPU_USERQ_WAIT	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_USERQ_WAIT, struct drm_amdgpu_userq_wait)
>  
>  /**
>   * DOC: memory domains
> @@ -442,6 +446,119 @@ struct drm_amdgpu_userq_mqd_compute_gfx11 {
>  	__u64   eop_va;
>  };
>  
> +/* userq signal/wait ioctl */
> +struct drm_amdgpu_userq_signal {
> +	/**
> +	 * @queue_id: Queue handle used by the userq fence creation function
> +	 * to retrieve the WPTR.
> +	 */
> +	__u32	queue_id;
> +	__u32	pad;
> +	/**
> +	 * @syncobj_handles: The list of syncobj handles submitted by the user queue
> +	 * job to be signaled.
> +	 */

I am not sure about the correctness of the 'list of syncobj handles.' If it is a list, the field should be of type |list_head|; if it's an array, it should be |__u64*|, since the next field declares |num_syncobj_handles|. Could you clarify this?

There are several fields like this ?

> +	__u64	syncobj_handles;
> +	/**
> +	 * @num_syncobj_handles: A count that represents the number of syncobj handles in
> +	 * @syncobj_handles.
> +	 */
> +	__u64	num_syncobj_handles;
> +	/**
> +	 * @bo_read_handles: The list of BO handles that the submitted user queue job
> +	 * is using for read only. This will update BO fences in the kernel.
> +	 */
> +	__u64	bo_read_handles;
> +	/**
> +	 * @bo_write_handles: The list of BO handles that the submitted user queue job
> +	 * is using for write only. This will update BO fences in the kernel.
> +	 */
> +	__u64	bo_write_handles;
> +	/**
> +	 * @num_bo_read_handles: A count that represents the number of read BO handles in
> +	 * @bo_read_handles.
> +	 */
> +	__u32	num_bo_read_handles;
> +	/**
> +	 * @num_bo_write_handles: A count that represents the number of write BO handles in
> +	 * @bo_write_handles.
> +	 */
> +	__u32	num_bo_write_handles;
> +};
> +
> +struct drm_amdgpu_userq_fence_info {
> +	/**
> +	 * @va: A gpu address allocated for each queue which stores the
> +	 * read pointer (RPTR) value.
> +	 */
> +	__u64	va;
> +	/**
> +	 * @value: A 64 bit value represents the write pointer (WPTR) of the
> +	 * queue commands which compared with the RPTR value to signal the
> +	 * fences.
> +	 */
> +	__u64	value;
> +};
> +
> +struct drm_amdgpu_userq_wait {
> +	/**
> +	 * @syncobj_handles: The list of syncobj handles submitted by the user queue
> +	 * job to get the va/value pairs.
> +	 */
> +	__u64	syncobj_handles;
> +	/**
> +	 * @syncobj_timeline_handles: The list of timeline syncobj handles submitted by
> +	 * the user queue job to get the va/value pairs at given @syncobj_timeline_points.
> +	 */
> +	__u64	syncobj_timeline_handles;
> +	/**
> +	 * @syncobj_timeline_points: The list of timeline syncobj points submitted by the
> +	 * user queue job for the corresponding @syncobj_timeline_handles.
> +	 */
> +	__u64	syncobj_timeline_points;
> +	/**
> +	 * @bo_read_handles: The list of read BO handles submitted by the user queue
> +	 * job to get the va/value pairs.
> +	 */
> +	__u64	bo_read_handles;
> +	/**
> +	 * @bo_write_handles: The list of write BO handles submitted by the user queue
> +	 * job to get the va/value pairs.
> +	 */
> +	__u64	bo_write_handles;
> +	/**
> +	 * @num_syncobj_timeline_handles: A count that represents the number of timeline
> +	 * syncobj handles in @syncobj_timeline_handles.
> +	 */
> +	__u16	num_syncobj_timeline_handles;
> +	/**
> +	 * @num_fences: This field can be used both as input and output. As input it defines
> +	 * the maximum number of fences that can be returned and as output it will specify
> +	 * how many fences were actually returned from the ioctl.
> +	 */
> +	__u16	num_fences;
> +	/**
> +	 * @num_syncobj_handles: A count that represents the number of syncobj handles in
> +	 * @syncobj_handles.
> +	 */
> +	__u32	num_syncobj_handles;
> +	/**
> +	 * @num_bo_read_handles: A count that represents the number of read BO handles in
> +	 * @bo_read_handles.
> +	 */
> +	__u32	num_bo_read_handles;
> +	/**
> +	 * @num_bo_write_handles: A count that represents the number of write BO handles in
> +	 * @bo_write_handles.
> +	 */
> +	__u32	num_bo_write_handles;
> +	/**
> +	 * @out_fences: The field is a return value from the ioctl containing the list of
> +	 * address/value pairs to wait for.
> +	 */
> +	__u64	out_fences;
> +};
> +
>  /* vm ioctl */
>  #define AMDGPU_VM_OP_RESERVE_VMID	1
>  #define AMDGPU_VM_OP_UNRESERVE_VMID	2

[-- Attachment #2: Type: text/html, Size: 6453 bytes --]

  reply	other threads:[~2025-03-31 19:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-28  8:23 [PATCH v3 01/19] drm-uapi/amdgpu: sync with drm-next Sunil Khatri
2025-03-28  8:23 ` [PATCH v3 02/19] " Sunil Khatri
2025-03-31 19:11   ` vitaly prosyak [this message]
2025-04-01  4:39     ` Khatri, Sunil
2025-04-01  4:50       ` vitaly prosyak
2025-04-01  5:46         ` Khatri, Sunil
2025-04-01 16:09   ` Kamil Konieczny
2025-03-28  8:24 ` [PATCH v3 03/19] lib/amdgpu: Add user mode queue support in ring context Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 04/19] lib/amdgpu: Add support of amd user queues Sunil Khatri
2025-04-01  4:21   ` vitaly prosyak
2025-04-01  4:41     ` Khatri, Sunil
2025-03-28  8:24 ` [PATCH v3 05/19] lib/amdgpu: add func amdgpu_bo_alloc_and_map_sync Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 06/19] tests/amdgpu: Add user queue support for gfx and compute Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 07/19] tests/amdgpu: Add UMQ submission tests " Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 08/19] tests/amdgpu: Add amdgpu_sync_dependency_test with UMQ Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 09/19] tests/amdgpu: use memory API's from amd_memory.h Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 10/19] lib/amdgpu: add macro for adding cmds in user queue Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 11/19] lib/amdgpu: use macro to add cmds in the user ring Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 12/19] tests/amdgpu: Add amdgpu_cp_nops tests for UMQ Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 13/19] drm-uapi/amdgpu: sync with drm-next Sunil Khatri
2025-04-01 16:06   ` Kamil Konieczny
2025-04-01 23:52     ` vitaly prosyak
2025-04-02 10:51       ` Kamil Konieczny
2025-04-01 23:57     ` vitaly prosyak
2025-03-28  8:24 ` [PATCH v3 14/19] lib/amdgpu: use right API to get the correct size Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 15/19] lib/amdgpu: use a memory fence to serialize write Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 16/19] tests/amdgpu: disable check for IP presense with no kernel queue Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 17/19] lib/amdgpu: make the local functions as static Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 18/19] lib/amdgpu: enable UMQ function under macro Sunil Khatri
2025-03-28  8:24 ` [PATCH v3 19/19] tests/amdgpu: Disable the UMQ tests under a macro Sunil Khatri
2025-03-28 13:01 ` ✓ Xe.CI.BAT: success for series starting with [v3,01/19] drm-uapi/amdgpu: sync with drm-next Patchwork
2025-03-28 13:12 ` ✗ i915.CI.BAT: failure " Patchwork
2025-03-29  0:43 ` ✗ Xe.CI.Full: " Patchwork
2025-04-01 23:46 ` [PATCH v3 01/19] " vitaly prosyak
2025-04-06 18:47 ` ✗ Xe.CI.Full: failure for series starting with [v3,01/19] " Patchwork

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=9c9978cb-0193-447a-935a-2f146a84f9a1@amd.com \
    --to=vprosyak@amd.com \
    --cc=Jesse.Zhang@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=sunil.khatri@amd.com \
    --cc=vitaly.prosyak@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