From a20a91fb1bfac5d05ec5bcf9afe0c9363f6c8c93 Mon Sep 17 00:00:00 2001 From: Antonino Maniscalco Date: Thu, 3 Oct 2024 18:13:01 +0200 Subject: Documentation: document adreno preemption Add documentation about the preemption feature supported by the msm driver. Signed-off-by: Antonino Maniscalco Patchwork: https://patchwork.freedesktop.org/patch/618032/ Signed-off-by: Rob Clark --- Documentation/gpu/msm-preemption.rst | 99 ++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/gpu/msm-preemption.rst (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/msm-preemption.rst b/Documentation/gpu/msm-preemption.rst new file mode 100644 index 000000000000..d768ca09fdec --- /dev/null +++ b/Documentation/gpu/msm-preemption.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:orphan: + +============== +MSM Preemption +============== + +Preemption allows Adreno GPUs to switch to a higher priority ring when work is +pushed to it, reducing latency for high priority submissions. + +When preemption is enabled 4 rings are initialized, corresponding to different +priority levels. Having multiple rings is purely a software concept as the GPU +only has registers to keep track of one graphics ring. +The kernel is able to switch which ring is currently being processed by +requesting preemption. When certain conditions are met, depending on the +priority level, the GPU will save its current state in a series of buffers, +then restores state from a similar set of buffers specified by the kernel. It +then resumes execution and fires an IRQ to let the kernel know the context +switch has completed. + +This mechanism can be used by the kernel to switch between rings. Whenever a +submission occurs the kernel finds the highest priority ring which isn't empty +and preempts to it if said ring is not the one being currently executed. This is +also done whenever a submission completes to make sure execution resumes on a +lower priority ring when a higher priority ring is done. + +Preemption levels +----------------- + +Preemption can only occur at certain boundaries. The exact conditions can be +configured by changing the preemption level, this allows to compromise between +latency (ie. the time that passes between when the kernel requests preemption +and when the SQE begins saving state) and overhead (the amount of state that +needs to be saved). + +The GPU offers 3 levels: + +Level 0 + Preemption only occurs at the submission level. This requires the least amount + of state to be saved as the execution of userspace submitted IBs is never + interrupted, however it offers very little benefit compared to not enabling + preemption of any kind. + +Level 1 + Preemption occurs at either bin level, if using GMEM rendering, or draw level + in the sysmem rendering case. + +Level 2 + Preemption occurs at draw level. + +Level 1 is the mode that is used by the msm driver. + +Additionally the GPU allows to specify a `skip_save_restore` option. This +disables the saving and restoring of all registers except those relating to the +operation of the SQE itself, reducing overhead. Saving and restoring is only +skipped when using GMEM with Level 1 preemption. When enabling this userspace is +expected to set the state that isn't preserved whenever preemption occurs which +is done by specifying preamble and postambles. Those are IBs that are executed +before and after preemption. + +Preemption buffers +------------------ + +A series of buffers are necessary to store the state of rings while they are not +being executed. There are different kinds of preemption records and most of +those require one buffer per ring. This is because preemption never occurs +between submissions on the same ring, which always run in sequence when the ring +is active. This means that only one context per ring is effectively active. + +SMMU_INFO + This buffer contains info about the current SMMU configuration such as the + ttbr0 register. The SQE firmware isn't actually able to save this record. + As a result SMMU info must be saved manually from the CP to a buffer and the + SMMU record updated with info from said buffer before triggering + preemption. + +NON_SECURE + This is the main preemption record where most state is saved. It is mostly + opaque to the kernel except for the first few words that must be initialized + by the kernel. + +SECURE + This saves state related to the GPU's secure mode. + +NON_PRIV + The intended purpose of this record is unknown. The SQE firmware actually + ignores it and therefore msm doesn't handle it. + +COUNTER + This record is used to save and restore performance counters. + +Handling the permissions of those buffers is critical for security. All but the +NON_PRIV records need to be inaccessible from userspace, so they must be mapped +in the kernel address space with the MSM_BO_MAP_PRIV flag. +For example, making the NON_SECURE record accessible from userspace would allow +any process to manipulate a saved ring's RPTR which can be used to skip the +execution of some packets in a ring and execute user commands with higher +privileges. -- cgit v1.2.3 From 59579829743239e387fff568809512ca34677f19 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Fri, 11 Oct 2024 17:41:10 -0400 Subject: drm/i915: Fix irq related documentation Also update the function names in the documentation. Closes: https://lore.kernel.org/intel-gfx/20241001134331.7b4d4ca5@canb.auug.org.au/ Reported-by: Stephen Rothwell Fixes: 3de5774cb8c0 ("drm/i915/irq: Rename suspend/resume functions") Cc: Jonathan Cavitt Cc: Andi Shyti Reviewed-by: Jonathan Cavitt Reviewed-by: Krzysztof Karas Reviewed-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20241011214111.98128-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi --- Documentation/gpu/i915.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index ad59ae579237..7a469df675d8 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -35,10 +35,10 @@ Interrupt Handling :functions: intel_irq_init intel_irq_init_hw intel_hpd_init .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_disable_interrupts + :functions: intel_irq_suspend .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_enable_interrupts + :functions: intel_irq_resume Intel GVT-g Guest Support(vGPU) ------------------------------- -- cgit v1.2.3 From cfffd980bf21b5a84fd364861d482d5a2ec21c49 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Wolfgang=20M=C3=BCller?= Date: Tue, 29 Oct 2024 12:17:52 +0100 Subject: drm/amd/pm: add zero RPM OD setting support for SMU13 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Whilst we have support for setting fan curves there is no support for disabling the zero RPM feature. Since the relevant bits are already present in the OverDriveTable, hook them up to a sysctl setting so users can influence this behaviour. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3489 Reviewed-by: Kenneth Feng Signed-off-by: Wolfgang Müller Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/thermal.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst index 6d942b5c58f0..ec6c1f1d5a4a 100644 --- a/Documentation/gpu/amdgpu/thermal.rst +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -100,6 +100,12 @@ fan_minimum_pwm .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: fan_minimum_pwm +fan_zero_rpm_enable +---------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: fan_zero_rpm_enable + GFXOFF ====== -- cgit v1.2.3 From 6bfe777e9267ee6d1c4712b52bb5d32e59508a3d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Wolfgang=20M=C3=BCller?= Date: Tue, 29 Oct 2024 12:17:53 +0100 Subject: drm/amd/pm: add zero RPM stop temperature OD setting support for SMU13 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Together with the feature to enable or disable zero RPM in the last commit, it also makes sense to expose the OD setting determining under which temperature the fan should stop if zero RPM is enabled. Reviewed-by: Kenneth Feng Signed-off-by: Wolfgang Müller Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/thermal.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst index ec6c1f1d5a4a..1768a106aab1 100644 --- a/Documentation/gpu/amdgpu/thermal.rst +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -106,6 +106,12 @@ fan_zero_rpm_enable .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: fan_zero_rpm_enable +fan_zero_rpm_stop_temperature +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: fan_zero_rpm_stop_temperature + GFXOFF ====== -- cgit v1.2.3 From 5954cfa812f4f5850cf0246c499a6dc256196b01 Mon Sep 17 00:00:00 2001 From: Srinivasan Shanmugam Date: Wed, 6 Nov 2024 19:25:50 +0530 Subject: drm/amdgpu: Add documentation for enforce isolation feature MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This feature enables process isolation on the graphics engine by serializing access to it and adding a cleaner shader which clears LDS (Local Data Store) and GPRs (General Purpose Registers) between jobs. Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Suggested-by: Alex Deucher Suggested-by: Asad Kamal Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/index.rst | 1 + Documentation/gpu/amdgpu/process-isolation.rst | 59 ++++++++++++++++++++++++++ 2 files changed, 60 insertions(+) create mode 100644 Documentation/gpu/amdgpu/process-isolation.rst (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 847e04924030..302d039928ee 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -16,4 +16,5 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. thermal driver-misc debugging + process-isolation amdgpu-glossary diff --git a/Documentation/gpu/amdgpu/process-isolation.rst b/Documentation/gpu/amdgpu/process-isolation.rst new file mode 100644 index 000000000000..6b6d70e357a7 --- /dev/null +++ b/Documentation/gpu/amdgpu/process-isolation.rst @@ -0,0 +1,59 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= + AMDGPU Process Isolation +========================= + +The AMDGPU driver includes a feature that enables automatic process isolation on the graphics engine. This feature serializes access to the graphics engine and adds a cleaner shader which clears the Local Data Store (LDS) and General Purpose Registers (GPRs) between jobs. All processes using the GPU, including both graphics and compute workloads, are serialized when this feature is enabled. On GPUs that support partitionable graphics engines, this feature can be enabled on a per-partition basis. + +In addition, there is an interface to manually run the cleaner shader when the use of the GPU is complete. This may be preferable in some use cases, such as a single-user system where the login manager triggers the cleaner shader when the user logs out. + +Process Isolation +================= + +The `run_cleaner_shader` and `enforce_isolation` sysfs interfaces allow users to manually execute the cleaner shader and control the process isolation feature, respectively. + +Partition Handling +------------------ + +The `enforce_isolation` file in sysfs can be used to enable process isolation and automatic shader cleanup between processes. On GPUs that support graphics engine partitioning, this can be enabled per partition. The partition and its current setting (0 disabled, 1 enabled) can be read from sysfs. On GPUs that do not support graphics engine partitioning, only a single partition will be present. Writing 1 to the partition position enables enforce isolation, writing 0 disables it. + +Example of enabling enforce isolation on a GPU with multiple partitions: + +.. code-block:: console + + $ echo 1 0 1 0 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 0 1 0 + +The output indicates that enforce isolation is enabled on zeroth and second parition and disabled on first and fourth parition. + +For devices with a single partition or those that do not support partitions, there will be only one element: + +.. code-block:: console + + $ echo 1 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 + +Cleaner Shader Execution +======================== + +The driver can trigger a cleaner shader to clean up the LDS and GPR state on the graphics engine. When process isolation is enabled, this happens automatically between processes. In addition, there is a sysfs file to manually trigger cleaner shader execution. + +To manually trigger the execution of the cleaner shader, write `0` to the `run_cleaner_shader` sysfs file: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader + +For multi-partition devices, you can specify the partition index when triggering the cleaner shader: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 0 + $ echo 1 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 1 + $ echo 2 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 2 + # ... and so on for each partition + +This command initiates the cleaner shader, which will run and complete before any new tasks are scheduled on the GPU. -- cgit v1.2.3