Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

[Michel Dänzer]

On 30/06/17 01:00 PM, Mao, David wrote:
> 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?

Yes.


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

You mean set the NO_CPU_ACCESS flag for BOs in the "CPU invisible heap"?
Yes, that's a good idea.

However, we can also improve the kernel driver's handling of the
CPU_ACCESS_REQUIRED flag so that userspace code can continue using it
the way it has been.


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

That can happen if userspace specifies both VRAM and GTT as preferred
domains. It's one reason why that isn't recommended.

> (Kernel seems to add the GTT even if the UMD only ask for LFB).

I can only see

                robj->allowed_domains = robj->prefered_domains;
                if (robj->allowed_domains == AMDGPU_GEM_DOMAIN_VRAM)
                        robj->allowed_domains |= AMDGPU_GEM_DOMAIN_GTT;

which adds GTT as an *allowed* domain for BOs which only have VRAM as
the preferred domain. Since VRAM is the only preferred domain, the
driver will attempt to move the BO from GTT to VRAM on userspace command
stream submissions (subject to throttling).


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