Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

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

 



On 2018-10-23 9:07 p.m., Marek Olšák wrote:
> From: Marek Olšák <marek.olsak@xxxxxxx>
> 
> ---
>  amdgpu/amdgpu_bo.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 81f8a5f7..00b9b54a 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
>  	if (r)
>  		goto out;
>  
>  	r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
>  			     buf_handle);
>  	if (r) {
>  		amdgpu_close_kms_handle(dev, args.out.handle);
>  		goto out;
>  	}
>  
> -	pthread_mutex_lock(&dev->bo_table_mutex);
> -	r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
> -				*buf_handle);
> -	pthread_mutex_unlock(&dev->bo_table_mutex);
> -	if (r)
> -		amdgpu_bo_free(*buf_handle);
> +	if (alloc_buffer->preferred_heap &
> +	    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {

What about AMDGPU_GEM_DOMAIN_CPU? I mean, that's unlikely to actually be
used here, but if it were, exporting and importing the resulting BO
should work fine?

Instead of white-listing the domains which can be shared, it might be
better to black-list those which can't, i.e. GDS/GWS/OA.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx




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

  Powered by Linux