[Mesa-dev] [PATCH 00/15] RadeonSI 32-bit GPU pointers

Christian König ckoenig.leichtzumerken at gmail.com
Sun Jan 7 17:35:52 UTC 2018


Am 07.01.2018 um 17:42 schrieb Marek Olšák:
> On Sun, Jan 7, 2018 at 9:50 AM, Christian König
> <ckoenig.leichtzumerken at gmail.com> wrote:
>> Am 07.01.2018 um 01:48 schrieb Marek Olšák:
>>> On Sat, Jan 6, 2018 at 5:51 PM, Christian König
>>> <ckoenig.leichtzumerken at gmail.com> wrote:
>>>> Hi Marek,
>>>>
>>>> actually I was on the verge to remove the 32bit VM support in libdrm
>>>> because
>>>> it clashes with HMM and SVM in general.
>>>>
>>>> Is it possible to set the upper 32bit of the 64bit address to some fixed
>>>> value instead?
>>> Yes, but not on radeon. radeon only has 8GB of virtual address space and
>>> 4GB on older kernels. I would have to change LLVM to set the high bits
>>> differently on amdgpu but keep the high bits 0 on radeon.
>>
>> That only matters on Vega10/Raven anyway.
>>
>> But in general being able to define what LLVM uses for the upper bits sounds
>> like a good idea to me, this way we can keep the handling in Mesa.
>>
>> Going to send updated libdrm patches which keeps the 32bit range usable on
>> Vega10/Raven as well.
> What is wrong with Vega10/Raven? The 32bit range works fine on Raven here.

Well there is nothing "wrong" with them, it's just that Vega10/Raven are 
the first generation with recoverable page faults and we probably want 
to use this for SVM.

This way you can basically use any CPU pointer on the GPU without 
further overhead. Should be pretty neat for uploads and quite a bunch of 
other use cases in OpenGL, not to mention OpenCL and Vulkan.

The crux is that we need to disallow any manual VA allocation when this 
is active or otherwise CPU and GPU address space handling could clash.

The address space on Vega10/Raven are divided in the same way it is on 
x86 CPUs. In other words you got a low address range from 
0x0-0x800000000000 and a high address range from 
0xffff800000000000-0xffffffffffffffff.

So the idea is that we free up the low range to be able to have a 1 to 1 
address mapping with the userspace CPU address space and either 
translate that using the ATC or HMM. And then use the high range for all 
manual VA allocations through libdrm.

See the patch "[PATCH libdrm 3/4] amdgpu: use the high VA range if 
possible v2" on the amd-gfx mailing list. This way the the 32bit range 
now starts at 0xffff800000000000 instead of 0x0. Please take a look 
and/or review them.

Regards,
Christian.

>
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list