linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c, branch v6.17

drm/amdgpu: properly handle GC vs MM in amdgpu_vmid_mgr_init()

2025-04-30T22:16:53Z

When kernel queues are disabled, all GC vmids are available for the scheduler. MM vmids are still managed by the driver so make all 16 available. Also fix gmc 10 vs 11 mix up in commit 1f61fc28b939 ("drm/amdgpu/mes: make more vmids available when disable_kq=1") v2: Properly handle pre-GC 10 hardware Fixes: 1f61fc28b939 ("drm/amdgpu/mes: make more vmids available when disable_kq=1") Cc: Arvind Yadav Reviewed-by: Arvind Yadav Signed-off-by: Alex Deucher

drm/amdgpu: adjust enforce_isolation handling

2025-04-11T20:58:15Z

Switch from a bool to an enum and allow more options for enforce isolation. There are now 3 modes of operation: - Disabled (0) - Enabled (serialization and cleaner shader) (1) - Enabled in legacy mode (no serialization or cleaner shader) (2) This provides better flexibility for more use cases. Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: stop reserving VMIDs to enforce isolation

2025-03-21T16:16:34Z

That was quite troublesome for gang submit. Completely drop this approach and enforce the isolation separately. Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: rework how isolation is enforced v2

2025-03-21T16:16:34Z

Limiting the number of available VMIDs to enforce isolation causes some issues with gang submit and applying certain HW workarounds which require multiple VMIDs to work correctly. So instead start to track all submissions to the relevant engines in a per partition data structure and use the dma_fences of the submissions to enforce isolation similar to what a VMID limit does. v2: use ~0l for jobs without isolation to distinct it from kernel submissions which uses NULL for the owner. Add some warning when we are OOM. Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: use GFP_NOWAIT for memory allocations

2025-03-21T16:15:08Z

In the critical submission path memory allocations can't wait for reclaim since that can potentially wait for submissions to finish. Finally clean that up and mark most memory allocations in the critical path with GFP_NOWAIT. The only exception left is the dma_fence_array() used when no VMID is available, but that will be cleaned up later on. Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: Drop unused fence argument from amdgpu_vmid_grab_used

2024-10-08T13:43:17Z

Fence argument is unused so lets drop it. Reviewed-by: Christian König Signed-off-by: Tvrtko Ursulin Cc: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: Make enforce_isolation setting per GPU

2024-08-16T18:27:45Z

This commit makes enforce_isolation setting to be per GPU and per partition by adding the enforce_isolation array to the adev structure. The adev variable is set based on the global enforce_isolation module parameter during device initialization. In amdgpu_ids.c, the adev->enforce_isolation value for the current GPU is used to determine whether to enforce isolation between graphics and compute processes on that GPU. In amdgpu_ids.c, the adev->enforce_isolation value for the current GPU and partition is used to determine whether to enforce isolation between graphics and compute processes on that GPU and partition. This allows the enforce_isolation setting to be controlled individually for each GPU and each partition, which is useful in a system with multiple GPUs and partitions where different isolation settings might be desired for different GPUs and partitions. v2: fix loop in amdgpu_vmid_mgr_init() (Alex) Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher Suggested-by: Christian König

drm/amdgpu: handle enforce isolation on non-0 gfxhub

2024-08-16T18:27:28Z

Some chips have more than one gfxhub so check if we are a gfxhub rather than just gfxhub 0. Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: reject gang submit on reserved VMIDs

2024-07-08T20:50:53Z

A gang submit won't work if the VMID is reserved and we can't flush out VM changes from multiple engines at the same time. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: fix using the reserved VMID with gang submit

2024-06-19T16:48:00Z

We need to ensure that even when using a reserved VMID that the gang members can still run in parallel. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher