[PATCH 4/4] drm/amdgpu: reset fpriv vram_lost_counter

Michel Dänzer michel at daenzer.net
Wed May 17 01:18:47 UTC 2017

On 16/05/17 06:25 PM, Chunming Zhou wrote:
> Change-Id: I8eb6d7f558da05510e429d3bf1d48c8cec6c1977
> Signed-off-by: Chunming Zhou <David1.Zhou at amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +++
>  include/uapi/drm/amdgpu_drm.h          | 1 +
>  2 files changed, 4 insertions(+)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index bca1fb5..f3e7525 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -2547,6 +2547,9 @@ int amdgpu_vm_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
>  		amdgpu_vm_free_reserved_vmid(adev, &fpriv->vm, AMDGPU_GFXHUB);
>  		break;
> +		fpriv->vram_lost_counter = atomic_read(&adev->vram_lost_counter);
> +		break;

How do you envision the UMDs using this? I can mostly think of them
calling this ioctl when a context is created or destroyed. But that
would also allow any other remaining contexts using the same DRM file
descriptor to use all ioctls again. So, I think there needs to be a
vram_lost_counter in struct amdgpu_ctx instead of in struct amdgpu_fpriv.

But then I'm not sure this ioctl will be useful... I guess the UMD could
try re-uploading the contents of crucial BOs (shader code, resource
descriptors etc.) for an existing context and then call this ioctl. How
about the GPUVM page tables? Will the kernel driver automatically
re-generate those as needed, or will the UMD also need to e.g. destroy
and re-create the VM mappings for all BOs before calling this ioctl?

It's hard to be sure whether that's workable for the UMD without at
least a working prototype...

Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

More information about the amd-gfx mailing list