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 <michel at daenzer.net<mailto:michel at daenzer.net>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170630/8059fd78/attachment.html>
