[AMD Official Use Only - General]
Series is Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Horatio Zhang
Sent: Monday, April 10, 2023 10:03 AM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Zhang, Horatio ;
Quan, Evan
Subject: [PATCH 1/2] drm/amd/pm: corr
Correct the max shader clock reporting on SMU
13.0.7.
Signed-off-by: Horatio Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 61 ++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
b/drivers/gpu/drm/amd
Correct the pstate standard/peak profiling mode clock
settings for SMU13.0.7.
Signed-off-by: Horatio Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 22 +--
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: Tom Rix
> Sent: Saturday, April 1, 2023 12:41 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; nat...@kernel.org;
> ndesaulni...@go
Hi Shashank,
I tried writing a program to experiment with usermode queues and I
found some weird behavior: The first run of the program works as
expected, while subsequent runs don't seem to do anything (and I
allocate everything in GTT, so it should be zero initialized
consistently). Is this a kn
On Wed, Mar 29, 2023 at 6:05 PM Shashank Sharma wrote:
>
> From: Shashank Sharma
>
> This patch adds:
> - A new IOCTL function to create and destroy
> - A new structure to keep all the user queue data in one place.
> - A function to generate unique index for the queue.
>
> V1: Worked on review co
On Wed, Mar 29, 2023 at 6:05 PM Shashank Sharma wrote:
>
> From: Arvind Yadav
>
> To support oversubscription, MES expects WPTR BOs to be mapped
> to GART, before they are submitted to usermode queues.
>
> Cc: Alex Deucher
> Cc: Christian Koenig
> Cc: Shashank Sharma
> Signed-off-by: Arvind Y
Update the existing log with DP LT downspread info:
[Downstream devices shall support down spreading of the link clock.
The down-spread amplitude shall either be disabled (0.0%) or up to 0.5%,
as written by the upstream device to the DOWNSPREAD_CTRL register
(DPCD 00107h). The modulation frequency
Instead of failing somewhere in the scheduler after the
ioctl has already succeeded.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2498
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 5 +
drivers
We need to introduce a new version of the info struct because
libdrm_amdgpu forgot any versioning info in amdgpu_query_hw_ip_info
so the mesa<->libdrm_amdgpu interface can't handle increasing the
size.
This info would be used by radv to figure out when we need to
split a submission into multiple s
We have a list of all rings, so no sense writing the same loop N
times. With how often this gets called and how small the ring list
is the performance of this shouldn't matter.
Note that some of the loops included some checking wrt harvesting.
That is redundant now, as those rings never get initia
On Sun, Apr 9, 2023, 5:50 PM Timur Kristóf wrote:
>
>
> Christian König ezt írta (időpont:
> 2023. ápr. 9., Vas 17:38):
>
>> Am 09.04.23 um 17:32 schrieb Bas Nieuwenhuizen:
>> > On Sun, Apr 9, 2023 at 5:30 PM Christian König
>> > wrote:
>> >> Am 09.04.23 um 16:44 schrieb Bas Nieuwenhuizen:
>> >
Am 09.04.23 um 17:32 schrieb Bas Nieuwenhuizen:
On Sun, Apr 9, 2023 at 5:30 PM Christian König
wrote:
Am 09.04.23 um 16:44 schrieb Bas Nieuwenhuizen:
We need to introduce a new version of the info struct because
libdrm_amdgpu forgot any versioning info in amdgpu_query_hw_ip_info
so the mesa<->
On Sun, Apr 9, 2023 at 5:30 PM Christian König
wrote:
>
> Am 09.04.23 um 16:44 schrieb Bas Nieuwenhuizen:
> > We need to introduce a new version of the info struct because
> > libdrm_amdgpu forgot any versioning info in amdgpu_query_hw_ip_info
> > so the mesa<->libdrm_amdgpu interface can't handle
Am 09.04.23 um 16:44 schrieb Bas Nieuwenhuizen:
We need to introduce a new version of the info struct because
libdrm_amdgpu forgot any versioning info in amdgpu_query_hw_ip_info
so the mesa<->libdrm_amdgpu interface can't handle increasing the
size.
Those are not forgotten, but simply unnecessa
We removed the GDS information because they were unnecessary. The GDS
size was already part of the device info before we added the shadow info.
But as far as I know the firmware needs valid VAs for all three buffers
or won't work correctly.
Christian.
Am 06.04.23 um 17:01 schrieb Marek Olšák
Instead of failing somewhere in the scheduler after the
ioctl has already succeeded.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2498
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 5 +
drivers
We need to introduce a new version of the info struct because
libdrm_amdgpu forgot any versioning info in amdgpu_query_hw_ip_info
so the mesa<->libdrm_amdgpu interface can't handle increasing the
size.
This info would be used by radv to figure out when we need to
split a submission into multiple s
We have a list of all rings, so no sense writing the same loop N
times. With how often this gets called and how small the ring list
is the performance of this shouldn't matter.
Note that some of the loops included some checking wrt harvesting.
That is redundant now, as those rings never get initia
19 matches
Mail list logo
