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
