Add PP messages for reading/setting Fast PPT and Slow PPT limit.
Signed-off-by: Xiaomeng Hou
---
drivers/gpu/drm/amd/pm/inc/smu_types.h | 4
drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h | 6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/in
Implement hwmon API for reading/setting slow and fast PPT limit.
APU power is managed to system-level requirements through the PPT
(package power tracking) feature. PPT is intended to limit power to the
requirements of the power source and could be dynamically updated to
maximize APU performance w
For Vangogh, the offset values of some GC registers used in the
gfx_v10_0_setup_grbm_cam_remapping() function are not the same as those
of Sienna_Cichlid, so cannot be reused.
Although gfx_v10_0_setup_grbm_cam_remapping() is not called now for
Vangogh, it is necessary to implement this patch in ca
Hi all,
I have a deadlock with the amdgpu mainline driver when running in parallel two
OpenCL applications. So far, we've been able to replicate it easily by executing
clinfo and MatrixMultiplication (from AMD opencl-samples). It's quite old the
opencl-samples so, if you have any other suggestion
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:207:8-16: WARNING: use
scnprintf or sprintf.
./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:185:8-16: WARNING: use
scnprintf or sprintf.
./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:163:8-16: WARNING: use
scnprintf
Hi Daniel,
this is not a deadlock, but rather a hardware lockup.
Which OpenCl stack are you using?
Regards,
Christian.
Am 03.02.21 um 09:33 schrieb Daniel Gomez:
Hi all,
I have a deadlock with the amdgpu mainline driver when running in parallel two
OpenCL applications. So far, we've been abl
[AMD Public Use]
<> One minor comment below.
-Original Message-
From: Hou, Xiaomeng (Matthew)
Sent: Wednesday, February 3, 2021 1:55 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Deucher, Alexander
; Wang, Kevin(Yang) ; Lazar,
Lijo ; Hou, Xiaomeng (Matthew)
Subject: [PATCH 2/
On Wed, Feb 3, 2021 at 9:36 AM Christian König wrote:
>
> Hi Daniel,
>
> this is not a deadlock, but rather a hardware lockup.
Are you sure? Ime getting stuck in dma_fence_wait has generally good
chance of being a dma_fence deadlock. GPU hang should never result in
a forever stuck dma_fence.
Dan
Am 03.02.21 um 09:48 schrieb Daniel Vetter:
On Wed, Feb 3, 2021 at 9:36 AM Christian König wrote:
Hi Daniel,
this is not a deadlock, but rather a hardware lockup.
Are you sure? Ime getting stuck in dma_fence_wait has generally good
chance of being a dma_fence deadlock. GPU hang should never r
On Wed, 3 Feb 2021 at 09:51, Christian König wrote:
>
> Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > On Wed, Feb 3, 2021 at 9:36 AM Christian König
> > wrote:
> >> Hi Daniel,
> >>
> >> this is not a deadlock, but rather a hardware lockup.
> > Are you sure? Ime getting stuck in dma_fence_wait
Am 02.02.21 um 22:54 schrieb Alex Deucher:
The hw interface changed on arcturus so the old numbering
scheme doesn't work.
Signed-off-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 66 +--
1 file changed, 32 insertions(+), 3
On Wed, Feb 3, 2021 at 9:51 AM Christian König wrote:
>
> Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > On Wed, Feb 3, 2021 at 9:36 AM Christian König
> > wrote:
> >> Hi Daniel,
> >>
> >> this is not a deadlock, but rather a hardware lockup.
> > Are you sure? Ime getting stuck in dma_fence_wai
the soft gpu metrics is not asic related data structure.
unify them to reduce duplicate code.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/inc/smu_v11_0.h| 4 ---
drivers/gpu/drm/amd/pm/inc/smu_v12_0.h| 2 --
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 ++-
.../g
simplify the list opertion.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 541ef6be390f..659b385b27b5
On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 9:51 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > > On Wed, Feb 3, 2021 at 9:36 AM Christian König
> > > wrote:
> > >> Hi Daniel,
> > >>
> > >> this is not a deadlock, but rather
On Mon, Feb 01, 2021 at 03:21:35PM -0800, Brian Welty wrote:
>
> On 1/28/2021 7:00 PM, Xingyou Chen wrote:
> > On 2021/1/27 上午5:46, Brian Welty wrote:
> >
> >> We'd like to revisit the proposal of a GPU cgroup controller for managing
> >> GPU devices but with just a basic set of controls. This s
Enable Async DCS
V3:
1. add the flag to skip APU support.
2. remove the hunk for workload selection since
it doesn't impact the function.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 ++--
drivers/gpu/drm/amd/include/amd_shared.h
On 2/3/21 11:47 AM, Kenneth Feng wrote:
Enable Async DCS
Please expand the commit message, like v1/v2 of this patch.
Regards,
Nirmoy
V3:
1. add the flag to skip APU support.
2. remove the hunk for workload selection since
it doesn't impact the function.
Signed-off-by: Kenneth Feng
-
On Mon, Feb 01, 2021 at 11:51:07AM -0500, Kenny Ho wrote:
> [Resent in plain text.]
>
> On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter wrote:
> > - there's been a pile of cgroups proposal to manage gpus at the drm
> > subsystem level, some by Kenny, and frankly this at least looks a bit
> > lik
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
>
> On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 9:51 AM Christian König
> > wrote:
> > >
> > > Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > > > On Wed, Feb 3, 2021 at 9:36 AM Christian König
> > > > wrote
Am 03.02.21 um 12:45 schrieb Daniel Gomez:
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
On Wed, Feb 3, 2021 at 9:51 AM Christian König wrote:
Am 03.02.21 um 09:48 schrieb Daniel Vetter:
On Wed, Feb 3, 2021 at 9:36 AM Christian König wr
On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> > On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
> > > On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> > > > On Wed, Feb 3, 2021 at 9:51 AM Christian König
> > > > wrote:
> > >
Am 03.02.21 um 13:24 schrieb Daniel Vetter:
On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
Am 03.02.21 um 12:45 schrieb Daniel Gomez:
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
On Wed, Feb 3, 2021 at 9:51 AM Christian
The current code tries to read the brightness value via
dc_link_get_backlight_level() no matter whether it's controlled via
aux or not, and this results in a bogus value returned.
Fix it to read the current value via
dc_link_get_backlight_level_nits() for the aux.
BugLink: https://bugzilla.opensus
Hi,
here are two patches handling the issues in the backlight control.
The first one is to fix the sysfs brightness read for devices with the
backlight controlled by aux channel. The second one is to add a new
module option, aux_backlight, to forcibly enable/disable the aux
channel backlight cont
There seem devices that don't work with the aux channel backlight
control. For allowing such users to test with the other backlight
control method, provide a new module option, aux_backlight, to specify
enabling or disabling the aux backport support explicitly. As
default, the aux support is dete
Quoting Brian Welty (2021-01-26 23:46:24)
> Single control below is added to DRM cgroup controller in order to track
> user execution time for GPU devices. It is up to device drivers to
> charge execution time to the cgroup via drm_cgroup_try_charge().
>
> sched.runtime
> Read-only value,
Looks good to me. I see some more redundant code in that function, if
you want to clean it up further:
> hive = kzalloc(sizeof(*hive), GFP_KERNEL);
> if (!hive) {
> dev_err(adev->dev, "XGMI: allocation failed\n");
> hive = NULL;
No need to set hive to
On Wed, Feb 3, 2021 at 7:30 AM Christian König wrote:
>
> Am 03.02.21 um 13:24 schrieb Daniel Vetter:
> > On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> >> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> >>> On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
> On Wed, 3 Feb 20
[AMD Official Use Only - Internal Distribution Only]
thanks Felix,
I will continue to optimize related codes in the future.
Best Regards,
Kevin
From: Kuehling, Felix
Sent: Wednesday, February 3, 2021 9:53 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
On Wed, Feb 03, 2021 at 08:56:17AM -0500, Alex Deucher wrote:
> On Wed, Feb 3, 2021 at 7:30 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 13:24 schrieb Daniel Vetter:
> > > On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> > >> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> >
>>Uh, that doesn't work. If you want infinite compute queues you need the
amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
run forever, you just hang the kernel whenever userspace feels like. Not
just the gpu, the kernel (anything that allocates memory, irrespective of
proc
Hi Daniel,
I've talked a bit with our internal team.
The problem is that the 20.20 release still uses the older OpenCL stack
which obviously has a bug here and causes a hang.
The best approach I can give you is to switch to the ROCm stack instead.
Regards,
Christian.
Am 03.02.21 um 09:33 sc
On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
>
> >>Uh, that doesn't work. If you want infinite compute queues you need the
> amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
> run forever, you just hang the kernel whenever userspace feels like. Not
> just the gpu,
On Wed, 3 Feb 2021 at 15:37, Christian König wrote:
>
> Hi Daniel,
>
> I've talked a bit with our internal team.
>
> The problem is that the 20.20 release still uses the older OpenCL stack
> which obviously has a bug here and causes a hang.
>
> The best approach I can give you is to switch to the
To achieve the best QoS for high priority compute jobs it is
required to limit waves on other compute pipes as well.
This patch will set min value in non high priority
mmSPI_WCL_PIPE_PERCENT_CS[0-3] registers to minimize the
impact of normal/low priority compute jobs over high priority
compute jobs
On Wed, Feb 3, 2021 at 3:26 AM Xiaomeng Hou wrote:
>
> Add PP messages for reading/setting Fast PPT and Slow PPT limit.
>
> Signed-off-by: Xiaomeng Hou
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/pm/inc/smu_types.h | 4
> drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h | 6 +
On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> >
> > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
> > run forever, you just ha
On Wed, Feb 3, 2021 at 11:07 AM Nirmoy Das wrote:
>
> To achieve the best QoS for high priority compute jobs it is
> required to limit waves on other compute pipes as well.
> This patch will set min value in non high priority
> mmSPI_WCL_PIPE_PERCENT_CS[0-3] registers to minimize the
> impact of n
On 2/3/21 5:56 PM, Alex Deucher wrote:
On Wed, Feb 3, 2021 at 11:07 AM Nirmoy Das wrote:
To achieve the best QoS for high priority compute jobs it is
required to limit waves on other compute pipes as well.
This patch will set min value in non high priority
mmSPI_WCL_PIPE_PERCENT_CS[0-3] regis
To achieve the best QoS for high priority compute jobs it is
required to limit waves on other compute pipes as well.
This patch will set min value in non high priority
mmSPI_WCL_PIPE_PERCENT_CS[0-3] registers to minimize the
impact of normal/low priority compute jobs over high priority
compute jobs
On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
>
> On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> > >
> > > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > > amdkfd model with preempt-ctx dma_f
On Wed, Feb 3, 2021 at 6:14 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
> >
> > On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John
> > > wrote:
> > > >
> > > > >>Uh, that doesn't work. If you want in
Add a new helper function for printing Topology values to support
printing 64-bit hex values. Use this for unique_id to ensure that the
unique_id in KFD's topology matches the one in amdgpu's sysfs pool.
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 +++-
1 file c
Instead of caching the value during amdgpu_device_init, just call the
function directly. This avoids issues where the unique_id hasn't been
saved by the time that KFD's topology snapshot is done (e.g. Arcturus).
KFD's topology information from the amdgpu_device was initially cached
at KFD initiali
Doesn't this break the ABI?
Am 2021-02-03 um 1:22 p.m. schrieb Kent Russell:
> Add a new helper function for printing Topology values to support
> printing 64-bit hex values. Use this for unique_id to ensure that the
> unique_id in KFD's topology matches the one in amdgpu's sysfs pool.
>
> Signed-
[AMD Public Use]
Indeed it will. Consider this dropped, as no one was asking for it anyways.
Kent
> -Original Message-
> From: Kuehling, Felix
> Sent: Wednesday, February 3, 2021 1:38 PM
> To: Russell, Kent ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdkfd: Print uniqu
Instead of caching the value during amdgpu_device_init, just call the
function directly. This avoids issues where the unique_id hasn't been
saved by the time that KFD's topology snapshot is done (e.g. Arcturus).
KFD's topology information from the amdgpu_device was initially cached
at KFD initiali
Am 2021-02-03 um 1:47 p.m. schrieb Kent Russell:
> Instead of caching the value during amdgpu_device_init, just call the
> function directly. This avoids issues where the unique_id hasn't been
> saved by the time that KFD's topology snapshot is done (e.g. Arcturus).
>
> KFD's topology information f
Daniel,
I will have to get back to you later on the details of this because my
head is currently context switched to some infrastructure and
Kubernetes/golang work, so I am having a hard time digesting what you
are saying. I am new to the bpf stuff so this is about my own
learning as well as a co
This reverts commit 4a3dea8932d3b1199680d2056dd91d31d94d70b7.
This causes blank screens for some users.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1388
Cc: Alvin Lee
Cc: Jun Lei
Cc: Rodrigo Siqueira
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource
On Wed, Feb 3, 2021 at 3:30 AM chen gong wrote:
>
> For Vangogh, the offset values of some GC registers used in the
> gfx_v10_0_setup_grbm_cam_remapping() function are not the same as those
> of Sienna_Cichlid, so cannot be reused.
>
> Although gfx_v10_0_setup_grbm_cam_remapping() is not called no
On 2/3/2021 5:25 AM, Joonas Lahtinen wrote:
> Quoting Brian Welty (2021-01-26 23:46:24)
>> Single control below is added to DRM cgroup controller in order to track
>> user execution time for GPU devices. It is up to device drivers to
>> charge execution time to the cgroup via drm_cgroup_try_char
Alex Deucher writes:
> On Wed, Feb 3, 2021 at 3:36 AM Dave Young wrote:
>>
>> Hi Baoquan,
>>
>> Thanks for ccing.
>> On 01/28/21 at 01:29pm, Baoquan He wrote:
>> > On 01/11/21 at 01:17pm, Alexander E. Patrakov wrote:
>> > > Hello,
>> > >
>> > > I was trying out kexec on my new laptop, which is a
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Kevin Wang
Sent: Wednesday, February 3, 2021 4:29 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, Kevin(Yang)
Subject: [PATCH] drm/amd/pm/swsmu: unify th
Enable DCS
V1: Enable Async DCS.
V2: Add the ppfeaturemask bit to enable from the modprobe parameter.
V3:
1. add the flag to skip APU support.
2. remove the hunk for workload selection since
it doesn't impact the function.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
On Wed, Feb 3, 2021 at 10:32 PM Kenneth Feng wrote:
>
> Enable DCS
>
> V1: Enable Async DCS.
> V2: Add the ppfeaturemask bit to enable from the modprobe parameter.
> V3:
> 1. add the flag to skip APU support.
> 2. remove the hunk for workload selection since
> it doesn't impact the function.
>
> S
Hi Dave, Daniel,
Fixes for 5.11.
The following changes since commit e0ecafede87eb1a3d1e708f0365fad0d59489285:
Merge tag 'amd-drm-fixes-5.11-2021-01-28' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-01-29 11:36:38
+1000)
are available in the Git repository at:
https:/
On Wed, Feb 3, 2021 at 7:56 PM Eric W. Biederman wrote:
>
> Alex Deucher writes:
>
> > On Wed, Feb 3, 2021 at 3:36 AM Dave Young wrote:
> >>
> >> Hi Baoquan,
> >>
> >> Thanks for ccing.
> >> On 01/28/21 at 01:29pm, Baoquan He wrote:
> >> > On 01/11/21 at 01:17pm, Alexander E. Patrakov wrote:
> >
Hi Dave, Daniel,
More fixes for 5.12. Same PR from last week with the issue Felix reported
fixed and a few more additional fixes on top.
The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0:
Merge tag 'amd-drm-next-5.12-2021-01-20' of
https://gitlab.freedesktop.org/agd
60 matches
Mail list logo
