[PATCH 4/4] drm/amdgpu: reset fpriv vram_lost_counter
david1.zhou at amd.com
Wed May 17 03:04:02 UTC 2017
On 2017年05月17日 09:18, Michel Dänzer wrote:
> 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)
>> case AMDGPU_VM_OP_UNRESERVE_VMID:
>> amdgpu_vm_free_reserved_vmid(adev, &fpriv->vm, AMDGPU_GFXHUB);
>> + case AMDGPU_VM_OP_RESET:
>> + 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.
struct amdgpu_fpriv for vram_lost_counter is proper place, especially
for ioctl return value.
if you need to reset ctx one by one, we can mark all contexts of that
vm, and then reset by userspace.
> 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?
VM page table will recover by vm shadow BOs.
> It's hard to be sure whether that's workable for the UMD without at
> least a working prototype...
Totally agree, if you can help to do this in userspace, I'd like to
support you from kernel side, or Christian.
More information about the amd-gfx