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

Christian König ckoenig.leichtzumerken at gmail.com
Wed Oct 24 08:14:58 UTC 2018


Am 24.10.18 um 10:04 schrieb Michel Dänzer:
> On 2018-10-23 9:07 p.m., Marek Olšák wrote:
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> ---
>>   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.

Well first of all GDS can be shared between applications.

Then adding a BO to the tracking doesn't add much overhead (only 8 bytes 
and only if it was the last allocated).

So I don't really see a reason why we should do this?

Christian.


More information about the amd-gfx mailing list