On 9/19/25 06:49, Louis Chauvet wrote:
Le 18/09/2025 à 02:45, Alex Hung a écrit :
On 9/17/25 08:47, Nícolas F. R. A. Prado wrote:
On Tue, 2025-09-16 at 19:54 -0600, Alex Hung wrote:
On 9/5/25 11:12, Louis Chauvet wrote:
Le 15/08/2025 à 05:50, Alex Hung a écrit :
From: Harry Wentla
On 2025-09-17 15:49, Melissa Wen wrote:
>
>
> On 12/09/2025 15:50, Harry Wentland wrote:
>>
>> On 2025-09-11 13:21, Melissa Wen wrote:
>>> Don't update DC stream color components during atomic check. The driver
>>> will continue validating the new CRTC color state but will not change DC
>>> st
On Fri, Sep 19, 2025 at 4:19 AM Prike Liang wrote:
>
> When a user unmaps a userq VA, the driver must ensure
> the queue has no in-flight jobs. If there is pending work,
> the kernel should wait for the attached eviction (bookkeeping)
> fence to signal before deleting the mapping.
>
> Suggested-by
This reverts commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280.
since we are going to revert commit 5307dce878d4 ("drm/gem: Acquire
references on GEM handles for framebuffers"), which it was fixing, this
commit won't be needed anymore.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_framebuffe
On Fri, Sep 19, 2025 at 4:11 AM Prike Liang wrote:
>
> Keeping waiting the userq fence infinitely until
> hang detection, and then suspend the hang queue and
> set the fence error.
>
> Signed-off-by: Prike Liang
Patches 1-4 are:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/am
Hi Dave, Simona,
Updates for 6.18.
The following changes since commit 2fd653b9bb5aacec5d4c421ab290905898fe85a2:
drm/amd/display: Drop dm_prepare_suspend() and dm_complete() (2025-09-05
17:38:42 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On Fri, Sep 19, 2025 at 4:19 AM Prike Liang wrote:
>
> It requires validating the userq VA whether is mapped before
> trying to resume the queue.
>
> Signed-off-by: Prike Liang
> Reviewed-by: Christian König
> Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 29 +++
On Fri, Sep 19, 2025 at 2:54 AM Prike Liang wrote:
>
> It should return an error code if userq VA validation fails.
>
> Fixes: 9e46b8bb0539 ("drm/amdgpu: validate userq buffer virtual
> address and size")
>
> Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amd
On Fri, Sep 19, 2025 at 4:29 AM Prike Liang wrote:
>
> From: Alex Deucher
>
> Query the status of the user queue, currently whether
> the queue is hung and whether or not VRAM is lost.
>
> v2: Misc cleanups
>
> Reviewed-by: Sunil Khatri
> Signed-off-by: Alex Deucher
> Reviewed-by: Prike Liang
On Fri, Sep 19, 2025 at 4:14 AM Timur Kristóf wrote:
>
> Mark YUV422 unsupported over DP on DCE to work around a
> regression caused by the recent YUV422 fallback patch.
>
> See https://gitlab.freedesktop.org/drm/amd/-/issues/4585
>
> The recent YUV422 fallback breaks DisplayPort on DCE6-10 becaus
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Leo Liu
> -Original Message-
> From: amd-gfx On Behalf Of
> Sonny Jiang
> Sent: September 18, 2025 1:13 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Jiang, Sonny
> Subject: [PATCH] drm/amdgpu: Update amdgpu_vcn5_fw_s
Hi all,
I just talked with Thomas that these two patches are preventing amdgpu
driver to be unloaded:
`modprobe: FATAL: Module amdgpu is in use.`
and there is no process using the driver.
We agreed that the best approach now is to completely revert the work
done for improving DMA bug handling t
On Fri, Sep 19, 2025 at 8:21 AM Christian König
wrote:
>
> Initially we enforced isolation by reserving a VMID, but that practice
> was now removed.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 5 -
> 1 file changed, 5 deletio
On Fri, Sep 19, 2025 at 8:29 AM Christian König
wrote:
>
> This reverts commit e44a0fe630c58b0a87d8281f5c1077a3479e5fce.
>
> Initially we used VMID reservation to enforce isolation between
> processes. That has now been replaced by proper fence handling.
>
> Both OpenGL, RADV and ROCm developers r
On Fri, 2025-09-19 at 11:09 -0400, Alex Deucher wrote:
> On Fri, Sep 19, 2025 at 4:14 AM Timur Kristóf
> wrote:
> >
> > Mark YUV422 unsupported over DP on DCE to work around a
> > regression caused by the recent YUV422 fallback patch.
> >
> > See https://gitlab.freedesktop.org/drm/amd/-/issues/4
On Thu, Sep 18, 2025 at 8:55 PM Chai, Thomas wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Friday, September 19, 2025 4:05 AM
> To: Chai, Thomas
> Cc: amd-gfx@lists.freedesktop.org; Zhang, H
GPUs typically benefit from contiguous memory via reduced TLB pressure and
improved caching performance, where the maximum size of contiguous block
which adds a performance benefit is related to hardware design.
TTM pool allocator by default tries (hard) to allocate up to the system
MAX_PAGE_ORDER
Let the TTM pool allocator know that we can afford for it to expend less
effort for satisfying contiguous allocations larger than 2MiB. The latter
is the maximum relevant PTE entry size and the driver and hardware are
happy to get larger blocks only opportunistically.
Signed-off-by: Tvrtko Ursulin
Following the discussion from:
https://lore.kernel.org/dri-devel/7c6a3aa0-c1eb-4726-988a-460c4895f...@amd.com/T/#m32a0260769a0ffb2f114d00066ef3bfda91f9fd6
Idea being that we can afford with no performance benefit to try less hard when
allocating contiguous backing store larger than the size whi
On Thu, Sep 18, 2025 at 9:04 PM Mario Limonciello (AMD)
wrote:
>
> From: Mario Limonciello
>
> The MES set resources packet has an optional bit 'lr_compute_wa'
> which can be used for preventing MES hangs on long compute jobs.
>
> Set this bit by default.
>
> Co-developed-by: Yifan Zhang
> Signe
Le 18/09/2025 à 02:45, Alex Hung a écrit :
On 9/17/25 08:47, Nícolas F. R. A. Prado wrote:
On Tue, 2025-09-16 at 19:54 -0600, Alex Hung wrote:
On 9/5/25 11:12, Louis Chauvet wrote:
Le 15/08/2025 à 05:50, Alex Hung a écrit :
From: Harry Wentland
This patch introduces a VKMS color pi
With this modification it builds:
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index a375f4a65acf..a0ca28a253d2 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -13,7 +13,6 @@
#include
#include "vkm
This reverts commit e44a0fe630c58b0a87d8281f5c1077a3479e5fce.
Initially we used VMID reservation to enforce isolation between
processes. That has now been replaced by proper fence handling.
Both OpenGL, RADV and ROCm developers requested a way to reserve a VMID
for SPM, so restore that approach b
On 19.09.25 12:42, Tvrtko Ursulin wrote:
>
> On 19/09/2025 11:17, Christian König wrote:
>> On 19.09.25 10:46, Tvrtko Ursulin wrote:
>>>
>>> On 19/09/2025 09:01, Christian König wrote:
On 19.09.25 09:43, Tvrtko Ursulin wrote:
> On 19/09/2025 07:46, Christian König wrote:
>> On 18.09.2
On 19/09/2025 11:17, Christian König wrote:
On 19.09.25 10:46, Tvrtko Ursulin wrote:
On 19/09/2025 09:01, Christian König wrote:
On 19.09.25 09:43, Tvrtko Ursulin wrote:
On 19/09/2025 07:46, Christian König wrote:
On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
On certain workload
From: Dillon Varone
[WHY&HOW]
This is a redundant field that is identically to optimized_required, so
just replace it.
Reviewed-by: Nicholas Kazlauskas
Reviewed-by: Aurabindo Pillai
Signed-off-by: Dillon Varone
Signed-off-by: Ivan Lipski
---
drivers/gpu/drm/amd/display/dc/core/dc.c
Now with drm_writeback_connector moved to drm_connector it makes
more sense use drm_connector as an argument rather than drm_connector.
The writeback connector can easily be derived from drm_connector.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c | 2 +-
...
On Wed, Sep 10, 2025 at 7:37 AM Prike Liang wrote:
>
> From: Alex Deucher
>
> Add an API to query queue status such as whether the
> queue is hung or whether vram is lost.
>
We need mesa code before we can land this new interface.
Alex
> Reviewed-by: Christian König
> Reviewed-by: Sunil Khatr
[Public]
> Hiding this information seems unreasonable unless there is another strong
> reason
This interface version is not used anywhere. Driver ensures backward
compatibility by PMFW version checks and shows the exact PMFW version in dmesg
log. PMFW version is a more authentic way to identif
The CSB buffer manipulation occurs in memory where the BO is mapped
during initialization, and some references to this buffer are handled
with volatile, which is incorrect in this scenario. There are a few
cases where the use of volatile is accepted, but none of them align with
CSB operations. Ther
On 19.09.25 13:13, Thadeu Lima de Souza Cascardo wrote:
>>>
The alternative I can offer is to disable the fallback which in your case
would trigger the OOM killer.
>
> Warning could be as simple as removing __GFP_NOWARN. But I don't think we
> want either a warning or to trigger th
Many callers of pci_rebar_get_possible_sizes() are interested in
finding out if a particular BAR Size (PCIe r6.2 sec. 7.8.6.3) is
supported by the particular BAR.
Add pci_rebar_size_supported() into PCI core to make it easy for the
drivers to determine if the BAR Size is supported or not.
Use the
On 09.09.25 16:49, Timur Kristóf wrote:
> SDMA v3-v5 can copy almost 4 MiB in a single copy operation.
> Use the same value as PAL and Mesa for copy_max_bytes.
>
> For reference, see oss2DmaCmdBuffer.cpp in PAL:
> "Due to HW limitation, the maximum count may not be 2^n-1,
> can only be
On 19.09.25 10:46, Tvrtko Ursulin wrote:
>
> On 19/09/2025 09:01, Christian König wrote:
>> On 19.09.25 09:43, Tvrtko Ursulin wrote:
>>> On 19/09/2025 07:46, Christian König wrote:
On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
> On certain workloads, like on ChromeOS when openin
Normally resources are evicted on dGPUs at suspend or hibernate and
on APUs at hibernate. These steps are unnecessary when using the S4
callbacks to put the system into S5.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Acked-by:
SDMA 5.2.x has increased transfer limits.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
index a8e39df29f343..da19d9384
On 12.09.25 16:08, Alex Deucher wrote:
> On Fri, Sep 12, 2025 at 10:06 AM Christian König
> wrote:
>>
>> On 12.09.25 15:02, Alex Deucher wrote:
>>> On Fri, Sep 12, 2025 at 7:17 AM Christian König
>>> wrote:
On 12.09.25 11:31, Jesse.Zhang wrote:
> The current user queue implementatio
On 19/09/2025 07:46, Christian König wrote:
On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
On certain workloads, like on ChromeOS when opening multiple tabs and
windows, and switching desktops, memory pressure can build up and latency
is observed as high order allocations result in me
On 19.09.25 10:11, Prike Liang wrote:
> Add the userq object virtual address list_add(),mapped()
> and list_del() helpers for tracking the userq obj va address
> usage.
>
> Signed-off-by: Prike Liang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgp
Mark YUV422 unsupported over DP on DCE to work around a
regression caused by the recent YUV422 fallback patch.
See https://gitlab.freedesktop.org/drm/amd/-/issues/4585
The recent YUV422 fallback breaks DisplayPort on DCE6-10 because
it can select a high refresh rate mode with YUV422 and 6 BPC,
wh
On 19/09/2025 09:01, Christian König wrote:
On 19.09.25 09:43, Tvrtko Ursulin wrote:
On 19/09/2025 07:46, Christian König wrote:
On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
On certain workloads, like on ChromeOS when opening multiple tabs and
windows, and switching desktops, memo
Add helpers to map/unmap a hardware MMIO register window (PCI BAR) as a
1-entry sg_table using dma_map_resource()/dma_unmap_resource(). This
will be used by MMIO_REMAP.
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 51
It requires validating the userq VA whether is mapped before
trying to resume the queue.
Signed-off-by: Prike Liang
Reviewed-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 29 ++-
1 file changed, 28 insertions(+), 1 deletion(-)
Track the userq obj for its life time, and reference and
dereference the buffer flag at its creating and destroying
period.
Suggested-by: Alex Deucher
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 28 +++
1 file changed, 28 insertions(+)
diff --
Hi Matthew,
I have added a new performance test case in this version, Could you
please take a look and provide RB.
It is important to get these patches upstream soon.
Thanks,
Arun.
On 9/9/2025 3:26 PM, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management
When a user unmaps a userq VA, the driver must ensure
the queue has no in-flight jobs. If there is pending work,
the kernel should wait for the attached eviction (bookkeeping)
fence to signal before deleting the mapping.
Suggested-by: Christian König
Signed-off-by: Prike Liang
---
drivers/gpu/d
Add the userq flag to identify the invalid userq cases.
Signed-off-by: Prike Liang
---
include/uapi/drm/amdgpu_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 871e0f56d61e..100ccee37d5c 100644
--- a/include/uapi/drm/
Add the userq invalid VA query interface.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 8ac7236091fa..a5e7e279b78e 100644
From: Alex Deucher
Query the status of the user queue, currently whether
the queue is hung and whether or not VRAM is lost.
v2: Misc cleanups
Reviewed-by: Sunil Khatri
Signed-off-by: Alex Deucher
Reviewed-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 35 +++
From: Alex Deucher
Add an API to query queue status such as whether the
queue is hung or whether vram is lost.
Reviewed-by: Christian König
Reviewed-by: Sunil Khatri
Signed-off-by: Alex Deucher
Reviewed-by: Prike Liang
---
include/uapi/drm/amdgpu_drm.h | 14 ++
1 file changed, 1
Keeping waiting the userq fence infinitely until
hang detection, and then suspend the hang queue and
set the fence error.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/a
Add the userq object virtual address list_add(),mapped()
and list_del() helpers for tracking the userq obj va address
usage.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 71 +++---
drivers/gpu/drm/a
Extend the userq state for identifying the
userq invalid cases.
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_u
On 19.09.25 09:43, Tvrtko Ursulin wrote:
> On 19/09/2025 07:46, Christian König wrote:
>> On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
>>> On certain workloads, like on ChromeOS when opening multiple tabs and
>>> windows, and switching desktops, memory pressure can build up and latency
>
[Public]
> This information was originally intended for developer use and problem
> identification; this change was made specifically for 13.0.6/13.0.12 but did
> not provide any benefit.
The mismatch messaging is there across smu11/12/14. This change suppresses the
message only for SMU v13.0.
[Public]
The message is really confusing during debug, and I remember getting stuck with
pmfw team , to explain them its not error just a message. As Lijo pointed out
we have not updated interface version for 13.0.6 and 13.0.12 from long time
because we are not using it. I only use this message
56 matches
Mail list logo
