Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
On 9/12/2024 5:29 PM, Asad Kamal wrote:
> Use same metric table for APU and Non APU systems
> for smu_v_13_0_6 to get metric data based on newer pmfw
> versions
>
> v2: Use inline func to check for ubified metrics support
>
Typo -ubified => unified
Reviewed-by: Lijo Lazar
Thanks,
On 9/12/2024 5:29 PM, Asad Kamal wrote:
> Use metrics 1_6 to report activities per partition
>
> v2: Use separate per instance for different platforms, shared
> vcn handled by other fix
>
> Signed-off-by: Asad Kamal
Series is -
Reviewed-by: Lijo Lazar
Thanks,
Lijo
> ---
> .../drm
Am 11.09.24 um 17:13 schrieb Yunxiang Li:
Since on modern systems all of vram can be made visible anyways, to
simplify the new implementation, drops tracking how much memory is
visible for now. If this is still needed we can add it back on top of
the new implementation.
Signed-off-by: Yunxiang L
Am 11.09.24 um 17:13 schrieb Yunxiang Li:
amdgpu_vm_bo_invalidate doesn't use the adev parameter and not all
callers have a reference to adev handy, so remove it for cleanliness.
Signed-off-by: Yunxiang Li
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +
Expose the interface for kfd to config sq perfmon.
Signed-off-by: Feifei Xu
Suggested-by: Hawking Zhang
Reviewed-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 3 +++
2 files changed, 18 insertions(+)
diff --gi
Add support for enable/disable perfmon profiling.
Signed-off-by: Feifei Xu
Suggested-by: Hawking Zhang
Reviewed-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 38 +
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 4 +++
drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h |
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Feifei Xu
Sent: Friday, September 13, 2024 16:33
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Zhang, Hawking ;
Lazar, Lijo
Subject: [PATCH 2/2
On Wed, 2024-09-11 at 13:22 +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2024 11:25, Philipp Stanner wrote:
> > On Mon, 2024-09-09 at 18:19 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Having removed one re-lock cycle on the entity->lock in a patch
> > > titled
> > > "drm/sch
Reviewed-by:JamesZhufortheseries.
On 2024-09-13 04:32, Feifei Xu wrote:
Expose the interface for kfd to config sq perfmon.
Signed-off-by: Feifei Xu
Suggested-by: Hawking Zhang
Reviewed-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
drivers/gpu/drm/amd/amd
Hi Dave, Simona,
A few fixes for 6.12 and the drm dma-buf race fixes from Al Viro.
The following changes since commit 7a199557643e993d4e7357860624b8aa5d8f4340:
Revert "drm/amdgpu: align pp_power_profile_mode with kernel docs" (2024-09-05
14:27:41 -0400)
are available in the Git repository at
On Thu, Sep 12, 2024 at 9:40 PM Zhu Lingshan wrote:
>
> This commits init registers in the Stand Along Walker
> for mmhub v1.0, to support ISP use cases.
>
> Signed-off-by: Zhu Lingshan
> Reported-and-Tested-by: Du Bin
> ---
> drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 48 +
From: Tvrtko Ursulin
Re-spin of the series from last week. Changelog is in individual patches.
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: Philipp Stanner
Tvrtko Ursulin (8):
drm/sched: Add locking to drm_sched_entity_modify_sched
drm/sched: Always wake
From: Tvrtko Ursulin
It does not seem there is a need to set the current entity in FIFO mode
since ot only serves as being a "cursor" in round-robin mode. Even if
scheduling mode is changed at runtime the change in behaviour is simply
to restart from the first entity, instead of continuing in RR
From: Tvrtko Ursulin
In FIFO mode We can avoid dropping the lock only to immediately re-acquire
by adding a new drm_sched_rq_update_fifo_locked() helper.
v2:
* Remove drm_sched_rq_update_fifo() altogether. (Christian)
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Alex Deucher
Cc: Lu
From: Tvrtko Ursulin
Having removed one re-lock cycle on the entity->lock in a patch titled
"drm/sched: Optimise drm_sched_entity_push_job", with only a tiny bit
larger refactoring we can do the same optimisation on the rq->lock.
(Currently both drm_sched_rq_add_entity() and
drm_sched_rq_update_f
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problem
From: Tvrtko Ursulin
Current kerneldoc for struct drm_sched_rq incompletely documents what
fields are protected by the lock.
This is not good because it is misleading.
Lets fix it by listing all the elements which are protected by the lock.
While at it, lets also re-order the members so all pr
From: Tvrtko Ursulin
Christian suggested to rename the lock and improve the documentation of
what it protects. And to also re-order the structure members so all
protected by the lock are together in a block.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
From: Tvrtko Ursulin
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve com
From: Tvrtko Ursulin
Entities run queue can change during drm_sched_entity_push_job() so make
sure to update the score consistently.
Signed-off-by: Tvrtko Ursulin
Fixes: d41a39dda140 ("drm/scheduler: improve job distribution with multiple
queues")
Cc: Nirmoy Das
Cc: Christian König
Cc: Luben
Currently amdgpu takes backlight caps provided by the ACPI tables
on systems as is. If the firmware sets maximums that are too low
this means that users don't get a good experience.
To avoid having to maintain a quirk list of such systems, do a sanity
check on the values. Check that the spread i
[Public]
Hi all,
This week this patchset was tested on the following systems:
* Lenovo ThinkBook T13s Gen4 with AMD Ryzen 5 6600U
* MSI Gaming X Trio RX 6800
* Gigabyte Gaming OC RX 7900 XTX
These systems were tested on the following display/connection types:
* eD
On 2024-09-13 14:00, Mario Limonciello wrote:
> Currently amdgpu takes backlight caps provided by the ACPI tables
> on systems as is. If the firmware sets maximums that are too low
> this means that users don't get a good experience.
>
> To avoid having to maintain a quirk list of such systems
On 9/13/2024 13:47, Harry Wentland wrote:
On 2024-09-13 14:00, Mario Limonciello wrote:
Currently amdgpu takes backlight caps provided by the ACPI tables
on systems as is. If the firmware sets maximums that are too low
this means that users don't get a good experience.
To avoid having to mai
On 2024-09-13 14:51, Mario Limonciello wrote:
> On 9/13/2024 13:47, Harry Wentland wrote:
>>
>>
>> On 2024-09-13 14:00, Mario Limonciello wrote:
>>> Currently amdgpu takes backlight caps provided by the ACPI tables
>>> on systems as is. If the firmware sets maximums that are too low
>>> this me
On Fri, Sep 13, 2024 at 2:51 PM Mario Limonciello
wrote:
>
> On 9/13/2024 13:47, Harry Wentland wrote:
> >
> >
> > On 2024-09-13 14:00, Mario Limonciello wrote:
> >> Currently amdgpu takes backlight caps provided by the ACPI tables
> >> on systems as is. If the firmware sets maximums that are too
On 9/13/2024 15:36, Alex Deucher wrote:
On Fri, Sep 13, 2024 at 2:51 PM Mario Limonciello
wrote:
On 9/13/2024 13:47, Harry Wentland wrote:
On 2024-09-13 14:00, Mario Limonciello wrote:
Currently amdgpu takes backlight caps provided by the ACPI tables
on systems as is. If the firmware sets
28 matches
Mail list logo
