[PATCH 3/4] drm/amdgpu: Fix acquiring VM on large-BAR systems

Christian König christian.koenig at amd.com
Mon Mar 26 10:34:23 UTC 2018


Am 26.03.2018 um 03:31 schrieb Felix Kühling:
> Am 2018-03-24 um 04:34 AM schrieb Christian König:
>> Am 23.03.2018 um 20:53 schrieb Felix Kuehling:
>>> On 2018-03-23 03:35 PM, Christian König wrote:
>>>> Am 23.03.2018 um 20:30 schrieb Felix Kuehling:
>>>>> On large-BAR systems the VM page tables for compute are accessed by
>>>>> the CPU. Always allow CPU access to the page directory so that it can
>>>>> be used later by the CPU when a VM is converted to a compute VM.
>>>> NAK, that means we initial place the PD in the visible are for GFX
>>>> which is not desired (not much of an issue for Vega/Raven, but bad for
>>>> older generations).
>>> I'm not setting AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED. Doesn't that mean
>>> the buffer can be placed in invisible VRAM initially?
>> The difference is the preference. When AMDGPU_GEM_CREATE_NO_CPU_ACCESS
>> is set we try to place it initially in invisible VRAM.
> Where is that done? I'm looking at amdgpu_ttm_placement_from_domain. It
> only looks at AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED.

Of course! I have to apologize, my memory fooled me and I mixed up the 
handling of two flags.

Didn't had the chance on the weekend to actually double check the code, 
but you're absolutely right.

> [SNIP]
>> If you want to avoid the move of the page directory on large BAR
>> systems when switching a VM from GFX to compute we can also initially
>> create the BO in the system domain.
>>
>> Thinking about that a bit more that is probably a good idea anyway
>> because it avoids using VRAM by just opening the device.
> Sure, I'd do that as a separate change because it actually changes the
> initial placement, whereas my patch did not (as far as I can tell).

Yeah, indeed. Creating the BO in the system domain would also simplify 
the eviction double check dance.

Anyway this patch is Reviewed-by: Christian König 
<christian.koenig at amd.com> and sorry for the noise.

Regards,
Christian.

>
> Regards,
>    Felix
>
>> Regards,
>> Christian.
>>
>>> Regards,
>>>     Felix
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>>>> ---
>>>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +--
>>>>>     1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>> index 90ff79e..bc3557b 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>> @@ -2406,8 +2406,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev,
>>>>> struct amdgpu_vm *vm,
>>>>>         if (vm->use_cpu_for_update)
>>>>>             flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
>>>>>         else
>>>>> -        flags |= (AMDGPU_GEM_CREATE_NO_CPU_ACCESS |
>>>>> -                AMDGPU_GEM_CREATE_SHADOW);
>>>>> +        flags |= AMDGPU_GEM_CREATE_SHADOW;
>>>>>           size = amdgpu_vm_bo_size(adev, adev->vm_manager.root_level);
>>>>>         r = amdgpu_bo_create(adev, size, align, true,
>>>>> AMDGPU_GEM_DOMAIN_VRAM,
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>



More information about the amd-gfx mailing list