On 28/06/17 11:33 AM, John Brooks wrote: > When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace, > it should only be treated as a hint to initially place a BO somewhere CPU > accessible, rather than having a permanent effect on BO placement. > > Instead of the flag being set in stone at BO creation, set the flag when a > page fault occurs so that it goes somewhere CPU-visible, and clear it when > the BO is requested by the GPU. > > However, clearing the CPU_ACCESS_REQUIRED flag may move BOs in GTT to > invisible VRAM, where they may promptly generate another page fault. When > BOs are constantly moved back and forth like this, it is highly detrimental > to performance. Only clear the flag on CS if: > > - The BO wasn't page faulted for a certain amount of time (currently 10 > seconds), and > - its last page fault didn't occur too soon (currently 500ms) after its > last CS request, or vice versa. > > Setting the flag in amdgpu_fault_reserve_notify() also means that we can > remove the loop to restrict lpfn to the end of visible VRAM, because > amdgpu_ttm_placement_init() will do it for us. > > Signed-off-by: John Brooks <j...@fastquake.com>
[...] > @@ -967,15 +967,9 @@ int amdgpu_bo_fault_reserve_notify(struct > ttm_buffer_object *bo) > > /* hurrah the memory is not visible ! */ > atomic64_inc(&adev->num_vram_cpu_page_faults); > + abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED; Talking about this on IRC reminded me that I think we should set the flag in this function regardless of where the BO is currently located. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel