Am 17.08.2017 um 06:30 schrieb Jan Vesely:
On Wed, 2017-08-16 at 23:49 -0400, Alex Deucher wrote:
On Wed, Aug 16, 2017 at 11:34 PM, Michel Dänzer <mic...@daenzer.net> wrote:
On 17/08/17 12:33 PM, Aaron Watry wrote:
On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer <mic...@daenzer.net> wrote:
On 17/08/17 10:52 AM, Aaron Watry wrote:
PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
but doesn't necessarily say anything about the size of those pages.
Is there any case known so far where it's not the CPU page size?
It's always the CPU page size. The limitation is not a hw limitation,
it's a sw limitation with the way the kernel handles creating BOs from
user memory.
So this won't change with the 2MB pages that are coming up for Vega?
I don't think it will, that's only about VRAM.
It applies to system memory as well, e.g., transparent huge pages, or
larger page sizes in general. I don't think that affects this
however.
what's so special about Vega 2MB pages? I thought GPUVM fragments could
specify any size (power of 2 > 4KB) even if TLBs supports anly select
few.
I remember using 4KB, 2MB, and 1GB pages with nice performance benefits
on Kaveri (using ATS, ROCm setup).
In general ATS works completely different to GPUVM and is rather bound
to the CPU page tables.
But GPUVM on everything before Vega10 has a so called fragmentation size
in their page table entries which tell the TLB that a certain bunch of
them are consecutive and so only one of them needs to be fetched and cached.
After Vega10 we more or less have the same as on x86_64 CPUs where you
set a bit in the page directory entry to stop the fetcher and use that
address instead. This way you not only make the TLB much faster, but
also save the last layer in the page table tree.
Christian.
Jan
Alex
If so, I guess I can just use getpagesize() in patch 2 for now and skip the CAP.
Right.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
