[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