Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Marek Olšák]

On Fri, Jun 30, 2017 at 12:34 PM, Christian König
<deathsimple at vodafone.de> 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