Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

On Tue, Jul 4, 2017 at 10:09 AM, Michel Dänzer  wrote:
> On 03/07/17 10:03 PM, Marek Olšák wrote:
>> On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer  wrote:
>>> On 30/06/17 08:43 PM, Marek Olšák wrote:

 I don't know what is being talked about here anymore, but I wouldn't
 like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
 userspace. The reason is that userspace doesn't and can't know whether
 CPU access will be required, and the frequency at which it will be
 required. 3 heaps {no CPU access, no flag, CPU access required} are
 too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
 uses "CPU access required" for almost everything except tiled
 textures, which use "no CPU access".
>>>
>>> FWIW, the difference between setting CPU_ACCESS_REQUIRED and not setting
>>> it for a BO created in VRAM will be: If it's set, the BO is initially
>>> created in CPU visible VRAM, otherwise it's most likely created in CPU
>>> invisible VRAM.
>>>
>>> If userspace knows that a BO will likely be accessed by the CPU first,
>>> setting the flag could save a move from CPU invisible to CPU visible
>>> VRAM when the CPU access happens. Conversely, if a BO will likely never
>>> be accessed by the CPU, not setting the flag may reduce pressure on CPU
>>> visible VRAM.
>>>
>>> Not sure radeonsi can make this distinction though.
>>
>> It can't.
>
> Not sure why, but anyway.
>
>
>> Either all mappable BOs set CPU_ACCESS_REQUIRED, or all mappable BOs
>> don't set it.
>
> FWIW, with kernels without John's fixes, the flag shouldn't be set for
> all such BOs, because it would prevent them from ever going to CPU
> invisible VRAM.
>
> With John's fixes, one possibility would be to set the flag based on the
> existing heuristics or some variant, and use it when a BO is newly
> created from the kernel, but to ignore the flag when reusing a BO from
> the cache (with John's fixes, whether or not the flag was set when a BO
> was created won't directly affect its state WRT the flag when it's
> reused from the cache).

Thanks. Based on your comments, I've come to the conclusion that the
userspace shouldn't set CPU_ACCESS_REQUIRED, because the only other
alternative (always setting the flag) is worse.

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 03/07/17 10:03 PM, Marek Olšák wrote:
> On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer  wrote:
>> On 30/06/17 08:43 PM, Marek Olšák wrote:
>>>
>>> I don't know what is being talked about here anymore, but I wouldn't
>>> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
>>> userspace. The reason is that userspace doesn't and can't know whether
>>> CPU access will be required, and the frequency at which it will be
>>> required. 3 heaps {no CPU access, no flag, CPU access required} are
>>> too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
>>> uses "CPU access required" for almost everything except tiled
>>> textures, which use "no CPU access".
>>
>> FWIW, the difference between setting CPU_ACCESS_REQUIRED and not setting
>> it for a BO created in VRAM will be: If it's set, the BO is initially
>> created in CPU visible VRAM, otherwise it's most likely created in CPU
>> invisible VRAM.
>>
>> If userspace knows that a BO will likely be accessed by the CPU first,
>> setting the flag could save a move from CPU invisible to CPU visible
>> VRAM when the CPU access happens. Conversely, if a BO will likely never
>> be accessed by the CPU, not setting the flag may reduce pressure on CPU
>> visible VRAM.
>>
>> Not sure radeonsi can make this distinction though.
> 
> It can't.

Not sure why, but anyway.


> Either all mappable BOs set CPU_ACCESS_REQUIRED, or all mappable BOs
> don't set it.

FWIW, with kernels without John's fixes, the flag shouldn't be set for
all such BOs, because it would prevent them from ever going to CPU
invisible VRAM.

With John's fixes, one possibility would be to set the flag based on the
existing heuristics or some variant, and use it when a BO is newly
created from the kernel, but to ignore the flag when reusing a BO from
the cache (with John's fixes, whether or not the flag was set when a BO
was created won't directly affect its state WRT the flag when it's
reused from the cache).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer  wrote:
> On 30/06/17 08:43 PM, Marek Olšák wrote:
>>
>> I don't know what is being talked about here anymore, but I wouldn't
>> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
>> userspace. The reason is that userspace doesn't and can't know whether
>> CPU access will be required, and the frequency at which it will be
>> required. 3 heaps {no CPU access, no flag, CPU access required} are
>> too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
>> uses "CPU access required" for almost everything except tiled
>> textures, which use "no CPU access".
>
> FWIW, the difference between setting CPU_ACCESS_REQUIRED and not setting
> it for a BO created in VRAM will be: If it's set, the BO is initially
> created in CPU visible VRAM, otherwise it's most likely created in CPU
> invisible VRAM.
>
> If userspace knows that a BO will likely be accessed by the CPU first,
> setting the flag could save a move from CPU invisible to CPU visible
> VRAM when the CPU access happens. Conversely, if a BO will likely never
> be accessed by the CPU, not setting the flag may reduce pressure on CPU
> visible VRAM.
>
> Not sure radeonsi can make this distinction though.

It can't.

Either all mappable BOs set CPU_ACCESS_REQUIRED, or all mappable BOs
don't set it. Either way, there is only one combination of flags for
mappable BOs in VRAM, and therefore only one kind of behavior the
kernel can follow.

>
>
>> I've been trying to trim down the number of heaps. So far, I have:
>> - VRAM_NO_CPU_ACCESS (implies WC)
>> - VRAM (implies WC)
>> - VRAM_GTT (combined, implies WC)
>
> Is this useful? It means:
>
> * The BO may be created in VRAM, or if there's no space, in GTT.
> * Once the BO is in GTT for any reason, it will never go back to VRAM.
>
> Such BOs will tend to end up in GTT after some time, at the latest after
> suspend/resume.
>
> I think it would be better for radeonsi to choose either VRAM or GTT as
> the preferred domain, and let the kernel handle it.

Currently, radeonsi on amdgpu doesn't use VRAM_GTT with the current kernel.

I'm aware of the limited usefulness.

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 30/06/17 08:43 PM, Marek Olšák wrote:
> 
> I don't know what is being talked about here anymore, but I wouldn't
> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
> userspace. The reason is that userspace doesn't and can't know whether
> CPU access will be required, and the frequency at which it will be
> required. 3 heaps {no CPU access, no flag, CPU access required} are
> too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
> uses "CPU access required" for almost everything except tiled
> textures, which use "no CPU access".

FWIW, the difference between setting CPU_ACCESS_REQUIRED and not setting
it for a BO created in VRAM will be: If it's set, the BO is initially
created in CPU visible VRAM, otherwise it's most likely created in CPU
invisible VRAM.

If userspace knows that a BO will likely be accessed by the CPU first,
setting the flag could save a move from CPU invisible to CPU visible
VRAM when the CPU access happens. Conversely, if a BO will likely never
be accessed by the CPU, not setting the flag may reduce pressure on CPU
visible VRAM.

Not sure radeonsi can make this distinction though.


> I've been trying to trim down the number of heaps. So far, I have:
> - VRAM_NO_CPU_ACCESS (implies WC)
> - VRAM (implies WC)
> - VRAM_GTT (combined, implies WC)

Is this useful? It means:

* The BO may be created in VRAM, or if there's no space, in GTT.
* Once the BO is in GTT for any reason, it will never go back to VRAM.

Such BOs will tend to end up in GTT after some time, at the latest after
suspend/resume.

I think it would be better for radeonsi to choose either VRAM or GTT as
the preferred domain, and let the kernel handle it.


> - GTT_WC
> - GTT




-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH RFC 0/2] Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[John Brooks]

> On 30/06/17 03:59 PM, Christian König wrote:
>> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
>>> We can deal with that internally in the kernel, while fixing the
>>> existing flag for userspace.
>> And as I said, NAK to that approach. I'm not going to add a
>> CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has
>> messed up it's use case.
>>
>> We could agree on filtering that flag from userspace when BOs are
>> created and/or map it to a CREATE_CPU_ACCESS_HINT flag.
> Then I propose the following:
>
> One patch:
>
> Convert AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED to a kernel internal flag
> AMDGPU_GEM_CPU_ACCESS_HINT in amdgpu_gem_create_ioctl, which is
> initially treated the same way as AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED.
>
> Another patch:
>
> Change the treatment of AMDGPU_GEM_CPU_ACCESS_HINT according to John's
> patch 4 in the latest series, or a variation of that as discussed on IRC.
>
>
> If any regressions are reported, we will be able to differentiate
> whether they are due to the addition of the new flag itself or due to
> the change in its handling.
>

How about this?
Note: I haven't tested this beyond compiling.

See replies for:
[PATCH RFC 1/2] drm/amdgpu: Add AMDGPU_BO_FLAG_CPU_ACCESS
[PATCH RFC 2/2] drm/amdgpu: Set/clear CPU_ACCESS flag on page fault

John

>
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

On Fri, Jun 30, 2017 at 12:34 PM, Christian König
 wrote:
> Am 30.06.2017 um 09:14 schrieb Michel Dänzer:
>>
>> On 30/06/17 03:59 PM, Christian König wrote:
>>>
>>> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:

 We can deal with that internally in the kernel, while fixing the
 existing flag for userspace.
>>>
>>> And as I said, NAK to that approach. I'm not going to add a
>>> CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has
>>> messed up it's use case.
>>>
>>> We could agree on filtering that flag from userspace when BOs are
>>> created and/or map it to a CREATE_CPU_ACCESS_HINT flag.
>>
>> Then I propose the following:
>>
>> One patch:
>>
>> Convert AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED to a kernel internal flag
>> AMDGPU_GEM_CPU_ACCESS_HINT in amdgpu_gem_create_ioctl, which is
>> initially treated the same way as AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED.
>>
>> Another patch:
>>
>> Change the treatment of AMDGPU_GEM_CPU_ACCESS_HINT according to John's
>> patch 4 in the latest series, or a variation of that as discussed on IRC.
>>
>>
>> If any regressions are reported, we will be able to differentiate
>> whether they are due to the addition of the new flag itself or due to
>> the change in its handling.
>
>
>
> It just occurred to me that there is a simpler way of handling this: We just
> never clear the flag on kernel allocations.
>
> See my main concern are the in kernel users of the flag which use it as
> guarantee that the BO is CPU accessible.
>
> If we handle those specially there shouldn't be a problem clearing the flag
> for the UMD BOs.

Hi,

I don't know what is being talked about here anymore, but I wouldn't
like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
userspace. The reason is that userspace doesn't and can't know whether
CPU access will be required, and the frequency at which it will be
required. 3 heaps {no CPU access, no flag, CPU access required} are
too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
uses "CPU access required" for almost everything except tiled
textures, which use "no CPU access".

I've been trying to trim down the number of heaps. So far, I have:
- VRAM_NO_CPU_ACCESS (implies WC)
- VRAM (implies WC)
- VRAM_GTT (combined, implies WC)
- GTT_WC
- GTT

See, you can't forbid CPU access for the combined VRAM_GTT heap. It's
one of the compromises there.

The more heaps we have, the more memory can be wasted by
suballocators. It's silly to have more than 3 suballocators just for
VRAM.

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Christian König]

Am 30.06.2017 um 09:14 schrieb Michel Dänzer:

On 30/06/17 03:59 PM, Christian König wrote:

Am 30.06.2017 um 08:51 schrieb Michel Dänzer:

We can deal with that internally in the kernel, while fixing the
existing flag for userspace.

And as I said, NAK to that approach. I'm not going to add a
CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has
messed up it's use case.

We could agree on filtering that flag from userspace when BOs are
created and/or map it to a CREATE_CPU_ACCESS_HINT flag.

Then I propose the following:

One patch:

Convert AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED to a kernel internal flag
AMDGPU_GEM_CPU_ACCESS_HINT in amdgpu_gem_create_ioctl, which is
initially treated the same way as AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED.

Another patch:

Change the treatment of AMDGPU_GEM_CPU_ACCESS_HINT according to John's
patch 4 in the latest series, or a variation of that as discussed on IRC.


If any regressions are reported, we will be able to differentiate
whether they are due to the addition of the new flag itself or due to
the change in its handling.



It just occurred to me that there is a simpler way of handling this: We 
just never clear the flag on kernel allocations.


See my main concern are the in kernel users of the flag which use it as 
guarantee that the BO is CPU accessible.


If we handle those specially there shouldn't be a problem clearing the 
flag for the UMD BOs.


Christian.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 30/06/17 03:59 PM, Christian König wrote:
> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
>> We can deal with that internally in the kernel, while fixing the
>> existing flag for userspace.
> 
> And as I said, NAK to that approach. I'm not going to add a
> CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has
> messed up it's use case.
> 
> We could agree on filtering that flag from userspace when BOs are
> created and/or map it to a CREATE_CPU_ACCESS_HINT flag.

Then I propose the following:

One patch:

Convert AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED to a kernel internal flag
AMDGPU_GEM_CPU_ACCESS_HINT in amdgpu_gem_create_ioctl, which is
initially treated the same way as AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED.

Another patch:

Change the treatment of AMDGPU_GEM_CPU_ACCESS_HINT according to John's
patch 4 in the latest series, or a variation of that as discussed on IRC.


If any regressions are reported, we will be able to differentiate
whether they are due to the addition of the new flag itself or due to
the change in its handling.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Christian König]

Am 30.06.2017 um 08:51 schrieb Michel Dänzer:

We can deal with that internally in the kernel, while fixing the
existing flag for userspace.


And as I said, NAK to that approach. I'm not going to add a 
CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has 
messed up it's use case.


We could agree on filtering that flag from userspace when BOs are 
created and/or map it to a CREATE_CPU_ACCESS_HINT flag. But I would 
rather want to avoid that as well.


Christian.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Christian König]

Am 30.06.2017 um 03:36 schrieb Michel Dänzer:

On 30/06/17 12:03 AM, Marek Olšák wrote:

Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?

No concern from my side for radeon.



On Thu, Jun 29, 2017 at 4:51 PM, Christian König
 wrote:

Yeah, I was thinking something similar.

See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU
access is immediately possible.

If you ask me that is not really useful for the UMD and was never meant to
be used by Mesa (only the closed source UMD and some kernel internal use
cases).

I would like to keep the behavior in the kernel driver as it is, but we
should really stop using this as a hint in Mesa.

So we'd have a flag in the userspace ABI which is only used by closed
source userspace, and which can be used to artificially create pressure
on CPU visible VRAM. I know somebody who would argue vehemently against
adding something like that. :)


Yeah, and I really tried hard to prevent that :)

But unfortunately the milk is already spilled, so not much we can do 
about that.



What does the closed source UMD use the flag for?


Well it doesn't use the flag, but it has the concept of separate heaps 
for visible and invisible VRAM and maps that to setting the flag 
appropriately.


But putting the closed source UMD asside, my primary concern is rather 
in kernel users of the flag.


Regards,
Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Mao, David]

Sounds good!
One thing to confirm, If the original location is already in the invisible, 
will the notifier callback to move the bo from invisible to visible?  if it is 
true and the logic is already available in the kernel, can we use NO_CPU_ACCESS 
flag by default to accomplish the similar purpose for now?
It also reminds me of another related topic, can we always take visible heap as 
priority against to the remote in this case?
So far, kernel don’t have the heap priority.
IIRC, if the LFB bo moved to GTT, it will never be moved back since GTT is also 
its preferred heap. (Kernel seems to add the GTT even if the UMD only ask for 
LFB).

Thanks.
Best Regards,
David
On 30 Jun 2017, at 11:36 AM, Michel Dänzer 
> wrote:

On 30/06/17 10:55 AM, Mao, David wrote:
Vulkan allows the application to decide whether it wants the allocation
to be host visible and device local.
If we drop the flag, what will happen if we did not set the
NO_CPU_ACCESS flag?
Will it fail the map in case the allocation could be placed in invisible
heap then?

No, it'll work just as well. On attempted CPU access,
amdgpu_bo_fault_reserve_notify will ensure that it's CPU accessible.

The difference is that it'll allow BOs which aren't being actively
accessed by the CPU to be in CPU invisible VRAM, reducing pressure on
CPU visible VRAM.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 30/06/17 10:55 AM, Mao, David wrote:
> Vulkan allows the application to decide whether it wants the allocation
> to be host visible and device local. 
> If we drop the flag, what will happen if we did not set the
> NO_CPU_ACCESS flag?
> Will it fail the map in case the allocation could be placed in invisible
> heap then?

No, it'll work just as well. On attempted CPU access,
amdgpu_bo_fault_reserve_notify will ensure that it's CPU accessible.

The difference is that it'll allow BOs which aren't being actively
accessed by the CPU to be in CPU invisible VRAM, reducing pressure on
CPU visible VRAM.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Mao, David]

Vulkan allows the application to decide whether it wants the allocation to be 
host visible and device local.
If we drop the flag, what will happen if we did not set the NO_CPU_ACCESS flag?
Will it fail the map in case the allocation could be placed in invisible heap 
then?

Thanks.
Best Regards,
David
On 29 Jun 2017, at 11:03 PM, Marek Olšák 
> wrote:

Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?

Thanks,
Marek

On Thu, Jun 29, 2017 at 4:51 PM, Christian König
> wrote:
Yeah, I was thinking something similar.

See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU
access is immediately possible.

If you ask me that is not really useful for the UMD and was never meant to
be used by Mesa (only the closed source UMD and some kernel internal use
cases).

I would like to keep the behavior in the kernel driver as it is, but we
should really stop using this as a hint in Mesa.

Regards,
Christian.


Am 29.06.2017 um 16:41 schrieb Marek Olšák:

Hi,

Given how our memory manager works and the guesswork that UMDs have to
do to determine whether to set the flag, I think the flag isn't
useful.

I'm proposing that CPU_ACCESS_REQUIRED:
- will be deprecated.
- It will remain to be accepted by the kernel driver, but it will
either not have any effect, or it will serve as a hint that might or
might not be followed.
- The only flag that UMDs are expected to set with regard to CPU
access is NO_CPU_ACCESS.

The main motivation is the reduction of "virtual" heaps for UMD buffer
suballocators and reusable buffer pools. A higher number of heaps
means that more memory can be wasted by UMDs.

Opinions?

Thanks,
Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 30/06/17 12:03 AM, Marek Olšák wrote:
> Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?

No concern from my side for radeon.


> On Thu, Jun 29, 2017 at 4:51 PM, Christian König
>  wrote:
>> Yeah, I was thinking something similar.
>>
>> See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU
>> access is immediately possible.
>>
>> If you ask me that is not really useful for the UMD and was never meant to
>> be used by Mesa (only the closed source UMD and some kernel internal use
>> cases).
>>
>> I would like to keep the behavior in the kernel driver as it is, but we
>> should really stop using this as a hint in Mesa.

So we'd have a flag in the userspace ABI which is only used by closed
source userspace, and which can be used to artificially create pressure
on CPU visible VRAM. I know somebody who would argue vehemently against
adding something like that. :)

What does the closed source UMD use the flag for?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?

Thanks,
Marek

On Thu, Jun 29, 2017 at 4:51 PM, Christian König
 wrote:
> Yeah, I was thinking something similar.
>
> See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU
> access is immediately possible.
>
> If you ask me that is not really useful for the UMD and was never meant to
> be used by Mesa (only the closed source UMD and some kernel internal use
> cases).
>
> I would like to keep the behavior in the kernel driver as it is, but we
> should really stop using this as a hint in Mesa.
>
> Regards,
> Christian.
>
>
> Am 29.06.2017 um 16:41 schrieb Marek Olšák:
>>
>> Hi,
>>
>> Given how our memory manager works and the guesswork that UMDs have to
>> do to determine whether to set the flag, I think the flag isn't
>> useful.
>>
>> I'm proposing that CPU_ACCESS_REQUIRED:
>> - will be deprecated.
>> - It will remain to be accepted by the kernel driver, but it will
>> either not have any effect, or it will serve as a hint that might or
>> might not be followed.
>> - The only flag that UMDs are expected to set with regard to CPU
>> access is NO_CPU_ACCESS.
>>
>> The main motivation is the reduction of "virtual" heaps for UMD buffer
>> suballocators and reusable buffer pools. A higher number of heaps
>> means that more memory can be wasted by UMDs.
>>
>> Opinions?
>>
>> Thanks,
>> Marek
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Christian König]

Yeah, I was thinking something similar.

See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that 
CPU access is immediately possible.


If you ask me that is not really useful for the UMD and was never meant 
to be used by Mesa (only the closed source UMD and some kernel internal 
use cases).


I would like to keep the behavior in the kernel driver as it is, but we 
should really stop using this as a hint in Mesa.


Regards,
Christian.

Am 29.06.2017 um 16:41 schrieb Marek Olšák:

Hi,

Given how our memory manager works and the guesswork that UMDs have to
do to determine whether to set the flag, I think the flag isn't
useful.

I'm proposing that CPU_ACCESS_REQUIRED:
- will be deprecated.
- It will remain to be accepted by the kernel driver, but it will
either not have any effect, or it will serve as a hint that might or
might not be followed.
- The only flag that UMDs are expected to set with regard to CPU
access is NO_CPU_ACCESS.

The main motivation is the reduction of "virtual" heaps for UMD buffer
suballocators and reusable buffer pools. A higher number of heaps
means that more memory can be wasted by UMDs.

Opinions?

Thanks,
Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx