[PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-07-12 02:47 AM, Marek Olšák wrote:
> From: Marek Olšák <marek.olsak at amd.com>
> 
> ---
>  amdgpu/amdgpu.h    | 7 ++++++-
>  amdgpu/amdgpu_bo.c | 4 ++++
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 36f91058..be83b457 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -77,21 +77,26 @@ struct drm_amdgpu_info_hw_ip;
>   *
>  */
>  enum amdgpu_bo_handle_type {
>  	/** GEM flink name (needs DRM authentication, used by DRI2) */
>  	amdgpu_bo_handle_type_gem_flink_name = 0,
>  
>  	/** KMS handle which is used by all driver ioctls */
>  	amdgpu_bo_handle_type_kms = 1,
>  
>  	/** DMA-buf fd handle */
> -	amdgpu_bo_handle_type_dma_buf_fd = 2
> +	amdgpu_bo_handle_type_dma_buf_fd = 2,
> +
> +	/** KMS handle, but re-importing as a DMABUF handle through
> +	 *  drmPrimeHandleToFD is forbidden. (Glamor does that)
> +	 */
> +	amdgpu_bo_handle_type_kms_noimport = 3,
>  };
>  
>  /** Define known types of GPU VM VA ranges */
>  enum amdgpu_gpu_va_range
>  {
>  	/** Allocate from "normal"/general range */
>  	amdgpu_gpu_va_range_general = 0
>  };
>  
>  enum amdgpu_sw_info {
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 9e37b149..d29be244 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -234,20 +234,22 @@ int amdgpu_bo_export(amdgpu_bo_handle bo,
>  	case amdgpu_bo_handle_type_gem_flink_name:
>  		r = amdgpu_bo_export_flink(bo);
>  		if (r)
>  			return r;
>  
>  		*shared_handle = bo->flink_name;
>  		return 0;
>  
>  	case amdgpu_bo_handle_type_kms:
>  		amdgpu_add_handle_to_table(bo);
> +		/* fall through */
> +	case amdgpu_bo_handle_type_kms_noimport:
>  		*shared_handle = bo->handle;
>  		return 0;

What is the rationale for this? I.e. why do you want to not store some
handles in the hash table? And how can code using
amdgpu_bo_handle_type_kms_noimport be sure that the BO will never be
re-imported via dma-buf?

The experience with the previous patch has shown that it's hard to keep
track of all possible ways in which BOs are imported, and that if we
miss one, this breaks pretty spectacularly.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux