[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Kamal, Asad
Sent: Wednesday, January 22, 2025 17:56
To: amd-gfx@lists.freedesktop.org; Lazar, Lijo
Cc: Ma, Le ; Zhang, Hawking ; Zhang,
Morris ; Kam
Enable the cleaner shader for GFX10.1.1/10.1.2 GPUs to provide data
isolation between GPU workloads. The cleaner shader is responsible for
clearing the Local Data Store (LDS), Vector General Purpose Registers
(VGPRs), and Scalar General Purpose Registers (SGPRs), which helps
prevent data leakage an
Enhance error handling in function amdgpu_pci_probe() to avoid
possible resource leakage.
Signed-off-by: Jiang Liu
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdg
Introduce new interface amdgpu_xcp_drm_dev_free() to free a specific
drm_device crreated by amdgpu_xcp_drm_dev_alloc(), which will be used
to do error recovery.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c | 63 +
drivers/gpu/drm/amd/amdxcp/amdgpu_
When AMD gpu firmware files are missing, loading the amdgpu driver will
cause following invalid memory access:
[ 89.735573] amdgpu :0a:00.0: amdgpu: Fetched VBIOS from platform
[ 89.735583] amdgpu: ATOM BIOS: 113-M3080202-101
[ 89.735676] amdgpu :0a:00.0: Direct firmware load for
am
This patchset tries to fix several memory leakages/invalid memory
accesses on error handling path during GPU driver loading/unloading.
They applies to:
https://gitlab.freedesktop.org/agd5f/linux.git amd-staging-drm-next
v6:
1) fix coding style of patch 5
v5:
1) drop first in v4, we have found a r
Introduce amdgpu_device_fini_schedulers() to clean scheduler related
resources, and avoid possible invalid memory access.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 9 ---
2 files changed,
If some GPU device failed to probe, `rmmod amdgpu` will trigger a use
after free bug related to amdgpu_driver_release_kms() as:
[16002.085540] BUG: kernel NULL pointer dereference, address:
[16002.093792] #PF: supervisor read access in kernel mode
[16002.03] #PF: error_code(0x0
> 2025年1月20日 17:04，Christian König 写道：
>
> Am 17.01.25 um 08:55 schrieb Jiang Liu:
>> Introduce amdgpu_device_fini_schedulers() to clean scheduler related
>> resources, and avoid possible invalid memory access.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_devic
Reviewed-by: Feifei Xu
On 1/21/2025 3:40 AM, Alex Deucher wrote:
Consolidate PM4 definitions. Most of these were previously
only defined in UMDs. Add them here as well and sync with
latest packets. Also no need to include soc15d.h on gfx10+.
Suggested-by: Saurabh Verma
Signed-off-by: Alex D
Ping again?
On Wed, Jan 22, 2025 at 10:41 AM Alex Deucher wrote:
>
> Ping?
>
> On Mon, Jan 20, 2025 at 2:47 PM Alex Deucher
> wrote:
> >
> > Consolidate PM4 definitions. Most of these were previously
> > only defined in UMDs. Add them here as well and sync with
> > latest packets. Also no ne
On 2025-01-17 04:19, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:49 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> Add kernel doc for AMD color pipeline.
>>
>> Signed-off-by: Alex Hung
>> Signed-off-by: Harry Wentland
>> ---
>> .../amd/display/amdgpu_dm/amdgpu_dm_color.c
SVM migration unmap pages from GPU and then update mapping to GPU to
recover page fault. Currently unmap clears the PDE entry for range
length >= huge page and may free PTB bo. Then update mapping should
alloc new PT bo, but there is race bug that the freed entry bo maybe
still on the pt_free list,
On Thursday, January 23rd, 2025 at 21:06, Harry Wentland
wrote:
> On 2025-01-15 03:00, Simon Ser wrote:
>
> > Is this 125 magic number something we can expect other hardware to
> > implement as well?
>
> It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
> this definition
On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland
wrote:
> On 2025-01-15 02:56, Simon Ser wrote:
>
> > Is this "ignore" something we could do at the core DRM level, instead
> > of doing it in all drivers? e.g. by silently ignoring user-space requests
> > to set the property?
>
> I thin
On 2025-01-17 04:06, Pekka Paalanen wrote:
> On Thu, 16 Jan 2025 10:56:22 +0200
> Pekka Paalanen wrote:
>
>> On Thu, 19 Dec 2024 21:33:37 -0700
>> Alex Hung wrote:
>>
>>> From: Harry Wentland
>>>
>>> The BT.709 and BT.2020 OETFs are the same, the only difference
>>> being that the BT.2020 va
On 2025-01-15 03:04, Simon Ser wrote:
>> The BT.709 and BT.2020 OETFs are the same, the only difference
>> being that the BT.2020 variant is defined with more precision
>> for 10 and 12-bit per color encodings.
>
> Just to make sure, the spec defines this precision, correct? It's
> not an AMD-s
On 2025-01-17 04:04, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:35 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> The PQ function defines a mapping of code values to nits (cd/m^2).
>> The max code value maps to 10,000 nits.
>>
>> Windows DWM's canonical composition color spac
On 2025-01-15 03:00, Simon Ser wrote:
> Is this 125 magic number something we can expect other hardware to
> implement as well?
>
It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
this definition one needs to use 125.0f to represent 10,000 nits,
the maximum value PQ can r
On Thu, Jan 23, 2025 at 12:47 PM Srinivasan Shanmugam
wrote:
>
> This commit adds the cleaner shader microcode for GFX10.1.0 GPUs. The
> cleaner shader is a piece of GPU code that is used to clear or
> initialize certain GPU resources, such as Local Data Share (LDS), Vector
> General Purpose Regis
This commit adds the cleaner shader microcode for GFX10.1.0 GPUs. The
cleaner shader is a piece of GPU code that is used to clear or
initialize certain GPU resources, such as Local Data Share (LDS), Vector
General Purpose Registers (VGPRs), and Scalar General Purpose Registers
(SGPRs).
Clearing th
[Public]
> -Original Message-
> From: Liang, Prike
> Sent: Wednesday, January 22, 2025 4:26 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Koenig, Christian ; Kuehling, Felix
> ; Kim, Jonathan ;
> Kasiviswanathan, Harish ; Liang, Prike
>
> Subject: [PATCH] drm/amdkfd: only flush the valida
On Thu, 2025-01-23 at 08:10 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 23/01/25 05:10, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > > Hi Philipp,
> > >
> > > On 22/01/25 11:08, Philipp Stanner wrote:
> > > > drm_sched_init() has a great many parameters
Hi Philipp,
On 23/01/25 09:13, Philipp Stanner wrote:
On Thu, 2025-01-23 at 08:10 -0300, Maíra Canal wrote:
Hi Philipp,
On 23/01/25 05:10, Philipp Stanner wrote:
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
Hi Philipp,
On 22/01/25 11:08, Philipp Stanner wrote:
drm_sched_init() has
Hi Philipp,
On 23/01/25 05:10, Philipp Stanner wrote:
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
Hi Philipp,
On 22/01/25 11:08, Philipp Stanner wrote:
drm_sched_init() has a great many parameters and upcoming new
functionality for the scheduler might add even more. Generally, the
g
On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote:
> > +It is the responsibility of the consumer to make sure that the device or
> > +its resources are not in use by any process before attempting recovery.
> I'm not convinced this is actually doable in practice, outside of
> killing all ap
On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> On Wed, 22 Jan 2025 15:08:20 +0100
> Philipp Stanner wrote:
>
> > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > - const struct drm_sched_backend_ops *ops,
> > - struct workqueue_struct *submit_wq,
> > - u32 num_rqs, u
On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > Philipp Stanner wrote:
> > >
> > > > int drm_sched_init(struc
On Tue, Jan 21, 2025 at 01:59:47AM +0100, Xaver Hugl wrote:
> Hi,
>
> I experimented with using this in KWin, and
> https://invent.kde.org/plasma/kwin/-/merge_requests/7027/diffs?commit_id=6da40f1b9e2bc94615a436de4778880cee16f940
> makes it fall back to a software renderer when a rebind is require
On 23/01/2025 09:35, Philipp Stanner wrote:
On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
On Wed, 22 Jan 2025 15:08:20 +0100
Philipp Stanner wrote:
int
On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote:
> On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> > On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > > On Wed, 22 Jan 2025 15:08:20 +01
On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_o
On Thu, 23 Jan 2025 08:33:01 +0100
Philipp Stanner wrote:
> On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_ops
On Thu, 2025-01-23 at 09:10 +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > Hi Philipp,
> >
> > On 22/01/25 11:08, Philipp Stanner wrote:
> > > drm_sched_init() has a great many parameters and upcoming new
> > > functionality for the scheduler might add ev
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 22/01/25 11:08, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great number of parameters reduces readabi
35 matches
Mail list logo
