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