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

[Alex Deucher]

On Thu, Aug 17, 2017 at 2:17 PM, Jan Vesely  wrote:
> Hi,
>
> thanks a lot for these answers.
>
> On Thu, 2017-08-17 at 15:01 +0200, Christian König wrote:
>> Am 17.08.2017 um 13:54 schrieb Jan Vesely:
>> > On Thu, 2017-08-17 at 11:54 +0200, Christian König wrote:
>> > > [SNIP]
>> > > 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?
>>
>> No, not even remotely. GPUVM page tables on pre-Vega can only deal with
>> two levels, some blocks like display can even only handle one or start
>> to run into problems.
>
> Can you share the motivation to change this? was it done to accommodate
> sparse mappings, or ease synchronizing with CPU pagetables (HMM like)?
> Given the problems you mentioned below the change is counter intuitive

The motivation was to handle larger virtual address spaces (40 vs 48
bit) while not eating up tons of memory for page tables.  Not a big
deal for gfx, but definitely important for compute, especially with
SVM.

Alex

>
>>
>> >   could fragmentation size go above the limit of one level?
>>
>> I think so, but I never confirmed with the hardware guys. The maximum
>> fragment size is 1 or 2GB IIRC and that's normally way larger than a
>> single page table.
>>
>> > > 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?
>>
>> Never measured it, but I would strongly assume so. See when you can skip
>> the last level of a page table walk in a four level tree you basically
>> make each full walk 25% more efficient.
>
> That makes sense, but high impact of PTW time on overall performance
> would imply poor TLB/MMU$ hit rate. Was the change targeted at graphics
> or compute workloads?
>
>>
>> > Does it mean that GPUVM does not have PTW prefix caches?
>>
>> Vega10 does have a cache for page directory entries, but we have seen
>> significant improvement when we stopped to use that and instead used the
>> L2 with 2MB pages.
>
> Does this perform better than using old style fragment based 2MB pages?
>
>
>> > 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.
>>
>> Well it's certainly a hot topic, cause it can affect memory throughput
>> significantly.
>
> Your answers are greatly appreciated. I always assumed that graphic
> workload requirements would be at odds with SVM cpu/gpu integration, so
> it's interesting to find out if it might not be the case. (It'd also be
> interesting to know what impact did the cache hierarchy changes in GCN
> have on graphics vs. compute performance)
>
> thanks,
> Jan
>
>
>>
>> Regards,
>> Christian.
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> --
> Jan Vesely 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jan Vesely]

Hi,

thanks a lot for these answers.

On Thu, 2017-08-17 at 15:01 +0200, Christian König wrote:
> Am 17.08.2017 um 13:54 schrieb Jan Vesely:
> > On Thu, 2017-08-17 at 11:54 +0200, Christian König wrote:
> > > [SNIP]
> > > 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?
> 
> No, not even remotely. GPUVM page tables on pre-Vega can only deal with 
> two levels, some blocks like display can even only handle one or start 
> to run into problems.

Can you share the motivation to change this? was it done to accommodate
sparse mappings, or ease synchronizing with CPU pagetables (HMM like)?
Given the problems you mentioned below the change is counter intuitive

> 
> >   could fragmentation size go above the limit of one level?
> 
> I think so, but I never confirmed with the hardware guys. The maximum 
> fragment size is 1 or 2GB IIRC and that's normally way larger than a 
> single page table.
> 
> > > 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?
> 
> Never measured it, but I would strongly assume so. See when you can skip 
> the last level of a page table walk in a four level tree you basically 
> make each full walk 25% more efficient.

That makes sense, but high impact of PTW time on overall performance
would imply poor TLB/MMU$ hit rate. Was the change targeted at graphics
or compute workloads?

> 
> > Does it mean that GPUVM does not have PTW prefix caches?
> 
> Vega10 does have a cache for page directory entries, but we have seen 
> significant improvement when we stopped to use that and instead used the 
> L2 with 2MB pages.

Does this perform better than using old style fragment based 2MB pages?


> > 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.
> 
> Well it's certainly a hot topic, cause it can affect memory throughput 
> significantly.

Your answers are greatly appreciated. I always assumed that graphic
workload requirements would be at odds with SVM cpu/gpu integration, so
it's interesting to find out if it might not be the case. (It'd also be
interesting to know what impact did the cache hierarchy changes in GCN
have on graphics vs. compute performance)

thanks,
Jan


> 
> Regards,
> Christian.
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Christian König]

Am 17.08.2017 um 13:54 schrieb Jan Vesely:

On Thu, 2017-08-17 at 11:54 +0200, Christian König wrote:

[SNIP]
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?


No, not even remotely. GPUVM page tables on pre-Vega can only deal with 
two levels, some blocks like display can even only handle one or start 
to run into problems.



  could fragmentation size go above the limit of one level?


I think so, but I never confirmed with the hardware guys. The maximum 
fragment size is 1 or 2GB IIRC and that's normally way larger than a 
single page table.



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?


Never measured it, but I would strongly assume so. See when you can skip 
the last level of a page table walk in a four level tree you basically 
make each full walk 25% more efficient.



Does it mean that GPUVM does not have PTW prefix caches?


Vega10 does have a cache for page directory entries, but we have seen 
significant improvement when we stopped to use that and instead used the 
L2 with 2MB pages.



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.


Well it's certainly a hot topic, cause it can affect memory throughput 
significantly.


Regards,
Christian.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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  
> > > wrote:
> > > > On 17/08/17 12:33 PM, Aaron Watry wrote:
> > > > > On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  
> > > > > wrote:
> > > > > > On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer 
> > > > > >  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@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
> 
> 

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Christian König]

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  wrote:

On 17/08/17 12:33 PM, Aaron Watry wrote:

On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:

On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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

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

[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  wrote:
> > On 17/08/17 12:33 PM, Aaron Watry wrote:
> > > On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  
> > > wrote:
> > > > On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  
> > > > 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).

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

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Alex Deucher]

On Wed, Aug 16, 2017 at 11:34 PM, Michel Dänzer  wrote:
> On 17/08/17 12:33 PM, Aaron Watry wrote:
>> On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
>>> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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.

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

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

[Michel Dänzer]

On 17/08/17 12:33 PM, Aaron Watry wrote:
> On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
>> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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.


> 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

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

[Aaron Watry]

On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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?

If so, I guess I can just use getpagesize() in patch 2 for now and skip the CAP.

--Aaron

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

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

[Michel Dänzer]

On 17/08/17 11:48 AM, Alex Deucher wrote:
> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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.

Right, I suspect "page" in the PIPE_CAP_RESOURCE_FROM_USER_MEMORY
documentation was always intended as "CPU page". Maybe that just needs
to be clarified.


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

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

[Alex Deucher]

On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  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.

Alex

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

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

[Michel Dänzer]

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?


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