[Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

[Jan Vesely]

On Thu, 2017-08-17 at 11:54 +0200, Christian König wrote:
> 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 <michel at daenzer.net> wrote:
> > > > On 17/08/17 12:33 PM, Aaron Watry wrote:
> > > > > On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> > > > > > On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer <michel at 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.

did pre-Vega GPUVM have the x86 style multilevel (4-5) structure of
page tables? could fragmentation size go above the limit of one level?

> 
> 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.

I assumed most of the benefits of large pages came from increased TLB
coverage. Do shorted page table walks bring significant performance
impact? Does it mean that GPUVM does not have PTW prefix caches?

sorry for the flurry of questions. I never looked into how GPUVM worked
 and assumed it used design choices tailored to benefit graphics
workloads. The "cpu-ization" of the address translation hierarchy is
rather interesting.

thanks you,
Jan

> 
> 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 at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > 
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 

-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170817/07f2c5d2/attachment.sig>