Hi Yong,
> How should deal with that or can you come up with a fix?
well that is the expected effect. So I don't see much we can do here.
Support for the parameter was added to be able to intentionally break
support for HMM/SVM for testing the fall back paths.
Didn't thought about ATC while enabling this, but it certainly falls
into the same category. Could be that we can still keep ATC working
while reducing the GPUVM size, but that would require further testing.
Regards,
Christian.
Am 14.12.2017 um 16:56 schrieb Yong Zhao:
> Hi Christian,
>
> I don't know much about the background. But according to my
> experiments, as long as we change the vm size to 64G, ATC memory
> access on Raven will fall apart. How should deal with that or can you
> come up with a fix?
>
> Regards,
>
> Yong
>
>
> On 2017-12-14 03:47 AM, Christian König wrote:
>> NAK, that really circumvents the intention of the patch to adjust the
>> number of levels based on the vm_size.
>>
>> Christian.
>>
>> Am 14.12.2017 um 03:25 schrieb Yong Zhao:
>>> Change-Id: Id522c1cbadb8c069720f4e64a31cff42cd014733
>>> Signed-off-by: Yong Zhao <yong.zhao at amd.com>
>>> ---
>>> Â drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
>>> Â 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 709587d..3b9eb1a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -2534,7 +2534,7 @@ void amdgpu_vm_adjust_size(struct
>>> amdgpu_device *adev, uint32_t vm_size,
>>> Â Â Â Â Â uint64_t tmp;
>>> Â Â Â Â Â Â /* adjust vm size first */
>>> -Â Â Â if (amdgpu_vm_size != -1) {
>>> +Â Â Â if (amdgpu_vm_size != -1 && max_level == 1) {
>>> Â Â Â Â Â Â Â Â Â unsigned max_size = 1 << (max_bits - 30);
>>> Â Â Â Â Â Â Â Â Â Â vm_size = amdgpu_vm_size;
>>
>
