[PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

Michel Dänzer michel at daenzer.net
Thu Jul 12 07:31:36 UTC 2018


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


More information about the amd-gfx mailing list