[PATCH 2/2] drm/amdgpu: Let KFD use more VMIDs on Arcturus

Christian König christian.koenig at amd.com
Thu Jun 25 15:50:21 UTC 2020


Am 25.06.20 um 17:43 schrieb Felix Kuehling:
> Am 2020-06-25 um 11:38 a.m. schrieb Christian König:
>> Am 25.06.20 um 17:15 schrieb Felix Kuehling:
>>> Am 2020-06-25 um 4:19 a.m. schrieb Christian König:
>>>> Am 25.06.20 um 05:18 schrieb Felix Kuehling:
>>>>> When there is no graphics support, KFD can use more of the VMIDs.
>>>>> Graphics
>>>>> VMIDs are only used for video decoding/encoding and post processing.
>>>>> With
>>>>> two VCE engines, there is no reason to reserve more than 2 VMIDs for
>>>>> that.
>>>> IIRC the expectation is that we still use the compute queues for post
>>>> processing and not the KFD.
>>>>
>>>> So we will need at least VMIDs for that as well.
>>> Correct. Post processing uses compute queues and VMIDs in the GFXHUB.
>>> VCE uses VMIDs in the MMHUB. I believe in Mesa they use the same VM
>>> context. So can't they share the same VMIDs?
>> Ah! Good point, But we still need at least 3 VMID when VMID
>> reservation is active.
> I don't know anything about that VMID reservation feature. What is it
> used for? Who is using it? How many VMIDs can be reserved?
>
> If one VMID is reserved, there would still be one VMID left for video
> post processing. That's not ideal, but I don't think it would be fatal.
> But is it a realistic use case that VMID reservation and ROCm+video
> processing would happen on the same system at the same time?

VMID reservation is used for debugging and yes there can only be one 
reserved.

But I think we need at least two for dynamic assignment or we might run 
into a BUG_ON() while giving VMIDs to jobs.

But I certainly need to test this as well. It's possible that 1 VMID 
indeed works as expected.

Regards,
Christian.

>
> Thanks,
>    Felix
>
>
>> I don't think you can go below this.
>>
>> Regards,
>> Christian.
>>
>>> Regards,
>>>     Felix
>>>
>>>
>>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>>>> ---
>>>>>     drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 ++++++++---
>>>>>     1 file changed, 8 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> index 6e10b42c57e5..3470929e5b8e 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> @@ -1245,10 +1245,15 @@ static int gmc_v9_0_sw_init(void *handle)
>>>>>         /*
>>>>>          * number of VMs
>>>>>          * VMID 0 is reserved for System
>>>>> -     * amdgpu graphics/compute will use VMIDs 1-7
>>>>> -     * amdkfd will use VMIDs 8-15
>>>>> +     * amdgpu graphics/compute will use VMIDs 1..n-1
>>>>> +     * amdkfd will use VMIDs n..15
>>>>> +     *
>>>>> +     * The first KFD VMID is 8 for GPUs with graphics, 3 for
>>>>> +     * compute-only GPUs. On compute-only GPUs that leaves 2 VMIDs
>>>>> +     * for video processing.
>>>>>          */
>>>>> -    adev->vm_manager.first_kfd_vmid = 8;
>>>>> +    adev->vm_manager.first_kfd_vmid =
>>>>> +        adev->asic_type == CHIP_ARCTURUS ? 3 : 8;
>>>>>           amdgpu_vm_manager_init(adev);
>>>>>     



More information about the amd-gfx mailing list