All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
@ 2018-07-30 10:02 Junwei Zhang
       [not found] ` <1532944950-28619-1-git-send-email-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Junwei Zhang @ 2018-07-30 10:02 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Junwei Zhang, Chunming Zhou, christian.koenig-5C7GfCeVMHo

From: Chunming Zhou <David1.Zhou@amd.com>

v2: get original gem handle from gobj
v3: update find bo data structure as union(in, out)
    simply some code logic

Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
 include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
 4 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4cd20e7..46c370b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
 			  struct drm_file *filp);
 int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
 			struct drm_file *filp);
+int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
+					    struct drm_file *filp);
 int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
 			  struct drm_file *filp);
 int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 71792d8..bae8417 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
 	return 0;
 }
 
+static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
+					     struct drm_gem_object *obj)
+{
+	int i;
+	struct drm_gem_object *tmp;
+
+	spin_lock(&filp->table_lock);
+	idr_for_each_entry(&filp->object_idr, tmp, i) {
+		if (obj == tmp) {
+			drm_gem_object_reference(obj);
+			spin_unlock(&filp->table_lock);
+			return i;
+		}
+	}
+	spin_unlock(&filp->table_lock);
+
+	return 0;
+}
+
+int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
+					    struct drm_file *filp)
+{
+	union drm_amdgpu_gem_find_bo *args = data;
+	struct drm_gem_object *gobj;
+	struct amdgpu_bo *bo;
+	struct ttm_buffer_object *tbo;
+	struct vm_area_struct *vma;
+	uint32_t handle;
+	int r;
+
+	if (offset_in_page(args->in.addr | args->in.size))
+		return -EINVAL;
+
+	down_read(&current->mm->mmap_sem);
+	vma = find_vma(current->mm, args->in.addr);
+	if (!vma || vma->vm_file != filp->filp ||
+	    (args->in.size > (vma->vm_end - args->in.addr))) {
+		args->out.handle = 0;
+		up_read(&current->mm->mmap_sem);
+		return -EINVAL;
+	}
+	args->out.offset = args->in.addr - vma->vm_start;
+
+	tbo = vma->vm_private_data;
+	bo = container_of(tbo, struct amdgpu_bo, tbo);
+	amdgpu_bo_ref(bo);
+	gobj = &bo->gem_base;
+
+	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
+	if (!handle) {
+		r = drm_gem_handle_create(filp, gobj, &handle);
+		if (r) {
+			DRM_ERROR("create gem handle failed\n");
+			up_read(&current->mm->mmap_sem);
+			return r;
+		}
+	}
+	args->out.handle = handle;
+	up_read(&current->mm->mmap_sem);
+
+	return 0;
+}
+
 int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
 			     struct drm_file *filp)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 7956848..1bd2cc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
 	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
 	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
 	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
-	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
+	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
+	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
 };
 const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
 
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 94444ee..000c415 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -54,6 +54,7 @@
 #define DRM_AMDGPU_VM			0x13
 #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
 #define DRM_AMDGPU_SCHED		0x15
+#define DRM_AMDGPU_GEM_FIND_BO		0x16
 /* not upstream */
 #define DRM_AMDGPU_FREESYNC	        0x5d
 
@@ -74,6 +75,7 @@
 #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
+#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
 
 /**
  * DOC: memory domains
@@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
 	struct drm_amdgpu_gem_wait_idle_out out;
 };
 
+struct drm_amdgpu_gem_find_bo_in {
+	/* CPU address */
+	__u64			addr;
+	/* memory size from CPU address */
+	__u64			size;
+};
+
+struct drm_amdgpu_gem_find_bo_out {
+	/* offset in bo */
+	__u64			offset;
+	/* resulting GEM handle */
+	__u32			handle;
+};
+
+union drm_amdgpu_gem_find_bo {
+	struct drm_amdgpu_gem_find_bo_in in;
+	struct drm_amdgpu_gem_find_bo_out out;
+};
+
 struct drm_amdgpu_wait_cs_in {
 	/* Command submission handle
          * handle equals 0 means none to wait for
-- 
1.9.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH 2/2] drm/amdgpu: bump version for API to find bo by cpu mapping
       [not found] ` <1532944950-28619-1-git-send-email-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
@ 2018-07-30 10:02   ` Junwei Zhang
  2018-07-30 10:47   ` [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3) Christian König
  1 sibling, 0 replies; 24+ messages in thread
From: Junwei Zhang @ 2018-07-30 10:02 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Junwei Zhang, david1.zhou-5C7GfCeVMHo, christian.koenig-5C7GfCeVMHo

bump version for new API involved.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8843a06..6b52551 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -70,9 +70,10 @@
  * - 3.25.0 - Add support for sensor query info (stable pstate sclk/mclk).
  * - 3.26.0 - GFX9: Process AMDGPU_IB_FLAG_TC_WB_NOT_INVALIDATE.
  * - 3.27.0 - Add new chunk to to AMDGPU_CS to enable BO_LIST creation.
+ * - 3.28.0 - Add API to find bo by cpu mapping for UMD bo validation.
  */
 #define KMS_DRIVER_MAJOR	3
-#define KMS_DRIVER_MINOR	27
+#define KMS_DRIVER_MINOR	28
 #define KMS_DRIVER_PATCHLEVEL	0
 
 int amdgpu_vram_limit = 0;
-- 
1.9.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found] ` <1532944950-28619-1-git-send-email-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
  2018-07-30 10:02   ` [PATCH 2/2] drm/amdgpu: bump version for API to find bo by cpu mapping Junwei Zhang
@ 2018-07-30 10:47   ` Christian König
       [not found]     ` <3d423f44-e47a-e70c-dfd9-80c1ff843e45-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  1 sibling, 1 reply; 24+ messages in thread
From: Christian König @ 2018-07-30 10:47 UTC (permalink / raw)
  To: Junwei Zhang, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou, christian.koenig-5C7GfCeVMHo

Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
> From: Chunming Zhou <David1.Zhou@amd.com>
>
> v2: get original gem handle from gobj
> v3: update find bo data structure as union(in, out)
>      simply some code logic

Do we now have an open source user for this, so that we can upstream it? 
One more point below.

>
> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4cd20e7..46c370b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			struct drm_file *filp);
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp);
>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index 71792d8..bae8417 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>   	return 0;
>   }
>   
> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
> +					     struct drm_gem_object *obj)
> +{
> +	int i;
> +	struct drm_gem_object *tmp;
> +
> +	spin_lock(&filp->table_lock);
> +	idr_for_each_entry(&filp->object_idr, tmp, i) {
> +		if (obj == tmp) {
> +			drm_gem_object_reference(obj);
> +			spin_unlock(&filp->table_lock);
> +			return i;
> +		}
> +	}

Please double check if that is still up to date.

I think we could as well try to use the DMA-buf handle tree for that.

Christian.

> +	spin_unlock(&filp->table_lock);
> +
> +	return 0;
> +}
> +
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp)
> +{
> +	union drm_amdgpu_gem_find_bo *args = data;
> +	struct drm_gem_object *gobj;
> +	struct amdgpu_bo *bo;
> +	struct ttm_buffer_object *tbo;
> +	struct vm_area_struct *vma;
> +	uint32_t handle;
> +	int r;
> +
> +	if (offset_in_page(args->in.addr | args->in.size))
> +		return -EINVAL;
> +
> +	down_read(&current->mm->mmap_sem);
> +	vma = find_vma(current->mm, args->in.addr);
> +	if (!vma || vma->vm_file != filp->filp ||
> +	    (args->in.size > (vma->vm_end - args->in.addr))) {
> +		args->out.handle = 0;
> +		up_read(&current->mm->mmap_sem);
> +		return -EINVAL;
> +	}
> +	args->out.offset = args->in.addr - vma->vm_start;
> +
> +	tbo = vma->vm_private_data;
> +	bo = container_of(tbo, struct amdgpu_bo, tbo);
> +	amdgpu_bo_ref(bo);
> +	gobj = &bo->gem_base;
> +
> +	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
> +	if (!handle) {
> +		r = drm_gem_handle_create(filp, gobj, &handle);
> +		if (r) {
> +			DRM_ERROR("create gem handle failed\n");
> +			up_read(&current->mm->mmap_sem);
> +			return r;
> +		}
> +	}
> +	args->out.handle = handle;
> +	up_read(&current->mm->mmap_sem);
> +
> +	return 0;
> +}
> +
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			     struct drm_file *filp)
>   {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 7956848..1bd2cc1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> -	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
> +	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>   };
>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>   
> diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> index 94444ee..000c415 100644
> --- a/include/uapi/drm/amdgpu_drm.h
> +++ b/include/uapi/drm/amdgpu_drm.h
> @@ -54,6 +54,7 @@
>   #define DRM_AMDGPU_VM			0x13
>   #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>   #define DRM_AMDGPU_SCHED		0x15
> +#define DRM_AMDGPU_GEM_FIND_BO		0x16
>   /* not upstream */
>   #define DRM_AMDGPU_FREESYNC	        0x5d
>   
> @@ -74,6 +75,7 @@
>   #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>   
>   /**
>    * DOC: memory domains
> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>   	struct drm_amdgpu_gem_wait_idle_out out;
>   };
>   
> +struct drm_amdgpu_gem_find_bo_in {
> +	/* CPU address */
> +	__u64			addr;
> +	/* memory size from CPU address */
> +	__u64			size;
> +};
> +
> +struct drm_amdgpu_gem_find_bo_out {
> +	/* offset in bo */
> +	__u64			offset;
> +	/* resulting GEM handle */
> +	__u32			handle;
> +};
> +
> +union drm_amdgpu_gem_find_bo {
> +	struct drm_amdgpu_gem_find_bo_in in;
> +	struct drm_amdgpu_gem_find_bo_out out;
> +};
> +
>   struct drm_amdgpu_wait_cs_in {
>   	/* Command submission handle
>            * handle equals 0 means none to wait for

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* RE: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]     ` <3d423f44-e47a-e70c-dfd9-80c1ff843e45-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-07-31  1:40       ` Zhou, David(ChunMing)
       [not found]         ` <SN1PR12MB051036BA7AC3560A4FAC68A1B42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  2018-07-31  6:58       ` Zhang, Jerry (Junwei)
  1 sibling, 1 reply; 24+ messages in thread
From: Zhou, David(ChunMing) @ 2018-07-31  1:40 UTC (permalink / raw)
  To: Koenig, Christian, Zhang, Jerry,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Thanks for Jerry  still  remembers  this series.

Hi Christian,

For upstream of this feature, seems we already had agreement long time ago. Two reasons for upstreaming:
1. this bug was found by an opengl game, so this bug also is in mesa driver in theory.
2. after upstream these patches, we can reduce pro specific patches, and close to open source.

Btw, an unit test is excepted when upstreaming, I remember Alex mentioned.

Thanks,
David Zhou
-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@gmail.com> 
Sent: Monday, July 30, 2018 6:48 PM
To: Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
Cc: Zhou, David(ChunMing) <David1.Zhou@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
> From: Chunming Zhou <David1.Zhou@amd.com>
>
> v2: get original gem handle from gobj
> v3: update find bo data structure as union(in, out)
>      simply some code logic

Do we now have an open source user for this, so that we can upstream it? 
One more point below.

>
> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4cd20e7..46c370b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			struct drm_file *filp);
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp);
>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data, 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index 71792d8..bae8417 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>   	return 0;
>   }
>   
> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
> +					     struct drm_gem_object *obj) {
> +	int i;
> +	struct drm_gem_object *tmp;
> +
> +	spin_lock(&filp->table_lock);
> +	idr_for_each_entry(&filp->object_idr, tmp, i) {
> +		if (obj == tmp) {
> +			drm_gem_object_reference(obj);
> +			spin_unlock(&filp->table_lock);
> +			return i;
> +		}
> +	}

Please double check if that is still up to date.

I think we could as well try to use the DMA-buf handle tree for that.

Christian.

> +	spin_unlock(&filp->table_lock);
> +
> +	return 0;
> +}
> +
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp)
> +{
> +	union drm_amdgpu_gem_find_bo *args = data;
> +	struct drm_gem_object *gobj;
> +	struct amdgpu_bo *bo;
> +	struct ttm_buffer_object *tbo;
> +	struct vm_area_struct *vma;
> +	uint32_t handle;
> +	int r;
> +
> +	if (offset_in_page(args->in.addr | args->in.size))
> +		return -EINVAL;
> +
> +	down_read(&current->mm->mmap_sem);
> +	vma = find_vma(current->mm, args->in.addr);
> +	if (!vma || vma->vm_file != filp->filp ||
> +	    (args->in.size > (vma->vm_end - args->in.addr))) {
> +		args->out.handle = 0;
> +		up_read(&current->mm->mmap_sem);
> +		return -EINVAL;
> +	}
> +	args->out.offset = args->in.addr - vma->vm_start;
> +
> +	tbo = vma->vm_private_data;
> +	bo = container_of(tbo, struct amdgpu_bo, tbo);
> +	amdgpu_bo_ref(bo);
> +	gobj = &bo->gem_base;
> +
> +	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
> +	if (!handle) {
> +		r = drm_gem_handle_create(filp, gobj, &handle);
> +		if (r) {
> +			DRM_ERROR("create gem handle failed\n");
> +			up_read(&current->mm->mmap_sem);
> +			return r;
> +		}
> +	}
> +	args->out.handle = handle;
> +	up_read(&current->mm->mmap_sem);
> +
> +	return 0;
> +}
> +
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			     struct drm_file *filp)
>   {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 7956848..1bd2cc1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> -	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
> +	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, 
> +amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>   };
>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>   
> diff --git a/include/uapi/drm/amdgpu_drm.h 
> b/include/uapi/drm/amdgpu_drm.h index 94444ee..000c415 100644
> --- a/include/uapi/drm/amdgpu_drm.h
> +++ b/include/uapi/drm/amdgpu_drm.h
> @@ -54,6 +54,7 @@
>   #define DRM_AMDGPU_VM			0x13
>   #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>   #define DRM_AMDGPU_SCHED		0x15
> +#define DRM_AMDGPU_GEM_FIND_BO		0x16
>   /* not upstream */
>   #define DRM_AMDGPU_FREESYNC	        0x5d
>   
> @@ -74,6 +75,7 @@
>   #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>   
>   /**
>    * DOC: memory domains
> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>   	struct drm_amdgpu_gem_wait_idle_out out;
>   };
>   
> +struct drm_amdgpu_gem_find_bo_in {
> +	/* CPU address */
> +	__u64			addr;
> +	/* memory size from CPU address */
> +	__u64			size;
> +};
> +
> +struct drm_amdgpu_gem_find_bo_out {
> +	/* offset in bo */
> +	__u64			offset;
> +	/* resulting GEM handle */
> +	__u32			handle;
> +};
> +
> +union drm_amdgpu_gem_find_bo {
> +	struct drm_amdgpu_gem_find_bo_in in;
> +	struct drm_amdgpu_gem_find_bo_out out; };
> +
>   struct drm_amdgpu_wait_cs_in {
>   	/* Command submission handle
>            * handle equals 0 means none to wait for

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* RE: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]         ` <SN1PR12MB051036BA7AC3560A4FAC68A1B42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2018-07-31  1:49           ` Zhou, David(ChunMing)
       [not found]             ` <SN1PR12MB05106FBFF052EDFD49193ABCB42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  2018-07-31  6:54           ` Christian König
  1 sibling, 1 reply; 24+ messages in thread
From: Zhou, David(ChunMing) @ 2018-07-31  1:49 UTC (permalink / raw)
  To: Zhou, David(ChunMing),
	Koenig, Christian, Zhang, Jerry,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Typo, excepted -> expected

-----Original Message-----
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Zhou, David(ChunMing)
Sent: Tuesday, July 31, 2018 9:41 AM
To: Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

Thanks for Jerry  still  remembers  this series.

Hi Christian,

For upstream of this feature, seems we already had agreement long time ago. Two reasons for upstreaming:
1. this bug was found by an opengl game, so this bug also is in mesa driver in theory.
2. after upstream these patches, we can reduce pro specific patches, and close to open source.

Btw, an unit test is excepted when upstreaming, I remember Alex mentioned.

Thanks,
David Zhou
-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Monday, July 30, 2018 6:48 PM
To: Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
Cc: Zhou, David(ChunMing) <David1.Zhou@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
> From: Chunming Zhou <David1.Zhou@amd.com>
>
> v2: get original gem handle from gobj
> v3: update find bo data structure as union(in, out)
>      simply some code logic

Do we now have an open source user for this, so that we can upstream it? 
One more point below.

>
> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4cd20e7..46c370b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			struct drm_file *filp);
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp);
>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>   			  struct drm_file *filp);
>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data, 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index 71792d8..bae8417 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>   	return 0;
>   }
>   
> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
> +					     struct drm_gem_object *obj) {
> +	int i;
> +	struct drm_gem_object *tmp;
> +
> +	spin_lock(&filp->table_lock);
> +	idr_for_each_entry(&filp->object_idr, tmp, i) {
> +		if (obj == tmp) {
> +			drm_gem_object_reference(obj);
> +			spin_unlock(&filp->table_lock);
> +			return i;
> +		}
> +	}

Please double check if that is still up to date.

I think we could as well try to use the DMA-buf handle tree for that.

Christian.

> +	spin_unlock(&filp->table_lock);
> +
> +	return 0;
> +}
> +
> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
> +					    struct drm_file *filp)
> +{
> +	union drm_amdgpu_gem_find_bo *args = data;
> +	struct drm_gem_object *gobj;
> +	struct amdgpu_bo *bo;
> +	struct ttm_buffer_object *tbo;
> +	struct vm_area_struct *vma;
> +	uint32_t handle;
> +	int r;
> +
> +	if (offset_in_page(args->in.addr | args->in.size))
> +		return -EINVAL;
> +
> +	down_read(&current->mm->mmap_sem);
> +	vma = find_vma(current->mm, args->in.addr);
> +	if (!vma || vma->vm_file != filp->filp ||
> +	    (args->in.size > (vma->vm_end - args->in.addr))) {
> +		args->out.handle = 0;
> +		up_read(&current->mm->mmap_sem);
> +		return -EINVAL;
> +	}
> +	args->out.offset = args->in.addr - vma->vm_start;
> +
> +	tbo = vma->vm_private_data;
> +	bo = container_of(tbo, struct amdgpu_bo, tbo);
> +	amdgpu_bo_ref(bo);
> +	gobj = &bo->gem_base;
> +
> +	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
> +	if (!handle) {
> +		r = drm_gem_handle_create(filp, gobj, &handle);
> +		if (r) {
> +			DRM_ERROR("create gem handle failed\n");
> +			up_read(&current->mm->mmap_sem);
> +			return r;
> +		}
> +	}
> +	args->out.handle = handle;
> +	up_read(&current->mm->mmap_sem);
> +
> +	return 0;
> +}
> +
>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>   			     struct drm_file *filp)
>   {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 7956848..1bd2cc1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>   	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> -	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
> +	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO,
> +amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>   };
>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>   
> diff --git a/include/uapi/drm/amdgpu_drm.h 
> b/include/uapi/drm/amdgpu_drm.h index 94444ee..000c415 100644
> --- a/include/uapi/drm/amdgpu_drm.h
> +++ b/include/uapi/drm/amdgpu_drm.h
> @@ -54,6 +54,7 @@
>   #define DRM_AMDGPU_VM			0x13
>   #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>   #define DRM_AMDGPU_SCHED		0x15
> +#define DRM_AMDGPU_GEM_FIND_BO		0x16
>   /* not upstream */
>   #define DRM_AMDGPU_FREESYNC	        0x5d
>   
> @@ -74,6 +75,7 @@
>   #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>   
>   /**
>    * DOC: memory domains
> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>   	struct drm_amdgpu_gem_wait_idle_out out;
>   };
>   
> +struct drm_amdgpu_gem_find_bo_in {
> +	/* CPU address */
> +	__u64			addr;
> +	/* memory size from CPU address */
> +	__u64			size;
> +};
> +
> +struct drm_amdgpu_gem_find_bo_out {
> +	/* offset in bo */
> +	__u64			offset;
> +	/* resulting GEM handle */
> +	__u32			handle;
> +};
> +
> +union drm_amdgpu_gem_find_bo {
> +	struct drm_amdgpu_gem_find_bo_in in;
> +	struct drm_amdgpu_gem_find_bo_out out; };
> +
>   struct drm_amdgpu_wait_cs_in {
>   	/* Command submission handle
>            * handle equals 0 means none to wait for

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]             ` <SN1PR12MB05106FBFF052EDFD49193ABCB42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2018-07-31  2:32               ` Zhang, Jerry (Junwei)
  0 siblings, 0 replies; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-07-31  2:32 UTC (permalink / raw)
  To: Zhou, David(ChunMing),
	Koenig, Christian, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

On 07/31/2018 09:49 AM, Zhou, David(ChunMing) wrote:
> Typo, excepted -> expected
>
> -----Original Message-----
> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Zhou, David(ChunMing)
> Sent: Tuesday, July 31, 2018 9:41 AM
> To: Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
>
> Thanks for Jerry  still  remembers  this series.
>
> Hi Christian,
>
> For upstream of this feature, seems we already had agreement long time ago. Two reasons for upstreaming:
> 1. this bug was found by an opengl game, so this bug also is in mesa driver in theory.
> 2. after upstream these patches, we can reduce pro specific patches, and close to open source.

Thanks for explanation.

>
> Btw, an unit test is excepted when upstreaming, I remember Alex mentioned.

Yes, I will.

>
> Thanks,
> David Zhou
> -----Original Message-----
> From: Christian König <ckoenig.leichtzumerken@gmail.com>
> Sent: Monday, July 30, 2018 6:48 PM
> To: Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Zhou, David(ChunMing) <David1.Zhou@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
> Subject: Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
>
> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>> From: Chunming Zhou <David1.Zhou@amd.com>
>>
>> v2: get original gem handle from gobj
>> v3: update find bo data structure as union(in, out)
>>       simply some code logic
>
> Do we now have an open source user for this, so that we can upstream it?
> One more point below.
>
>>
>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>> ---
>>    drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>    include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>    4 files changed, 88 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 4cd20e7..46c370b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>>    			  struct drm_file *filp);
>>    int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>    			struct drm_file *filp);
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +					    struct drm_file *filp);
>>    int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>    			  struct drm_file *filp);
>>    int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index 71792d8..bae8417 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>>    	return 0;
>>    }
>>
>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>> +					     struct drm_gem_object *obj) {
>> +	int i;
>> +	struct drm_gem_object *tmp;
>> +
>> +	spin_lock(&filp->table_lock);
>> +	idr_for_each_entry(&filp->object_idr, tmp, i) {
>> +		if (obj == tmp) {
>> +			drm_gem_object_reference(obj);
>> +			spin_unlock(&filp->table_lock);
>> +			return i;
>> +		}
>> +	}
>
> Please double check if that is still up to date.

We may have to replace drm_gem_object_reference() with drm_gem_object_get().

On 2nd thought, do we really need to do reference every time?
if UMD find the same gem object for 3 times, it also need to explicitly free(put) that object for 3 times?


>
> I think we could as well try to use the DMA-buf handle tree for that.

If the bo is not import/export, DMA-buf will be NULL always.

Regards,
Jerry

>
> Christian.
>
>> +	spin_unlock(&filp->table_lock);
>> +
>> +	return 0;
>> +}
>> +
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +					    struct drm_file *filp)
>> +{
>> +	union drm_amdgpu_gem_find_bo *args = data;
>> +	struct drm_gem_object *gobj;
>> +	struct amdgpu_bo *bo;
>> +	struct ttm_buffer_object *tbo;
>> +	struct vm_area_struct *vma;
>> +	uint32_t handle;
>> +	int r;
>> +
>> +	if (offset_in_page(args->in.addr | args->in.size))
>> +		return -EINVAL;
>> +
>> +	down_read(&current->mm->mmap_sem);
>> +	vma = find_vma(current->mm, args->in.addr);
>> +	if (!vma || vma->vm_file != filp->filp ||
>> +	    (args->in.size > (vma->vm_end - args->in.addr))) {
>> +		args->out.handle = 0;
>> +		up_read(&current->mm->mmap_sem);
>> +		return -EINVAL;
>> +	}
>> +	args->out.offset = args->in.addr - vma->vm_start;
>> +
>> +	tbo = vma->vm_private_data;
>> +	bo = container_of(tbo, struct amdgpu_bo, tbo);
>> +	amdgpu_bo_ref(bo);
>> +	gobj = &bo->gem_base;
>> +
>> +	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
>> +	if (!handle) {
>> +		r = drm_gem_handle_create(filp, gobj, &handle);
>> +		if (r) {
>> +			DRM_ERROR("create gem handle failed\n");
>> +			up_read(&current->mm->mmap_sem);
>> +			return r;
>> +		}
>> +	}
>> +	args->out.handle = handle;
>> +	up_read(&current->mm->mmap_sem);
>> +
>> +	return 0;
>> +}
>> +
>>    int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>    			     struct drm_file *filp)
>>    {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index 7956848..1bd2cc1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>> -	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
>> +	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
>> +	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO,
>> +amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>>    };
>>    const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>>
>> diff --git a/include/uapi/drm/amdgpu_drm.h
>> b/include/uapi/drm/amdgpu_drm.h index 94444ee..000c415 100644
>> --- a/include/uapi/drm/amdgpu_drm.h
>> +++ b/include/uapi/drm/amdgpu_drm.h
>> @@ -54,6 +54,7 @@
>>    #define DRM_AMDGPU_VM			0x13
>>    #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>>    #define DRM_AMDGPU_SCHED		0x15
>> +#define DRM_AMDGPU_GEM_FIND_BO		0x16
>>    /* not upstream */
>>    #define DRM_AMDGPU_FREESYNC	        0x5d
>>
>> @@ -74,6 +75,7 @@
>>    #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>>
>>    /**
>>     * DOC: memory domains
>> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>>    	struct drm_amdgpu_gem_wait_idle_out out;
>>    };
>>
>> +struct drm_amdgpu_gem_find_bo_in {
>> +	/* CPU address */
>> +	__u64			addr;
>> +	/* memory size from CPU address */
>> +	__u64			size;
>> +};
>> +
>> +struct drm_amdgpu_gem_find_bo_out {
>> +	/* offset in bo */
>> +	__u64			offset;
>> +	/* resulting GEM handle */
>> +	__u32			handle;
>> +};
>> +
>> +union drm_amdgpu_gem_find_bo {
>> +	struct drm_amdgpu_gem_find_bo_in in;
>> +	struct drm_amdgpu_gem_find_bo_out out; };
>> +
>>    struct drm_amdgpu_wait_cs_in {
>>    	/* Command submission handle
>>             * handle equals 0 means none to wait for
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]         ` <SN1PR12MB051036BA7AC3560A4FAC68A1B42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  2018-07-31  1:49           ` Zhou, David(ChunMing)
@ 2018-07-31  6:54           ` Christian König
  1 sibling, 0 replies; 24+ messages in thread
From: Christian König @ 2018-07-31  6:54 UTC (permalink / raw)
  To: Zhou, David(ChunMing),
	Koenig, Christian, Zhang, Jerry,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Am 31.07.2018 um 03:40 schrieb Zhou, David(ChunMing):
> Thanks for Jerry  still  remembers  this series.
>
> Hi Christian,
>
> For upstream of this feature, seems we already had agreement long time ago. Two reasons for upstreaming:
> 1. this bug was found by an opengl game, so this bug also is in mesa driver in theory.
> 2. after upstream these patches, we can reduce pro specific patches, and close to open source.

I mean the functionality is actually rather simple, so I don't see much 
of an issue with that.

> Btw, an unit test is excepted when upstreaming, I remember Alex mentioned.

Yeah, agree an unit test is really a must have for that.

Christian.

>
> Thanks,
> David Zhou
> -----Original Message-----
> From: Christian König <ckoenig.leichtzumerken@gmail.com>
> Sent: Monday, July 30, 2018 6:48 PM
> To: Zhang, Jerry <Jerry.Zhang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Zhou, David(ChunMing) <David1.Zhou@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
> Subject: Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
>
> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>> From: Chunming Zhou <David1.Zhou@amd.com>
>>
>> v2: get original gem handle from gobj
>> v3: update find bo data structure as union(in, out)
>>       simply some code logic
> Do we now have an open source user for this, so that we can upstream it?
> One more point below.
>
>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>> ---
>>    drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>    include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>    4 files changed, 88 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 4cd20e7..46c370b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>>    			  struct drm_file *filp);
>>    int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>    			struct drm_file *filp);
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +					    struct drm_file *filp);
>>    int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>    			  struct drm_file *filp);
>>    int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index 71792d8..bae8417 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>>    	return 0;
>>    }
>>    
>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>> +					     struct drm_gem_object *obj) {
>> +	int i;
>> +	struct drm_gem_object *tmp;
>> +
>> +	spin_lock(&filp->table_lock);
>> +	idr_for_each_entry(&filp->object_idr, tmp, i) {
>> +		if (obj == tmp) {
>> +			drm_gem_object_reference(obj);
>> +			spin_unlock(&filp->table_lock);
>> +			return i;
>> +		}
>> +	}
> Please double check if that is still up to date.
>
> I think we could as well try to use the DMA-buf handle tree for that.
>
> Christian.
>
>> +	spin_unlock(&filp->table_lock);
>> +
>> +	return 0;
>> +}
>> +
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +					    struct drm_file *filp)
>> +{
>> +	union drm_amdgpu_gem_find_bo *args = data;
>> +	struct drm_gem_object *gobj;
>> +	struct amdgpu_bo *bo;
>> +	struct ttm_buffer_object *tbo;
>> +	struct vm_area_struct *vma;
>> +	uint32_t handle;
>> +	int r;
>> +
>> +	if (offset_in_page(args->in.addr | args->in.size))
>> +		return -EINVAL;
>> +
>> +	down_read(&current->mm->mmap_sem);
>> +	vma = find_vma(current->mm, args->in.addr);
>> +	if (!vma || vma->vm_file != filp->filp ||
>> +	    (args->in.size > (vma->vm_end - args->in.addr))) {
>> +		args->out.handle = 0;
>> +		up_read(&current->mm->mmap_sem);
>> +		return -EINVAL;
>> +	}
>> +	args->out.offset = args->in.addr - vma->vm_start;
>> +
>> +	tbo = vma->vm_private_data;
>> +	bo = container_of(tbo, struct amdgpu_bo, tbo);
>> +	amdgpu_bo_ref(bo);
>> +	gobj = &bo->gem_base;
>> +
>> +	handle = amdgpu_gem_get_handle_from_object(filp, gobj);
>> +	if (!handle) {
>> +		r = drm_gem_handle_create(filp, gobj, &handle);
>> +		if (r) {
>> +			DRM_ERROR("create gem handle failed\n");
>> +			up_read(&current->mm->mmap_sem);
>> +			return r;
>> +		}
>> +	}
>> +	args->out.handle = handle;
>> +	up_read(&current->mm->mmap_sem);
>> +
>> +	return 0;
>> +}
>> +
>>    int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>    			     struct drm_file *filp)
>>    {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index 7956848..1bd2cc1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>    	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>> -	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
>> +	DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
>> +	DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO,
>> +amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>>    };
>>    const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>>    
>> diff --git a/include/uapi/drm/amdgpu_drm.h
>> b/include/uapi/drm/amdgpu_drm.h index 94444ee..000c415 100644
>> --- a/include/uapi/drm/amdgpu_drm.h
>> +++ b/include/uapi/drm/amdgpu_drm.h
>> @@ -54,6 +54,7 @@
>>    #define DRM_AMDGPU_VM			0x13
>>    #define DRM_AMDGPU_FENCE_TO_HANDLE	0x14
>>    #define DRM_AMDGPU_SCHED		0x15
>> +#define DRM_AMDGPU_GEM_FIND_BO		0x16
>>    /* not upstream */
>>    #define DRM_AMDGPU_FREESYNC	        0x5d
>>    
>> @@ -74,6 +75,7 @@
>>    #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_FREESYNC	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO	DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>>    
>>    /**
>>     * DOC: memory domains
>> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>>    	struct drm_amdgpu_gem_wait_idle_out out;
>>    };
>>    
>> +struct drm_amdgpu_gem_find_bo_in {
>> +	/* CPU address */
>> +	__u64			addr;
>> +	/* memory size from CPU address */
>> +	__u64			size;
>> +};
>> +
>> +struct drm_amdgpu_gem_find_bo_out {
>> +	/* offset in bo */
>> +	__u64			offset;
>> +	/* resulting GEM handle */
>> +	__u32			handle;
>> +};
>> +
>> +union drm_amdgpu_gem_find_bo {
>> +	struct drm_amdgpu_gem_find_bo_in in;
>> +	struct drm_amdgpu_gem_find_bo_out out; };
>> +
>>    struct drm_amdgpu_wait_cs_in {
>>    	/* Command submission handle
>>             * handle equals 0 means none to wait for
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]     ` <3d423f44-e47a-e70c-dfd9-80c1ff843e45-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2018-07-31  1:40       ` Zhou, David(ChunMing)
@ 2018-07-31  6:58       ` Zhang, Jerry (Junwei)
       [not found]         ` <5B6008A1.5050401-5C7GfCeVMHo@public.gmane.org>
  1 sibling, 1 reply; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-07-31  6:58 UTC (permalink / raw)
  To: christian.koenig-5C7GfCeVMHo, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

On 07/30/2018 06:47 PM, Christian König wrote:
> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>> From: Chunming Zhou <David1.Zhou@amd.com>
>>
>> v2: get original gem handle from gobj
>> v3: update find bo data structure as union(in, out)
>>      simply some code logic
>
> Do we now have an open source user for this, so that we can upstream it? One more point below.
>
>>
>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>   4 files changed, 88 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 4cd20e7..46c370b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>>                 struct drm_file *filp);
>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>               struct drm_file *filp);
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +                        struct drm_file *filp);
>>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>                 struct drm_file *filp);
>>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index 71792d8..bae8417 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>>       return 0;
>>   }
>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>> +                         struct drm_gem_object *obj)
>> +{
>> +    int i;
>> +    struct drm_gem_object *tmp;
>> +
>> +    spin_lock(&filp->table_lock);
>> +    idr_for_each_entry(&filp->object_idr, tmp, i) {
>> +        if (obj == tmp) {
>> +            drm_gem_object_reference(obj);
>> +            spin_unlock(&filp->table_lock);
>> +            return i;
>> +        }
>> +    }
>
> Please double check if that is still up to date.

We may have to replace drm_gem_object_reference() with drm_gem_object_get().

On 2nd thought, do we really need to do reference every time?
if UMD find the same gem object for 3 times, it also need to explicitly free(put) that object for 3 times?


>
> I think we could as well try to use the DMA-buf handle tree for that.

If the bo is not import/export, DMA-buf will be NULL always.

Regards,
Jerry
>
> Christian.
>
>> +    spin_unlock(&filp->table_lock);
>> +
>> +    return 0;
>> +}
>> +
>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>> +                        struct drm_file *filp)
>> +{
>> +    union drm_amdgpu_gem_find_bo *args = data;
>> +    struct drm_gem_object *gobj;
>> +    struct amdgpu_bo *bo;
>> +    struct ttm_buffer_object *tbo;
>> +    struct vm_area_struct *vma;
>> +    uint32_t handle;
>> +    int r;
>> +
>> +    if (offset_in_page(args->in.addr | args->in.size))
>> +        return -EINVAL;
>> +
>> +    down_read(&current->mm->mmap_sem);
>> +    vma = find_vma(current->mm, args->in.addr);
>> +    if (!vma || vma->vm_file != filp->filp ||
>> +        (args->in.size > (vma->vm_end - args->in.addr))) {
>> +        args->out.handle = 0;
>> +        up_read(&current->mm->mmap_sem);
>> +        return -EINVAL;
>> +    }
>> +    args->out.offset = args->in.addr - vma->vm_start;
>> +
>> +    tbo = vma->vm_private_data;
>> +    bo = container_of(tbo, struct amdgpu_bo, tbo);
>> +    amdgpu_bo_ref(bo);
>> +    gobj = &bo->gem_base;
>> +
>> +    handle = amdgpu_gem_get_handle_from_object(filp, gobj);
>> +    if (!handle) {
>> +        r = drm_gem_handle_create(filp, gobj, &handle);
>> +        if (r) {
>> +            DRM_ERROR("create gem handle failed\n");
>> +            up_read(&current->mm->mmap_sem);
>> +            return r;
>> +        }
>> +    }
>> +    args->out.handle = handle;
>> +    up_read(&current->mm->mmap_sem);
>> +
>> +    return 0;
>> +}
>> +
>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>                    struct drm_file *filp)
>>   {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index 7956848..1bd2cc1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>> -    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
>> +    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
>> +    DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>>   };
>>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>> diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
>> index 94444ee..000c415 100644
>> --- a/include/uapi/drm/amdgpu_drm.h
>> +++ b/include/uapi/drm/amdgpu_drm.h
>> @@ -54,6 +54,7 @@
>>   #define DRM_AMDGPU_VM            0x13
>>   #define DRM_AMDGPU_FENCE_TO_HANDLE    0x14
>>   #define DRM_AMDGPU_SCHED        0x15
>> +#define DRM_AMDGPU_GEM_FIND_BO        0x16
>>   /* not upstream */
>>   #define DRM_AMDGPU_FREESYNC            0x5d
>> @@ -74,6 +75,7 @@
>>   #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_FREESYNC    DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO    DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>>   /**
>>    * DOC: memory domains
>> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>>       struct drm_amdgpu_gem_wait_idle_out out;
>>   };
>> +struct drm_amdgpu_gem_find_bo_in {
>> +    /* CPU address */
>> +    __u64            addr;
>> +    /* memory size from CPU address */
>> +    __u64            size;
>> +};
>> +
>> +struct drm_amdgpu_gem_find_bo_out {
>> +    /* offset in bo */
>> +    __u64            offset;
>> +    /* resulting GEM handle */
>> +    __u32            handle;
>> +};
>> +
>> +union drm_amdgpu_gem_find_bo {
>> +    struct drm_amdgpu_gem_find_bo_in in;
>> +    struct drm_amdgpu_gem_find_bo_out out;
>> +};
>> +
>>   struct drm_amdgpu_wait_cs_in {
>>       /* Command submission handle
>>            * handle equals 0 means none to wait for
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]         ` <5B6008A1.5050401-5C7GfCeVMHo@public.gmane.org>
@ 2018-07-31  7:03           ` Christian König
       [not found]             ` <c6b11c1f-b32a-4ab8-6a78-aa7886eed60a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-07-31  7:03 UTC (permalink / raw)
  To: Zhang, Jerry (Junwei),
	christian.koenig-5C7GfCeVMHo,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
> On 07/30/2018 06:47 PM, Christian König wrote:
>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>> From: Chunming Zhou <David1.Zhou@amd.com>
>>>
>>> v2: get original gem handle from gobj
>>> v3: update find bo data structure as union(in, out)
>>>      simply some code logic
>>
>> Do we now have an open source user for this, so that we can upstream 
>> it? One more point below.
>>
>>>
>>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 
>>> +++++++++++++++++++++++++++++++++
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>>   4 files changed, 88 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 4cd20e7..46c370b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device 
>>> *dev, void *data,
>>>                 struct drm_file *filp);
>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>               struct drm_file *filp);
>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, 
>>> void *data,
>>> +                        struct drm_file *filp);
>>>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>>                 struct drm_file *filp);
>>>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index 71792d8..bae8417 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device 
>>> *dev, void *data,
>>>       return 0;
>>>   }
>>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>>> +                         struct drm_gem_object *obj)
>>> +{
>>> +    int i;
>>> +    struct drm_gem_object *tmp;
>>> +
>>> +    spin_lock(&filp->table_lock);
>>> +    idr_for_each_entry(&filp->object_idr, tmp, i) {
>>> +        if (obj == tmp) {
>>> +            drm_gem_object_reference(obj);
>>> +            spin_unlock(&filp->table_lock);
>>> +            return i;
>>> +        }
>>> +    }
>>
>> Please double check if that is still up to date.
>
> We may have to replace drm_gem_object_reference() with 
> drm_gem_object_get().
>
> On 2nd thought, do we really need to do reference every time?

Yes, that's a must have. Otherwise the handle could be freed and reused 
already when we return.

> if UMD find the same gem object for 3 times, it also need to 
> explicitly free(put) that object for 3 times?

Correct yes. Thinking more about this the real problem is to translate 
the handle into a structure in libdrm.

Here we are back to the problem Marek and Michel has been working on for 
a while that we always need to be able to translate a handle into a bo 
structure.....

So that needs to be solved before we can upstream the changes.

Regards,
Christian.

>
>
>>
>> I think we could as well try to use the DMA-buf handle tree for that.
>
> If the bo is not import/export, DMA-buf will be NULL always.
>
> Regards,
> Jerry
>>
>> Christian.
>>
>>> + spin_unlock(&filp->table_lock);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, 
>>> void *data,
>>> +                        struct drm_file *filp)
>>> +{
>>> +    union drm_amdgpu_gem_find_bo *args = data;
>>> +    struct drm_gem_object *gobj;
>>> +    struct amdgpu_bo *bo;
>>> +    struct ttm_buffer_object *tbo;
>>> +    struct vm_area_struct *vma;
>>> +    uint32_t handle;
>>> +    int r;
>>> +
>>> +    if (offset_in_page(args->in.addr | args->in.size))
>>> +        return -EINVAL;
>>> +
>>> +    down_read(&current->mm->mmap_sem);
>>> +    vma = find_vma(current->mm, args->in.addr);
>>> +    if (!vma || vma->vm_file != filp->filp ||
>>> +        (args->in.size > (vma->vm_end - args->in.addr))) {
>>> +        args->out.handle = 0;
>>> +        up_read(&current->mm->mmap_sem);
>>> +        return -EINVAL;
>>> +    }
>>> +    args->out.offset = args->in.addr - vma->vm_start;
>>> +
>>> +    tbo = vma->vm_private_data;
>>> +    bo = container_of(tbo, struct amdgpu_bo, tbo);
>>> +    amdgpu_bo_ref(bo);
>>> +    gobj = &bo->gem_base;
>>> +
>>> +    handle = amdgpu_gem_get_handle_from_object(filp, gobj);
>>> +    if (!handle) {
>>> +        r = drm_gem_handle_create(filp, gobj, &handle);
>>> +        if (r) {
>>> +            DRM_ERROR("create gem handle failed\n");
>>> +            up_read(&current->mm->mmap_sem);
>>> +            return r;
>>> +        }
>>> +    }
>>> +    args->out.handle = handle;
>>> +    up_read(&current->mm->mmap_sem);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>                    struct drm_file *filp)
>>>   {
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>> index 7956848..1bd2cc1 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct 
>>> drm_device *dev, unsigned int pipe)
>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
>>> DRM_AUTH|DRM_RENDER_ALLOW),
>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
>>> DRM_AUTH|DRM_RENDER_ALLOW),
>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, 
>>> amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>> -    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, 
>>> amdgpu_display_freesync_ioctl, DRM_MASTER)
>>> +    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, 
>>> amdgpu_display_freesync_ioctl, DRM_MASTER),
>>> +    DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, 
>>> amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>>>   };
>>>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>>> diff --git a/include/uapi/drm/amdgpu_drm.h 
>>> b/include/uapi/drm/amdgpu_drm.h
>>> index 94444ee..000c415 100644
>>> --- a/include/uapi/drm/amdgpu_drm.h
>>> +++ b/include/uapi/drm/amdgpu_drm.h
>>> @@ -54,6 +54,7 @@
>>>   #define DRM_AMDGPU_VM            0x13
>>>   #define DRM_AMDGPU_FENCE_TO_HANDLE    0x14
>>>   #define DRM_AMDGPU_SCHED        0x15
>>> +#define DRM_AMDGPU_GEM_FIND_BO        0x16
>>>   /* not upstream */
>>>   #define DRM_AMDGPU_FREESYNC            0x5d
>>> @@ -74,6 +75,7 @@
>>>   #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_FREESYNC DRM_IOWR(DRM_COMMAND_BASE + 
>>> DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>>> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE + 
>>> DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>>>   /**
>>>    * DOC: memory domains
>>> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>>>       struct drm_amdgpu_gem_wait_idle_out out;
>>>   };
>>> +struct drm_amdgpu_gem_find_bo_in {
>>> +    /* CPU address */
>>> +    __u64            addr;
>>> +    /* memory size from CPU address */
>>> +    __u64            size;
>>> +};
>>> +
>>> +struct drm_amdgpu_gem_find_bo_out {
>>> +    /* offset in bo */
>>> +    __u64            offset;
>>> +    /* resulting GEM handle */
>>> +    __u32            handle;
>>> +};
>>> +
>>> +union drm_amdgpu_gem_find_bo {
>>> +    struct drm_amdgpu_gem_find_bo_in in;
>>> +    struct drm_amdgpu_gem_find_bo_out out;
>>> +};
>>> +
>>>   struct drm_amdgpu_wait_cs_in {
>>>       /* Command submission handle
>>>            * handle equals 0 means none to wait for
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]             ` <c6b11c1f-b32a-4ab8-6a78-aa7886eed60a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-07-31  8:05               ` Zhang, Jerry (Junwei)
       [not found]                 ` <5B601844.3010405-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-07-31  8:05 UTC (permalink / raw)
  To: christian.koenig-5C7GfCeVMHo, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

On 07/31/2018 03:03 PM, Christian König wrote:
> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>> On 07/30/2018 06:47 PM, Christian König wrote:
>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>> From: Chunming Zhou <David1.Zhou@amd.com>
>>>>
>>>> v2: get original gem handle from gobj
>>>> v3: update find bo data structure as union(in, out)
>>>>      simply some code logic
>>>
>>> Do we now have an open source user for this, so that we can upstream it? One more point below.
>>>
>>>>
>>>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>>>> ---
>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>>>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>>>   4 files changed, 88 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> index 4cd20e7..46c370b 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>>>>                 struct drm_file *filp);
>>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>>               struct drm_file *filp);
>>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>>>> +                        struct drm_file *filp);
>>>>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>>>                 struct drm_file *filp);
>>>>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>> index 71792d8..bae8417 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>>>>       return 0;
>>>>   }
>>>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>>>> +                         struct drm_gem_object *obj)
>>>> +{
>>>> +    int i;
>>>> +    struct drm_gem_object *tmp;
>>>> +
>>>> +    spin_lock(&filp->table_lock);
>>>> +    idr_for_each_entry(&filp->object_idr, tmp, i) {
>>>> +        if (obj == tmp) {
>>>> +            drm_gem_object_reference(obj);
>>>> +            spin_unlock(&filp->table_lock);
>>>> +            return i;
>>>> +        }
>>>> +    }
>>>
>>> Please double check if that is still up to date.
>>
>> We may have to replace drm_gem_object_reference() with drm_gem_object_get().
>>
>> On 2nd thought, do we really need to do reference every time?
>
> Yes, that's a must have. Otherwise the handle could be freed and reused already when we return.
>
>> if UMD find the same gem object for 3 times, it also need to explicitly free(put) that object for 3 times?
>
> Correct yes. Thinking more about this the real problem is to translate the handle into a structure in libdrm.
>
> Here we are back to the problem Marek and Michel has been working on for a while that we always need to be able to translate a handle into a bo structure.....
>
> So that needs to be solved before we can upstream the changes.

Thanks for your info.
It's better to fix that before upstream.

Regards,
Jerry

>
> Regards,
> Christian.
>
>>
>>
>>>
>>> I think we could as well try to use the DMA-buf handle tree for that.
>>
>> If the bo is not import/export, DMA-buf will be NULL always.
>>
>> Regards,
>> Jerry
>>>
>>> Christian.
>>>
>>>> + spin_unlock(&filp->table_lock);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>>>> +                        struct drm_file *filp)
>>>> +{
>>>> +    union drm_amdgpu_gem_find_bo *args = data;
>>>> +    struct drm_gem_object *gobj;
>>>> +    struct amdgpu_bo *bo;
>>>> +    struct ttm_buffer_object *tbo;
>>>> +    struct vm_area_struct *vma;
>>>> +    uint32_t handle;
>>>> +    int r;
>>>> +
>>>> +    if (offset_in_page(args->in.addr | args->in.size))
>>>> +        return -EINVAL;
>>>> +
>>>> +    down_read(&current->mm->mmap_sem);
>>>> +    vma = find_vma(current->mm, args->in.addr);
>>>> +    if (!vma || vma->vm_file != filp->filp ||
>>>> +        (args->in.size > (vma->vm_end - args->in.addr))) {
>>>> +        args->out.handle = 0;
>>>> +        up_read(&current->mm->mmap_sem);
>>>> +        return -EINVAL;
>>>> +    }
>>>> +    args->out.offset = args->in.addr - vma->vm_start;
>>>> +
>>>> +    tbo = vma->vm_private_data;
>>>> +    bo = container_of(tbo, struct amdgpu_bo, tbo);
>>>> +    amdgpu_bo_ref(bo);
>>>> +    gobj = &bo->gem_base;
>>>> +
>>>> +    handle = amdgpu_gem_get_handle_from_object(filp, gobj);
>>>> +    if (!handle) {
>>>> +        r = drm_gem_handle_create(filp, gobj, &handle);
>>>> +        if (r) {
>>>> +            DRM_ERROR("create gem handle failed\n");
>>>> +            up_read(&current->mm->mmap_sem);
>>>> +            return r;
>>>> +        }
>>>> +    }
>>>> +    args->out.handle = handle;
>>>> +    up_read(&current->mm->mmap_sem);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>>                    struct drm_file *filp)
>>>>   {
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>>> index 7956848..1bd2cc1 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>>>> @@ -1100,7 +1100,8 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe)
>>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>>>       DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
>>>> -    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER)
>>>> +    DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl, DRM_MASTER),
>>>> +    DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, amdgpu_gem_find_bo_by_cpu_mapping_ioctl, DRM_AUTH|DRM_RENDER_ALLOW)
>>>>   };
>>>>   const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
>>>> diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
>>>> index 94444ee..000c415 100644
>>>> --- a/include/uapi/drm/amdgpu_drm.h
>>>> +++ b/include/uapi/drm/amdgpu_drm.h
>>>> @@ -54,6 +54,7 @@
>>>>   #define DRM_AMDGPU_VM            0x13
>>>>   #define DRM_AMDGPU_FENCE_TO_HANDLE    0x14
>>>>   #define DRM_AMDGPU_SCHED        0x15
>>>> +#define DRM_AMDGPU_GEM_FIND_BO        0x16
>>>>   /* not upstream */
>>>>   #define DRM_AMDGPU_FREESYNC            0x5d
>>>> @@ -74,6 +75,7 @@
>>>>   #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_FREESYNC DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
>>>> +#define DRM_IOCTL_AMDGPU_GEM_FIND_BO DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_FIND_BO, union drm_amdgpu_gem_find_bo)
>>>>   /**
>>>>    * DOC: memory domains
>>>> @@ -392,6 +394,25 @@ struct drm_amdgpu_gem_wait_idle_out {
>>>>       struct drm_amdgpu_gem_wait_idle_out out;
>>>>   };
>>>> +struct drm_amdgpu_gem_find_bo_in {
>>>> +    /* CPU address */
>>>> +    __u64            addr;
>>>> +    /* memory size from CPU address */
>>>> +    __u64            size;
>>>> +};
>>>> +
>>>> +struct drm_amdgpu_gem_find_bo_out {
>>>> +    /* offset in bo */
>>>> +    __u64            offset;
>>>> +    /* resulting GEM handle */
>>>> +    __u32            handle;
>>>> +};
>>>> +
>>>> +union drm_amdgpu_gem_find_bo {
>>>> +    struct drm_amdgpu_gem_find_bo_in in;
>>>> +    struct drm_amdgpu_gem_find_bo_out out;
>>>> +};
>>>> +
>>>>   struct drm_amdgpu_wait_cs_in {
>>>>       /* Command submission handle
>>>>            * handle equals 0 means none to wait for
>>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                 ` <5B601844.3010405-5C7GfCeVMHo@public.gmane.org>
@ 2018-07-31  8:13                   ` Christian König
       [not found]                     ` <5e8f2a76-6cbd-1f80-ec94-fcd79c0fa55c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-07-31  8:13 UTC (permalink / raw)
  To: Zhang, Jerry (Junwei),
	christian.koenig-5C7GfCeVMHo,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
> On 07/31/2018 03:03 PM, Christian König wrote:
>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>> From: Chunming Zhou <David1.Zhou@amd.com>
>>>>>
>>>>> v2: get original gem handle from gobj
>>>>> v3: update find bo data structure as union(in, out)
>>>>>      simply some code logic
>>>>
>>>> Do we now have an open source user for this, so that we can 
>>>> upstream it? One more point below.
>>>>
>>>>>
>>>>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>>>>> ---
>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 
>>>>> +++++++++++++++++++++++++++++++++
>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>>>>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>>>>   4 files changed, 88 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>> index 4cd20e7..46c370b 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device 
>>>>> *dev, void *data,
>>>>>                 struct drm_file *filp);
>>>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>>>               struct drm_file *filp);
>>>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device 
>>>>> *dev, void *data,
>>>>> +                        struct drm_file *filp);
>>>>>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>>>>                 struct drm_file *filp);
>>>>>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>> index 71792d8..bae8417 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device 
>>>>> *dev, void *data,
>>>>>       return 0;
>>>>>   }
>>>>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>>>>> +                         struct drm_gem_object *obj)
>>>>> +{
>>>>> +    int i;
>>>>> +    struct drm_gem_object *tmp;
>>>>> +
>>>>> +    spin_lock(&filp->table_lock);
>>>>> +    idr_for_each_entry(&filp->object_idr, tmp, i) {
>>>>> +        if (obj == tmp) {
>>>>> +            drm_gem_object_reference(obj);
>>>>> +            spin_unlock(&filp->table_lock);
>>>>> +            return i;
>>>>> +        }
>>>>> +    }
>>>>
>>>> Please double check if that is still up to date.
>>>
>>> We may have to replace drm_gem_object_reference() with 
>>> drm_gem_object_get().
>>>
>>> On 2nd thought, do we really need to do reference every time?
>>
>> Yes, that's a must have. Otherwise the handle could be freed and 
>> reused already when we return.
>>
>>> if UMD find the same gem object for 3 times, it also need to 
>>> explicitly free(put) that object for 3 times?
>>
>> Correct yes. Thinking more about this the real problem is to 
>> translate the handle into a structure in libdrm.
>>
>> Here we are back to the problem Marek and Michel has been working on 
>> for a while that we always need to be able to translate a handle into 
>> a bo structure.....
>>
>> So that needs to be solved before we can upstream the changes.
>
> Thanks for your info.
> It's better to fix that before upstream.

Thinking more about this the hash currently used in libdrm is not 
adequate any more.

E.g. we now need to be able to find all BOs based on their handle. Since 
the handles are dense either an r/b tree or a radix tree now sounds like 
the best approach to me.

Christian.

>
> Regards,
> Jerry

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                     ` <5e8f2a76-6cbd-1f80-ec94-fcd79c0fa55c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-07-31  8:58                       ` Zhang, Jerry (Junwei)
       [not found]                         ` <5B60249D.7030503-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-07-31  8:58 UTC (permalink / raw)
  To: christian.koenig-5C7GfCeVMHo, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

On 07/31/2018 04:13 PM, Christian König wrote:
> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>> On 07/31/2018 03:03 PM, Christian König wrote:
>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>> From: Chunming Zhou <David1.Zhou@amd.com>
>>>>>>
>>>>>> v2: get original gem handle from gobj
>>>>>> v3: update find bo data structure as union(in, out)
>>>>>>      simply some code logic
>>>>>
>>>>> Do we now have an open source user for this, so that we can upstream it? One more point below.
>>>>>
>>>>>>
>>>>>> Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
>>>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v3)
>>>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>>> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
>>>>>> ---
>>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h     |  2 ++
>>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 63 +++++++++++++++++++++++++++++++++
>>>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +-
>>>>>>   include/uapi/drm/amdgpu_drm.h           | 21 +++++++++++
>>>>>>   4 files changed, 88 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>> index 4cd20e7..46c370b 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>> @@ -1213,6 +1213,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void *data,
>>>>>>                 struct drm_file *filp);
>>>>>>   int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
>>>>>>               struct drm_file *filp);
>>>>>> +int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
>>>>>> +                        struct drm_file *filp);
>>>>>>   int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
>>>>>>                 struct drm_file *filp);
>>>>>>   int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>>> index 71792d8..bae8417 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>>>>> @@ -288,6 +288,69 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data,
>>>>>>       return 0;
>>>>>>   }
>>>>>> +static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
>>>>>> +                         struct drm_gem_object *obj)
>>>>>> +{
>>>>>> +    int i;
>>>>>> +    struct drm_gem_object *tmp;
>>>>>> +
>>>>>> +    spin_lock(&filp->table_lock);
>>>>>> +    idr_for_each_entry(&filp->object_idr, tmp, i) {
>>>>>> +        if (obj == tmp) {
>>>>>> +            drm_gem_object_reference(obj);
>>>>>> +            spin_unlock(&filp->table_lock);
>>>>>> +            return i;
>>>>>> +        }
>>>>>> +    }
>>>>>
>>>>> Please double check if that is still up to date.
>>>>
>>>> We may have to replace drm_gem_object_reference() with drm_gem_object_get().
>>>>
>>>> On 2nd thought, do we really need to do reference every time?
>>>
>>> Yes, that's a must have. Otherwise the handle could be freed and reused already when we return.
>>>
>>>> if UMD find the same gem object for 3 times, it also need to explicitly free(put) that object for 3 times?
>>>
>>> Correct yes. Thinking more about this the real problem is to translate the handle into a structure in libdrm.
>>>
>>> Here we are back to the problem Marek and Michel has been working on for a while that we always need to be able to translate a handle into a bo structure.....
>>>
>>> So that needs to be solved before we can upstream the changes.
>>
>> Thanks for your info.
>> It's better to fix that before upstream.
>
> Thinking more about this the hash currently used in libdrm is not adequate any more.
>
> E.g. we now need to be able to find all BOs based on their handle. Since the handles are dense either an r/b tree or a radix tree now sounds like the best approach to me.

Not sure the exact reason that we added hash table in libdrm.
But it really costs much less time than calling IOCTL to find BO by their handles.

In this case, UMD seems not to be able to get BO handle and try to verify it by cpu address then.
In another word, UMD would like to find if the memory is created as BO or system memory, I suppose.

Regards,
Jerry


>
> Christian.
>
>>
>> Regards,
>> Jerry
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                         ` <5B60249D.7030503-5C7GfCeVMHo@public.gmane.org>
@ 2018-07-31  9:04                           ` Christian König
       [not found]                             ` <9dc68d5d-561c-242a-b3ba-1c8078ab670f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-07-31  9:04 UTC (permalink / raw)
  To: Zhang, Jerry (Junwei),
	christian.koenig-5C7GfCeVMHo,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

Am 31.07.2018 um 10:58 schrieb Zhang, Jerry (Junwei):
> On 07/31/2018 04:13 PM, Christian König wrote:
>> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>>> On 07/31/2018 03:03 PM, Christian König wrote:
>>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>> [SNIP]
>>>>>> Please double check if that is still up to date.
>>>>>
>>>>> We may have to replace drm_gem_object_reference() with 
>>>>> drm_gem_object_get().
>>>>>
>>>>> On 2nd thought, do we really need to do reference every time?
>>>>
>>>> Yes, that's a must have. Otherwise the handle could be freed and 
>>>> reused already when we return.
>>>>
>>>>> if UMD find the same gem object for 3 times, it also need to 
>>>>> explicitly free(put) that object for 3 times?
>>>>
>>>> Correct yes. Thinking more about this the real problem is to 
>>>> translate the handle into a structure in libdrm.
>>>>
>>>> Here we are back to the problem Marek and Michel has been working 
>>>> on for a while that we always need to be able to translate a handle 
>>>> into a bo structure.....
>>>>
>>>> So that needs to be solved before we can upstream the changes.
>>>
>>> Thanks for your info.
>>> It's better to fix that before upstream.
>>
>> Thinking more about this the hash currently used in libdrm is not 
>> adequate any more.
>>
>> E.g. we now need to be able to find all BOs based on their handle. 
>> Since the handles are dense either an r/b tree or a radix tree now 
>> sounds like the best approach to me.
>
> Not sure the exact reason that we added hash table in libdrm.

The reason for that was that when a kernel function returns a handle we 
need to make sure that we always use the same struct amdgpu_bo for it.

Otherwise you run into quite some problems with syncing etc...

> But it really costs much less time than calling IOCTL to find BO by 
> their handles.

Well we could just completely drop the kernel implementation and use an 
userspace implementation.

And yes I agree when we need a tree anyway it would probably be faster 
than calling the IOCTL to find the BO.

Christian.

>
> In this case, UMD seems not to be able to get BO handle and try to 
> verify it by cpu address then.
> In another word, UMD would like to find if the memory is created as BO 
> or system memory, I suppose.
>
> Regards,
> Jerry
>
>
>>
>> Christian.
>>
>>>
>>> Regards,
>>> Jerry
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                             ` <9dc68d5d-561c-242a-b3ba-1c8078ab670f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-07-31  9:54                               ` Zhang, Jerry (Junwei)
       [not found]                                 ` <5B6031CA.4050102-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-07-31  9:54 UTC (permalink / raw)
  To: christian.koenig-5C7GfCeVMHo, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

On 07/31/2018 05:04 PM, Christian König wrote:
> Am 31.07.2018 um 10:58 schrieb Zhang, Jerry (Junwei):
>> On 07/31/2018 04:13 PM, Christian König wrote:
>>> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>>>> On 07/31/2018 03:03 PM, Christian König wrote:
>>>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>>> [SNIP]
>>>>>>> Please double check if that is still up to date.
>>>>>>
>>>>>> We may have to replace drm_gem_object_reference() with drm_gem_object_get().
>>>>>>
>>>>>> On 2nd thought, do we really need to do reference every time?
>>>>>
>>>>> Yes, that's a must have. Otherwise the handle could be freed and reused already when we return.
>>>>>
>>>>>> if UMD find the same gem object for 3 times, it also need to explicitly free(put) that object for 3 times?
>>>>>
>>>>> Correct yes. Thinking more about this the real problem is to translate the handle into a structure in libdrm.
>>>>>
>>>>> Here we are back to the problem Marek and Michel has been working on for a while that we always need to be able to translate a handle into a bo structure.....
>>>>>
>>>>> So that needs to be solved before we can upstream the changes.
>>>>
>>>> Thanks for your info.
>>>> It's better to fix that before upstream.
>>>
>>> Thinking more about this the hash currently used in libdrm is not adequate any more.
>>>
>>> E.g. we now need to be able to find all BOs based on their handle. Since the handles are dense either an r/b tree or a radix tree now sounds like the best approach to me.
>>
>> Not sure the exact reason that we added hash table in libdrm.
>
> The reason for that was that when a kernel function returns a handle we need to make sure that we always use the same struct amdgpu_bo for it.
>
> Otherwise you run into quite some problems with syncing etc...

Thanks for your explanation.

>
>> But it really costs much less time than calling IOCTL to find BO by their handles.
>
> Well we could just completely drop the kernel implementation and use an userspace implementation.

Do you mean to implement finding bo by cpu address in libdrm completely?
e.g. to create a tree to manage bo handle in libdrm?

Jerry

>
> And yes I agree when we need a tree anyway it would probably be faster than calling the IOCTL to find the BO.
>
> Christian.
>
>>
>> In this case, UMD seems not to be able to get BO handle and try to verify it by cpu address then.
>> In another word, UMD would like to find if the memory is created as BO or system memory, I suppose.
>>
>> Regards,
>> Jerry
>>
>>
>>>
>>> Christian.
>>>
>>>>
>>>> Regards,
>>>> Jerry
>>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                 ` <5B6031CA.4050102-5C7GfCeVMHo@public.gmane.org>
@ 2018-07-31 10:13                                   ` Christian König
       [not found]                                     ` <3ffb8b8c-fae3-92d9-80e1-bd7d0498b4c7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-07-31 10:13 UTC (permalink / raw)
  To: Zhang, Jerry (Junwei),
	christian.koenig-5C7GfCeVMHo,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: Chunming Zhou

Am 31.07.2018 um 11:54 schrieb Zhang, Jerry (Junwei):
> On 07/31/2018 05:04 PM, Christian König wrote:
>> Am 31.07.2018 um 10:58 schrieb Zhang, Jerry (Junwei):
>>> On 07/31/2018 04:13 PM, Christian König wrote:
>>>> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>>>>> On 07/31/2018 03:03 PM, Christian König wrote:
>>>>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>>>> [SNIP]
>>>>>>>> Please double check if that is still up to date.
>>>>>>>
>>>>>>> We may have to replace drm_gem_object_reference() with 
>>>>>>> drm_gem_object_get().
>>>>>>>
>>>>>>> On 2nd thought, do we really need to do reference every time?
>>>>>>
>>>>>> Yes, that's a must have. Otherwise the handle could be freed and 
>>>>>> reused already when we return.
>>>>>>
>>>>>>> if UMD find the same gem object for 3 times, it also need to 
>>>>>>> explicitly free(put) that object for 3 times?
>>>>>>
>>>>>> Correct yes. Thinking more about this the real problem is to 
>>>>>> translate the handle into a structure in libdrm.
>>>>>>
>>>>>> Here we are back to the problem Marek and Michel has been working 
>>>>>> on for a while that we always need to be able to translate a 
>>>>>> handle into a bo structure.....
>>>>>>
>>>>>> So that needs to be solved before we can upstream the changes.
>>>>>
>>>>> Thanks for your info.
>>>>> It's better to fix that before upstream.
>>>>
>>>> Thinking more about this the hash currently used in libdrm is not 
>>>> adequate any more.
>>>>
>>>> E.g. we now need to be able to find all BOs based on their handle. 
>>>> Since the handles are dense either an r/b tree or a radix tree now 
>>>> sounds like the best approach to me.
>>>
>>> Not sure the exact reason that we added hash table in libdrm.
>>
>> The reason for that was that when a kernel function returns a handle 
>> we need to make sure that we always use the same struct amdgpu_bo for 
>> it.
>>
>> Otherwise you run into quite some problems with syncing etc...
>
> Thanks for your explanation.
>
>>
>>> But it really costs much less time than calling IOCTL to find BO by 
>>> their handles.
>>
>> Well we could just completely drop the kernel implementation and use 
>> an userspace implementation.
>
> Do you mean to implement finding bo by cpu address in libdrm completely?

Yes, exactly.

> e.g. to create a tree to manage bo handle in libdrm?

I mean when we need to create a tree to map the handle to a BO you could 
also create a tree to map the CPU pointer to the BO directly and avoid 
the IOCTL overhead completely.

Christian.

>
> Jerry
>
>>
>> And yes I agree when we need a tree anyway it would probably be 
>> faster than calling the IOCTL to find the BO.
>>
>> Christian.
>>
>>>
>>> In this case, UMD seems not to be able to get BO handle and try to 
>>> verify it by cpu address then.
>>> In another word, UMD would like to find if the memory is created as 
>>> BO or system memory, I suppose.
>>>
>>> Regards,
>>> Jerry
>>>
>>>
>>>>
>>>> Christian.
>>>>
>>>>>
>>>>> Regards,
>>>>> Jerry
>>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                     ` <3ffb8b8c-fae3-92d9-80e1-bd7d0498b4c7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-07-31 22:07                                       ` Marek Olšák
       [not found]                                         ` <CAAxE2A6uLe_ZMTGQ2dqFbY--Mf15qRrP+tX6pbicokpe8Wo=qQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Marek Olšák @ 2018-07-31 22:07 UTC (permalink / raw)
  To: Christian König
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

Can this be implemented as a wrapper on top of libdrm? So that the
tree (or hash table) isn't created for UMDs that don't need it.

Marek

On Tue, Jul 31, 2018 at 6:13 AM, Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
> Am 31.07.2018 um 11:54 schrieb Zhang, Jerry (Junwei):
>>
>> On 07/31/2018 05:04 PM, Christian König wrote:
>>>
>>> Am 31.07.2018 um 10:58 schrieb Zhang, Jerry (Junwei):
>>>>
>>>> On 07/31/2018 04:13 PM, Christian König wrote:
>>>>>
>>>>> Am 31.07.2018 um 10:05 schrieb Zhang, Jerry (Junwei):
>>>>>>
>>>>>> On 07/31/2018 03:03 PM, Christian König wrote:
>>>>>>>
>>>>>>> Am 31.07.2018 um 08:58 schrieb Zhang, Jerry (Junwei):
>>>>>>>>
>>>>>>>> On 07/30/2018 06:47 PM, Christian König wrote:
>>>>>>>>>
>>>>>>>>> Am 30.07.2018 um 12:02 schrieb Junwei Zhang:
>>>>>>>>> [SNIP]
>>>>>>>>> Please double check if that is still up to date.
>>>>>>>>
>>>>>>>>
>>>>>>>> We may have to replace drm_gem_object_reference() with
>>>>>>>> drm_gem_object_get().
>>>>>>>>
>>>>>>>> On 2nd thought, do we really need to do reference every time?
>>>>>>>
>>>>>>>
>>>>>>> Yes, that's a must have. Otherwise the handle could be freed and
>>>>>>> reused already when we return.
>>>>>>>
>>>>>>>> if UMD find the same gem object for 3 times, it also need to
>>>>>>>> explicitly free(put) that object for 3 times?
>>>>>>>
>>>>>>>
>>>>>>> Correct yes. Thinking more about this the real problem is to
>>>>>>> translate the handle into a structure in libdrm.
>>>>>>>
>>>>>>> Here we are back to the problem Marek and Michel has been working on
>>>>>>> for a while that we always need to be able to translate a handle into a bo
>>>>>>> structure.....
>>>>>>>
>>>>>>> So that needs to be solved before we can upstream the changes.
>>>>>>
>>>>>>
>>>>>> Thanks for your info.
>>>>>> It's better to fix that before upstream.
>>>>>
>>>>>
>>>>> Thinking more about this the hash currently used in libdrm is not
>>>>> adequate any more.
>>>>>
>>>>> E.g. we now need to be able to find all BOs based on their handle.
>>>>> Since the handles are dense either an r/b tree or a radix tree now sounds
>>>>> like the best approach to me.
>>>>
>>>>
>>>> Not sure the exact reason that we added hash table in libdrm.
>>>
>>>
>>> The reason for that was that when a kernel function returns a handle we
>>> need to make sure that we always use the same struct amdgpu_bo for it.
>>>
>>> Otherwise you run into quite some problems with syncing etc...
>>
>>
>> Thanks for your explanation.
>>
>>>
>>>> But it really costs much less time than calling IOCTL to find BO by
>>>> their handles.
>>>
>>>
>>> Well we could just completely drop the kernel implementation and use an
>>> userspace implementation.
>>
>>
>> Do you mean to implement finding bo by cpu address in libdrm completely?
>
>
> Yes, exactly.
>
>> e.g. to create a tree to manage bo handle in libdrm?
>
>
> I mean when we need to create a tree to map the handle to a BO you could
> also create a tree to map the CPU pointer to the BO directly and avoid the
> IOCTL overhead completely.
>
> Christian.
>
>
>>
>> Jerry
>>
>>>
>>> And yes I agree when we need a tree anyway it would probably be faster
>>> than calling the IOCTL to find the BO.
>>>
>>> Christian.
>>>
>>>>
>>>> In this case, UMD seems not to be able to get BO handle and try to
>>>> verify it by cpu address then.
>>>> In another word, UMD would like to find if the memory is created as BO
>>>> or system memory, I suppose.
>>>>
>>>> Regards,
>>>> Jerry
>>>>
>>>>
>>>>>
>>>>> Christian.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Jerry
>>>>>
>>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
>>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                         ` <CAAxE2A6uLe_ZMTGQ2dqFbY--Mf15qRrP+tX6pbicokpe8Wo=qQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2018-08-01  6:32                                           ` Christian König
       [not found]                                             ` <53eb686a-0747-394a-b0c3-4cd53ab836e2-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-08-01  6:32 UTC (permalink / raw)
  To: Marek Olšák
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

Am 01.08.2018 um 00:07 schrieb Marek Olšák:
> Can this be implemented as a wrapper on top of libdrm? So that the
> tree (or hash table) isn't created for UMDs that don't need it.

No, the problem is that an application gets a CPU pointer from one API 
and tries to import that pointer into another one.

In other words we need to implement this independent of the UMD who 
mapped the BO.

Christian.

>
> Marek
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                             ` <53eb686a-0747-394a-b0c3-4cd53ab836e2-5C7GfCeVMHo@public.gmane.org>
@ 2018-08-01 17:39                                               ` Marek Olšák
       [not found]                                                 ` <CAAxE2A6C0mmr2vogcAQL+XNQuPU=BqHUGjqAMVnS3pK37XJa0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Marek Olšák @ 2018-08-01 17:39 UTC (permalink / raw)
  To: Christian König
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

On Wed, Aug 1, 2018 at 2:32 AM, Christian König
<christian.koenig@amd.com> wrote:
> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>
>> Can this be implemented as a wrapper on top of libdrm? So that the
>> tree (or hash table) isn't created for UMDs that don't need it.
>
>
> No, the problem is that an application gets a CPU pointer from one API and
> tries to import that pointer into another one.
>
> In other words we need to implement this independent of the UMD who mapped
> the BO.

Yeah, it could be an optional feature of libdrm, and other components
should be able to disable it to remove the overhead.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                 ` <CAAxE2A6C0mmr2vogcAQL+XNQuPU=BqHUGjqAMVnS3pK37XJa0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2018-08-01 17:52                                                   ` Christian König
       [not found]                                                     ` <edbcf817-75ea-6e6a-d64a-6274a78308e7-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-08-01 17:52 UTC (permalink / raw)
  To: Marek Olšák
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

Am 01.08.2018 um 19:39 schrieb Marek Olšák:
> On Wed, Aug 1, 2018 at 2:32 AM, Christian König
> <christian.koenig@amd.com> wrote:
>> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>> Can this be implemented as a wrapper on top of libdrm? So that the
>>> tree (or hash table) isn't created for UMDs that don't need it.
>>
>> No, the problem is that an application gets a CPU pointer from one API and
>> tries to import that pointer into another one.
>>
>> In other words we need to implement this independent of the UMD who mapped
>> the BO.
> Yeah, it could be an optional feature of libdrm, and other components
> should be able to disable it to remove the overhead.

The overhead is negligible, the real problem is the memory footprint.

A brief look at the hash implementation in libdrm showed that this is 
actually really inefficient.

I think we have the choice of implementing a r/b tree to map the CPU 
pointer addresses or implement a quadratic tree to map the handles.

The later is easy to do and would also allow to get rid of the hash 
table as well.

Christian.

>
> Marek

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                     ` <edbcf817-75ea-6e6a-d64a-6274a78308e7-5C7GfCeVMHo@public.gmane.org>
@ 2018-08-01 17:59                                                       ` Marek Olšák
       [not found]                                                         ` <CAAxE2A4=k5_20jaPcM9awxQ69MhXY2wtEX9NFxZU9=43_SsRug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Marek Olšák @ 2018-08-01 17:59 UTC (permalink / raw)
  To: Christian König
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

On Wed, Aug 1, 2018 at 1:52 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 01.08.2018 um 19:39 schrieb Marek Olšák:
>>
>> On Wed, Aug 1, 2018 at 2:32 AM, Christian König
>> <christian.koenig@amd.com> wrote:
>>>
>>> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>>>
>>>> Can this be implemented as a wrapper on top of libdrm? So that the
>>>> tree (or hash table) isn't created for UMDs that don't need it.
>>>
>>>
>>> No, the problem is that an application gets a CPU pointer from one API
>>> and
>>> tries to import that pointer into another one.
>>>
>>> In other words we need to implement this independent of the UMD who
>>> mapped
>>> the BO.
>>
>> Yeah, it could be an optional feature of libdrm, and other components
>> should be able to disable it to remove the overhead.
>
>
> The overhead is negligible, the real problem is the memory footprint.
>
> A brief look at the hash implementation in libdrm showed that this is
> actually really inefficient.
>
> I think we have the choice of implementing a r/b tree to map the CPU pointer
> addresses or implement a quadratic tree to map the handles.
>
> The later is easy to do and would also allow to get rid of the hash table as
> well.

We can also use the hash table from mesa/src/util.

I don't think the overhead would be negligible. It would be a log(n)
insertion in bo_map and a log(n) deletion in bo_unmap. If you did
bo_map+bo_unmap 10000 times, would it be negligible?

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                         ` <CAAxE2A4=k5_20jaPcM9awxQ69MhXY2wtEX9NFxZU9=43_SsRug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2018-08-01 18:29                                                           ` Christian König
       [not found]                                                             ` <ba1798f5-9aa9-6d55-791a-b2fd52087ea7-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2018-08-01 18:29 UTC (permalink / raw)
  To: Marek Olšák
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

Am 01.08.2018 um 19:59 schrieb Marek Olšák:
> On Wed, Aug 1, 2018 at 1:52 PM, Christian König
> <christian.koenig@amd.com> wrote:
>> Am 01.08.2018 um 19:39 schrieb Marek Olšák:
>>> On Wed, Aug 1, 2018 at 2:32 AM, Christian König
>>> <christian.koenig@amd.com> wrote:
>>>> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>>>> Can this be implemented as a wrapper on top of libdrm? So that the
>>>>> tree (or hash table) isn't created for UMDs that don't need it.
>>>>
>>>> No, the problem is that an application gets a CPU pointer from one API
>>>> and
>>>> tries to import that pointer into another one.
>>>>
>>>> In other words we need to implement this independent of the UMD who
>>>> mapped
>>>> the BO.
>>> Yeah, it could be an optional feature of libdrm, and other components
>>> should be able to disable it to remove the overhead.
>>
>> The overhead is negligible, the real problem is the memory footprint.
>>
>> A brief look at the hash implementation in libdrm showed that this is
>> actually really inefficient.
>>
>> I think we have the choice of implementing a r/b tree to map the CPU pointer
>> addresses or implement a quadratic tree to map the handles.
>>
>> The later is easy to do and would also allow to get rid of the hash table as
>> well.
> We can also use the hash table from mesa/src/util.
>
> I don't think the overhead would be negligible. It would be a log(n)
> insertion in bo_map and a log(n) deletion in bo_unmap. If you did
> bo_map+bo_unmap 10000 times, would it be negligible?

Compared to what the kernel needs to do for updating the page tables it 
is less than 1% of the total work.

The real question is if it wouldn't be simpler to use a tree for the 
handles. Since the handles are dense you can just use an unbalanced tree 
which is really easy.

For a tree of the CPU mappings we would need an r/b interval tree, which 
is hard to implement and quite some overkill.

Do you have any numbers how many BOs really get a CPU mapping in a real 
world application?

Christian.

>
> Marek

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                             ` <ba1798f5-9aa9-6d55-791a-b2fd52087ea7-5C7GfCeVMHo@public.gmane.org>
@ 2018-08-02  0:00                                                               ` Marek Olšák
       [not found]                                                                 ` <CAAxE2A4bma0u8R+ggETPoUycC=MTkrs0oUGJFW8kGx__Sf35eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Marek Olšák @ 2018-08-02  0:00 UTC (permalink / raw)
  To: Christian König
  Cc: Zhang, Jerry (Junwei), Chunming Zhou, amd-gfx mailing list

On Wed, Aug 1, 2018 at 2:29 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 01.08.2018 um 19:59 schrieb Marek Olšák:
>>
>> On Wed, Aug 1, 2018 at 1:52 PM, Christian König
>> <christian.koenig@amd.com> wrote:
>>>
>>> Am 01.08.2018 um 19:39 schrieb Marek Olšák:
>>>>
>>>> On Wed, Aug 1, 2018 at 2:32 AM, Christian König
>>>> <christian.koenig@amd.com> wrote:
>>>>>
>>>>> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>>>>>
>>>>>> Can this be implemented as a wrapper on top of libdrm? So that the
>>>>>> tree (or hash table) isn't created for UMDs that don't need it.
>>>>>
>>>>>
>>>>> No, the problem is that an application gets a CPU pointer from one API
>>>>> and
>>>>> tries to import that pointer into another one.
>>>>>
>>>>> In other words we need to implement this independent of the UMD who
>>>>> mapped
>>>>> the BO.
>>>>
>>>> Yeah, it could be an optional feature of libdrm, and other components
>>>> should be able to disable it to remove the overhead.
>>>
>>>
>>> The overhead is negligible, the real problem is the memory footprint.
>>>
>>> A brief look at the hash implementation in libdrm showed that this is
>>> actually really inefficient.
>>>
>>> I think we have the choice of implementing a r/b tree to map the CPU
>>> pointer
>>> addresses or implement a quadratic tree to map the handles.
>>>
>>> The later is easy to do and would also allow to get rid of the hash table
>>> as
>>> well.
>>
>> We can also use the hash table from mesa/src/util.
>>
>> I don't think the overhead would be negligible. It would be a log(n)
>> insertion in bo_map and a log(n) deletion in bo_unmap. If you did
>> bo_map+bo_unmap 10000 times, would it be negligible?
>
>
> Compared to what the kernel needs to do for updating the page tables it is
> less than 1% of the total work.
>
> The real question is if it wouldn't be simpler to use a tree for the
> handles. Since the handles are dense you can just use an unbalanced tree
> which is really easy.
>
> For a tree of the CPU mappings we would need an r/b interval tree, which is
> hard to implement and quite some overkill.
>
> Do you have any numbers how many BOs really get a CPU mapping in a real
> world application?

Without our suballocator, we sometimes exceeded the max. mmap limit
(~64K). It should be much less with the suballocator with 128KB slabs,
probably a few thousands.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                                 ` <CAAxE2A4bma0u8R+ggETPoUycC=MTkrs0oUGJFW8kGx__Sf35eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2018-08-02  6:20                                                                   ` Zhang, Jerry (Junwei)
       [not found]                                                                     ` <5B62A2A0.5060508-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Jerry (Junwei) @ 2018-08-02  6:20 UTC (permalink / raw)
  To: Marek Olšák, Christian König
  Cc: Chunming Zhou, amd-gfx mailing list

On 08/02/2018 08:00 AM, Marek Olšák wrote:
> On Wed, Aug 1, 2018 at 2:29 PM, Christian König
> <christian.koenig@amd.com> wrote:
>> Am 01.08.2018 um 19:59 schrieb Marek Olšák:
>>>
>>> On Wed, Aug 1, 2018 at 1:52 PM, Christian König
>>> <christian.koenig@amd.com> wrote:
>>>>
>>>> Am 01.08.2018 um 19:39 schrieb Marek Olšák:
>>>>>
>>>>> On Wed, Aug 1, 2018 at 2:32 AM, Christian König
>>>>> <christian.koenig@amd.com> wrote:
>>>>>>
>>>>>> Am 01.08.2018 um 00:07 schrieb Marek Olšák:
>>>>>>>
>>>>>>> Can this be implemented as a wrapper on top of libdrm? So that the
>>>>>>> tree (or hash table) isn't created for UMDs that don't need it.
>>>>>>
>>>>>>
>>>>>> No, the problem is that an application gets a CPU pointer from one API
>>>>>> and
>>>>>> tries to import that pointer into another one.
>>>>>>
>>>>>> In other words we need to implement this independent of the UMD who
>>>>>> mapped
>>>>>> the BO.
>>>>>
>>>>> Yeah, it could be an optional feature of libdrm, and other components
>>>>> should be able to disable it to remove the overhead.
>>>>
>>>>
>>>> The overhead is negligible, the real problem is the memory footprint.
>>>>
>>>> A brief look at the hash implementation in libdrm showed that this is
>>>> actually really inefficient.
>>>>
>>>> I think we have the choice of implementing a r/b tree to map the CPU
>>>> pointer
>>>> addresses or implement a quadratic tree to map the handles.
>>>>
>>>> The later is easy to do and would also allow to get rid of the hash table
>>>> as
>>>> well.
>>>
>>> We can also use the hash table from mesa/src/util.
>>>
>>> I don't think the overhead would be negligible. It would be a log(n)
>>> insertion in bo_map and a log(n) deletion in bo_unmap. If you did
>>> bo_map+bo_unmap 10000 times, would it be negligible?
>>
>>
>> Compared to what the kernel needs to do for updating the page tables it is
>> less than 1% of the total work.
>>
>> The real question is if it wouldn't be simpler to use a tree for the
>> handles. Since the handles are dense you can just use an unbalanced tree
>> which is really easy.
>>
>> For a tree of the CPU mappings we would need an r/b interval tree, which is
>> hard to implement and quite some overkill.
>>
>> Do you have any numbers how many BOs really get a CPU mapping in a real
>> world application?
>
> Without our suballocator, we sometimes exceeded the max. mmap limit
> (~64K). It should be much less with the suballocator with 128KB slabs,
> probably a few thousands.

Is there a way to verify that it has performance issue if moving the cpu mapping in libdrm hash table
from kernel side?

AFAIW, only one game will use that with close OGL.

Regards,
Jerry

>
> Marek
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)
       [not found]                                                                     ` <5B62A2A0.5060508-5C7GfCeVMHo@public.gmane.org>
@ 2018-08-02  6:29                                                                       ` Christian König
  0 siblings, 0 replies; 24+ messages in thread
From: Christian König @ 2018-08-02  6:29 UTC (permalink / raw)
  To: Zhang, Jerry (Junwei), Marek Olšák
  Cc: Chunming Zhou, amd-gfx mailing list

Am 02.08.2018 um 08:20 schrieb Zhang, Jerry (Junwei):
> On 08/02/2018 08:00 AM, Marek Olšák wrote:
>> On Wed, Aug 1, 2018 at 2:29 PM, Christian König
>> <christian.koenig@amd.com> wrote:
>>> Am 01.08.2018 um 19:59 schrieb Marek Olšák:
>>>> [SNIP]
>>>
>>> Compared to what the kernel needs to do for updating the page tables 
>>> it is
>>> less than 1% of the total work.
>>>
>>> The real question is if it wouldn't be simpler to use a tree for the
>>> handles. Since the handles are dense you can just use an unbalanced 
>>> tree
>>> which is really easy.
>>>
>>> For a tree of the CPU mappings we would need an r/b interval tree, 
>>> which is
>>> hard to implement and quite some overkill.
>>>
>>> Do you have any numbers how many BOs really get a CPU mapping in a real
>>> world application?
>>
>> Without our suballocator, we sometimes exceeded the max. mmap limit
>> (~64K). It should be much less with the suballocator with 128KB slabs,
>> probably a few thousands.
>
> Is there a way to verify that it has performance issue if moving the 
> cpu mapping in libdrm hash table
> from kernel side?

Going to take a look at this, but I have the feeling that the CPU 
overhead we need to add in userspace isn't that much.

>
> AFAIW, only one game will use that with close OGL.

Well, I would also say that this is a bug in the game and should be 
fixed there.

Christian.

>
> Regards,
> Jerry
>
>>
>> Marek
>>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2018-08-02  6:29 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-30 10:02 [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3) Junwei Zhang
     [not found] ` <1532944950-28619-1-git-send-email-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
2018-07-30 10:02   ` [PATCH 2/2] drm/amdgpu: bump version for API to find bo by cpu mapping Junwei Zhang
2018-07-30 10:47   ` [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3) Christian König
     [not found]     ` <3d423f44-e47a-e70c-dfd9-80c1ff843e45-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-31  1:40       ` Zhou, David(ChunMing)
     [not found]         ` <SN1PR12MB051036BA7AC3560A4FAC68A1B42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-07-31  1:49           ` Zhou, David(ChunMing)
     [not found]             ` <SN1PR12MB05106FBFF052EDFD49193ABCB42E0-z7L1TMIYDg5tVDmkcP8tDwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-07-31  2:32               ` Zhang, Jerry (Junwei)
2018-07-31  6:54           ` Christian König
2018-07-31  6:58       ` Zhang, Jerry (Junwei)
     [not found]         ` <5B6008A1.5050401-5C7GfCeVMHo@public.gmane.org>
2018-07-31  7:03           ` Christian König
     [not found]             ` <c6b11c1f-b32a-4ab8-6a78-aa7886eed60a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-31  8:05               ` Zhang, Jerry (Junwei)
     [not found]                 ` <5B601844.3010405-5C7GfCeVMHo@public.gmane.org>
2018-07-31  8:13                   ` Christian König
     [not found]                     ` <5e8f2a76-6cbd-1f80-ec94-fcd79c0fa55c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-31  8:58                       ` Zhang, Jerry (Junwei)
     [not found]                         ` <5B60249D.7030503-5C7GfCeVMHo@public.gmane.org>
2018-07-31  9:04                           ` Christian König
     [not found]                             ` <9dc68d5d-561c-242a-b3ba-1c8078ab670f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-31  9:54                               ` Zhang, Jerry (Junwei)
     [not found]                                 ` <5B6031CA.4050102-5C7GfCeVMHo@public.gmane.org>
2018-07-31 10:13                                   ` Christian König
     [not found]                                     ` <3ffb8b8c-fae3-92d9-80e1-bd7d0498b4c7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-31 22:07                                       ` Marek Olšák
     [not found]                                         ` <CAAxE2A6uLe_ZMTGQ2dqFbY--Mf15qRrP+tX6pbicokpe8Wo=qQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-01  6:32                                           ` Christian König
     [not found]                                             ` <53eb686a-0747-394a-b0c3-4cd53ab836e2-5C7GfCeVMHo@public.gmane.org>
2018-08-01 17:39                                               ` Marek Olšák
     [not found]                                                 ` <CAAxE2A6C0mmr2vogcAQL+XNQuPU=BqHUGjqAMVnS3pK37XJa0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-01 17:52                                                   ` Christian König
     [not found]                                                     ` <edbcf817-75ea-6e6a-d64a-6274a78308e7-5C7GfCeVMHo@public.gmane.org>
2018-08-01 17:59                                                       ` Marek Olšák
     [not found]                                                         ` <CAAxE2A4=k5_20jaPcM9awxQ69MhXY2wtEX9NFxZU9=43_SsRug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-01 18:29                                                           ` Christian König
     [not found]                                                             ` <ba1798f5-9aa9-6d55-791a-b2fd52087ea7-5C7GfCeVMHo@public.gmane.org>
2018-08-02  0:00                                                               ` Marek Olšák
     [not found]                                                                 ` <CAAxE2A4bma0u8R+ggETPoUycC=MTkrs0oUGJFW8kGx__Sf35eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-02  6:20                                                                   ` Zhang, Jerry (Junwei)
     [not found]                                                                     ` <5B62A2A0.5060508-5C7GfCeVMHo@public.gmane.org>
2018-08-02  6:29                                                                       ` Christian König

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.