kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h, branch v6.6.132

drm/amdgpu: add VM generation token

2023-06-15T15:37:55+00:00

Instead of using the VRAM lost counter add a 64bit token which indicates if a context or job is still valid to use. Should the VRAM be lost or the page tables need re-creation the token will change indicating that userspace needs to act and re-create the contexts and re-submit the work. Signed-off-by: Christian König Reviewed-by: Luben Tuikov Signed-off-by: Alex Deucher

drm/amdgpu: keep amdgpu_ctx_mgr in ctx structure

2023-06-09T13:59:37+00:00

Keep amdgpu_ctx_mgr in ctx structure to track fpriv. v2: add missing fpriv declaration lost in rebase Signed-off-by: James Zhu Acked-by: Lijo Lazar Signed-off-by: Alex Deucher

drm/amdgpu: revert "partial revert "remove ctx->lock" v2"

2022-09-13T18:33:01+00:00

This reverts commit 94f4c4965e5513ba624488f4b601d6b385635aec. We found that the bo_list is missing a protection for its list entries. Since that is fixed now this workaround can be removed again. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: Convert to common fdinfo format v5

2022-05-26T18:56:34+00:00

Convert fdinfo format to one documented in drm-usage-stats.rst. It turned out that the existing implementation was actually completely nonsense. The calculated percentages indeed represented the usage of the engine, but with varying time slices. So 10% usage for application A could mean something completely different than 10% usage for application B. Completely nuke that and just use the now standardized nanosecond interface. v2: drop the documentation change for now, nuke percentage calculation v3: only account for each hw_ip, move the time_spend to the ctx mgr. v4: move general ctx changes into separate patch, rework the fdinfo to ctx_mgr interface so that all usages are calculated at once, drop some unecessary and dangerous refcount dance. v5: add one more comment how we calculate the time spend Signed-off-by: Tvrtko Ursulin Signed-off-by: Christian König Reviewed-by: Shashank Sharma Cc: Daniel Vetter Signed-off-by: Alex Deucher

drm/amdgpu: cleanup ctx implementation

2022-05-26T18:56:31+00:00

Let each context have a pointer to the ctx manager and properly initialize the adev pointer inside the context manager. Reduce the BUG_ON() in amdgpu_ctx_add_fence() into a WARN_ON() and directly return the sequence number instead of writing into a parmeter. Signed-off-by: Christian König Reviewed-by: Shashank Sharma Signed-off-by: Alex Deucher

drm/amdgpu: partial revert "remove ctx->lock" v2

2022-04-21T09:26:20+00:00

This reverts commit 461fa7b0ac565ef25c1da0ced31005dd437883a7. We are missing some inter dependencies here so re-introduce the lock until we have figured out what's missing. Just drop/retake it while adding dependencies. v2: still drop the lock while adding dependencies Signed-off-by: Christian König Tested-by: Mikhail Gavrilov (v1) Fixes: 461fa7b0ac56 ("drm/amdgpu: remove ctx->lock") Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20220419110633.166236-1-christian.koenig@amd.com

drm/amdgpu: remove ctx->lock

2022-02-11T21:19:23+00:00

KMD reports a warning on holding a lock from drm_syncobj_find_fence, when running amdgpu_test case “syncobj timeline test”. ctx->lock was designed to prevent concurrent "amdgpu_ctx_wait_prev_fence" calls and avoid dead reservation lock from GPU reset. since no reservation lock is held in latest GPU reset any more, ctx->lock can be simply removed and concurrent "amdgpu_ctx_wait_prev_fence" call also can be prevented by PD root bo reservation lock. call stacks: ================= //hold lock amdgpu_cs_ioctl->amdgpu_cs_parser_init->mutex_lock(&parser->ctx->lock); … //report warning amdgpu_cs_dependencies->amdgpu_cs_process_syncobj_timeline_in_dep \ ->amdgpu_syncobj_lookup_and_add_to_sync -> drm_syncobj_find_fence \ -> lockdep_assert_none_held_once … amdgpu_cs_ioctl->amdgpu_cs_parser_fini->mutex_unlock(&parser->ctx->lock); Signed-off-by: Ken Xue Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu/UAPI: add new CTX OP to get/set stable pstates

2022-01-27T20:50:08+00:00

Add a new CTX ioctl operation to set stable pstates for profiling. When creating traces for tools like RGP or using SPM or doing performance profiling, it's required to enable a special stable profiling power state on the GPU. These profiling states set fixed clocks and disable certain other power features like powergating which may impact the results. Historically, these profiling pstates were enabled via sysfs, but this adds an interface to enable it via the CTX ioctl from the application. Since the power state is global only one application can set it at a time, so if multiple applications try and use it only the first will get it, the ioctl will return -EBUSY for others. The sysfs interface will override whatever has been set by this interface. Mesa MR: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/207 v2: don't default r = 0; v3: rebase on Evan's PM cleanup Reviewed-by: Evan Quan Signed-off-by: Alex Deucher

drm/amdgpu: rework context priority handling

2021-09-01T20:55:11+00:00

To get a hardware queue priority for a context, we are currently mapping AMDGPU_CTX_PRIORITY_* to DRM_SCHED_PRIORITY_* and then to hardware queue priority, which is not the right way to do that as DRM_SCHED_PRIORITY_* is software scheduler's priority and it is independent from a hardware queue priority. Use userspace provided context priority, AMDGPU_CTX_PRIORITY_* to map a context to proper hardware queue priority. Signed-off-by: Nirmoy Das Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: fix fence calculation (v2)

2021-05-13T18:09:12+00:00

The proper metric for fence utilization over several contexts is an harmonic mean, but such calculation is prohibitive in kernel space, so the code approximates it. Because the approximation diverges when one context has a very small ratio compared with the other context, this change filter out ratios smaller that 0.01% v2: make the fence calculation static and initialize variables within that function v3: Fix warnings (Alex) Reviewed-by: Alex Deucher Signed-off-by: David M Nieto Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20210513174539.27409-2-david.nieto@amd.com