lwn.git/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c, branch v6.9

drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2

2024-05-01T01:39:57+00:00

This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap. The basic problem here is that after the move the old location is simply not available any more. Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well. Also rework the statistic handling so that we don't update the eviction counter before the move. v2: add missing NULL check Signed-off-by: Christian König Fixes: 94aeb4117343 ("drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3171 Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org

drm/amdgpu: Update BO eviction priorities

2024-04-24T03:23:28+00:00

Make SVM BOs more likely to get evicted than other BOs. These BOs opportunistically use available VRAM, but can fall back relatively seamlessly to system memory. It also avoids SVM migrations evicting other, more important BOs as they will evict other SVM allocations first. Signed-off-by: Felix Kuehling Acked-by: Mukul Joshi Tested-by: Mukul Joshi Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: fix visible VRAM handling during faults

2024-04-17T15:50:43+00:00

When we removed the hacky start code check we actually didn't took into account that *all* VRAM pages needs to be CPU accessible. Clean up the code and unify the handling into a single helper which checks if the whole resource is CPU accessible. The only place where a partial check would make sense is during eviction, but that is neglitible. Signed-off-by: Christian König Fixes: aed01a68047b ("drm/amdgpu: Remove TTM resource->start visible VRAM condition v2") Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org

drm/amdgpu: add shared fdinfo stats

2024-02-16T11:52:50+00:00

Add shared stats. Useful for seeing shared memory. v2: take dma-buf into account as well v3: use the new gem helper Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/ Signed-off-by: Alex Deucher Cc: Rob Clark Reviewed-by: Christian König Signed-off-by: Christian König

Merge drm/drm-next into drm-misc-next

2024-01-29T13:20:23+00:00

Kickstart 6.9 development cycle. Signed-off-by: Maxime Ripard

drm/ttm: replace busy placement with flags v6

2024-01-25T08:59:44+00:00

Instead of a list of separate busy placement add flags which indicate that a placement should only be used when there is room or if we need to evict. v2: add missing TTM_PL_FLAG_IDLE for i915 v3: fix auto build test ERROR on drm-tip/drm-tip v4: fix some typos pointed out by checkpatch v5: cleanup some rebase problems with VMWGFX v6: implement some missing VMWGFX functionality pointed out by Zack, rename the flags as suggested by Michel, rebase on drm-tip and adjust XE as well Signed-off-by: Christian König Signed-off-by: Somalapuram Amaranath Reviewed-by: Zack Rusin Reviewed-by: Thomas Zimmermann Reviewed-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20240112125158.2748-4-christian.koenig@amd.com

drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap

2023-12-14T20:25:48+00:00

Issue: during evict or validate happened on amdgpu_bo, the 'from' and 'to' is always same in ftrace event of amdgpu_bo_move where calling the 'trace_amdgpu_bo_move', the comment says move_notify is called before move happens, but actually it is called after move happens, here the new_mem is same as bo->resource Fix: move trace_amdgpu_bo_move from move_notify to amdgpu_bo_move Signed-off-by: Wang, Beyond Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: warn when there are still mappings when a BO is destroyed v2

2023-12-13T21:33:02+00:00

This can only happen when there is a reference counting bug. v2: fix typo Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: fix AGP addressing when GART is not at 0

2023-11-29T21:49:22+00:00

This worked by luck if the GART aperture ended up at 0. When we ended up moving GART on some chips, the GART aperture ended up offsetting the AGP address since the resource->start is a GART offset, not an MC address. Fix this by moving the AGP address setup into amdgpu_bo_gpu_offset_no_check(). v2: check mem_type before checking agp v3: check if the ttm bo has a ttm_tt allocated yet Fixes: 67318cb84341 ("drm/amdgpu/gmc11: set gart placement GC11") Tested-by: Mario Limonciello Reported-by: Jesse Zhang Reported-by: Yifan Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: christian.koenig@amd.com Cc: mario.limonciello@amd.com

drm/amdgpu: fix AGP init order

2023-11-09T21:59:46+00:00

The default AGP settings were overwriting the IP selected ones since the default was getting set after the IP ones were selected. Fixes: de59b69932e6 ("drm/amdgpu/gmc: set a default disable value for AGP") Link: https://lists.freedesktop.org/archives/amd-gfx/2023-November/100966.html Tested-by: Mikhail Gavrilov Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: Mikhail Gavrilov