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.kuehl...@amd.com>
Regards,
Felix
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
