Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

On Tue, Jul 4, 2017 at 10:09 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 03/07/17 10:03 PM, Marek Olšák wrote:
>> On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer <michel at daenzer.net> 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