[PATCH 3/4] drm/amdgpu: add IOCTL interface for per VM BOs v3

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

 



Am 31.08.2017 um 00:55 schrieb Felix Kuehling:
> On 2017-08-30 11:00 AM, Christian König wrote:
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>> @@ -136,7 +136,8 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
>>   {
>>   	struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
>>   
>> -	if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
>> +	if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
>> +	    bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
>>   		return ERR_PTR(-EPERM);
>>   
>>   	return drm_gem_prime_export(dev, gobj, flags);
> Is this limitation necessary?

Not really, there are just two issue why I would like to have it at 
least for the GFX side:

1. The root page directory stays allocated while we wait for all the per 
VM BOs to be destroyed.

This can be fixed with reservation object reference counting, but I 
didn't had time yet to implement this.

2. The implicit fencing causes a bunch of problems for displayable 
textures. So any sharing of such BOs with the X server can cause 
undefined delays.

We need to fix this on the userspace level and add something like a 
AMDGPU_GEM_CREATE_UNSYCED flag for BO allocation.

Regards,
Christian.

> If it weren't for this, I'd use per-VM BOs
> for KFD, because we always need to validate all our BOs when we restore
> from an eviction anyway. But we need to be able to support buffer
> sharing at the same time. And we don't know which buffers an application
> plans to shared at allocation time.
>
> Either way, we could address this later. This patch is Reviewed-by:
> Felix Kuehling <Felix.Kuehling at amd.com>
>
> Regards,
>    Felix
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> 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