Am 29.01.2018 um 00:02 schrieb Felix Kuehling:
> On 2018-01-27 04:19 AM, Christian König wrote:
>> Am 27.01.2018 um 02:09 schrieb Felix Kuehling:
>>> Add GPUVM size and DRM render node. Also add function to query the
>>> VMID mask to avoid hard-coding it in multiple places later.
>>>
>>> Signed-off-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c     | 19
>>> +++++++++++++++++--
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h     | 2 ++
>>> Â drivers/gpu/drm/amd/include/kgd_kfd_interface.h |Â 6 ++++++
>>> Â 3 files changed, 25 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> index c9f204d..294c467 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> @@ -30,6 +30,8 @@
>>> Â const struct kgd2kfd_calls *kgd2kfd;
>>> Â bool (*kgd2kfd_init_p)(unsigned int, const struct kgd2kfd_calls**);
>>> Â +static const unsigned int compute_vmid_bitmap = 0xFF00;
>>> +
>>> Â int amdgpu_amdkfd_init(void)
>>> Â {
>>> Â Â Â Â Â int ret;
>>> @@ -137,9 +139,12 @@ void amdgpu_amdkfd_device_init(struct
>>> amdgpu_device *adev)
>>> Â Â Â Â Â int last_valid_bit;
>>> Â Â Â Â Â if (adev->kfd) {
>>> Â Â Â Â Â Â Â Â Â struct kgd2kfd_shared_resources gpu_resources = {
>>> -Â Â Â Â Â Â Â Â Â Â Â .compute_vmid_bitmap = 0xFF00,
>>> +Â Â Â Â Â Â Â Â Â Â Â .compute_vmid_bitmap = compute_vmid_bitmap,
>>> Â Â Â Â Â Â Â Â Â Â Â Â Â .num_pipe_per_mec = adev->gfx.mec.num_pipe_per_mec,
>>> -Â Â Â Â Â Â Â Â Â Â Â .num_queue_per_pipe = adev->gfx.mec.num_queue_per_pipe
>>> +Â Â Â Â Â Â Â Â Â Â Â .num_queue_per_pipe = adev->gfx.mec.num_queue_per_pipe,
>>> +Â Â Â Â Â Â Â Â Â Â Â .gpuvm_size = adev->vm_manager.max_pfn
>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â << AMDGPU_GPU_PAGE_SHIFT,
>> That most likely doesn't work as intended on Vega10. The address space
>> is divided into an upper and a lower range, but max_pfn includes both.
>>
>> I suggest to use something like min(adev->vm_manager.max_pfn <<
>> AMDGPU_GPU_PAGE_SHIFT, AMDGPU_VM_HOLE_START).
> I think this is fine as it is. This just tells the Thunk the size of the
> virtual address space supported by the GPU. Currently the Thunk only
> uses 40-bits for SVM. But eventually it will be able to use the entire
> 47 bits of user address space. Any excess address space will just go unused.
>
> I'm also wondering how universal the split 48-bit virtual address space
> layout is. Even for x86_64 there seems to be a 5-level page table layout
> that supports 56 bits of user mode addresses
> (Documentation/x86/x86_64/mm.txt). AArch64 seems to support 48-bit user
> mode addresses (Documentation/arm64/memory.txt). I haven't found similar
> information for PowerPC yet.
>
> We should avoid coding too much architecture-specific logic into this
> driver that's supposed to support other architectures as well. I should
> also review the aperture placement with bigger user mode address spaces
> in mind.
And that is exactly the reason why I've suggested to change that.
See the split between lower and upper range is not related to the CPU
configuration, instead it is a property of our GPU setup and hardware
generation.
So we should either split it in gpuvm_size_low/gpuvm_size_high or to
just use the lower range and limit the value as suggested above.
This should avoid having any GPU generation and CPU configuration
specific logic in the common interface.
Regards,
Christian.
>
> Regards,
> Â Felix
