Le 16/02/2024 à 17:24, Ville Syrjälä a écrit :
On Fri, Feb 16, 2024 at 04:09:55PM +0100, Pierre-Eric Pelloux-Prayer wrote:
With this and the dma_fence_used_as_dependency event, a tool can draw the
relationship between the compositing draw, the atomic commit, and vblank.
An example on a 2
.
With work queues, the source is now something like: "kworker/u64:0-15248"
(and the PID isn't stable), so the "timeline=gfx_0.0.0" attribute
isn't enough in multi-GPU setups.
This commit adds a dev=devname attribute to resolve this issue.
Signed-off-by: Pierre-Eric Pelloux-
drm_sched_job_add_dependency adds dependencies so use the new
trace event.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/scheduler/sched_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler
=2571916093743, high-prec=true
-0 [018] d.h3. 2571.915968: drm_vblank_event: crtc=0,
seq=153862, time=2571916377180, high-prec=true
v2: fix unchecked memory allocation
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/drm_atomic_uapi.c | 21 +
drivers/gpu/drm
to amdgpu_cs_start
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu
Useful to identify why sdma jobs are submitted.
v2: moved from amdgpu_bo_create to amdgpu_bo_fill
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 18 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++
2 files changed, 20 insertions
issue
I have prototype code using this in UMR, as can be see here:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37
v2: add a macro since every caller passes __func__ as the reason parameter
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
To inform tools about the relationship between the fences.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence-chain.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 9663ba1bb6ac
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 27 +++
2 files
attribute to the trace_amdgpu_sched_run_job event
* addressed review comments
Pierre-Eric Pelloux-Prayer (8):
tracing, dma-buf: add a trace_dma_fence_sync_to event
dma-buf/fence-chain: use trace_dma_fence_sync_to
amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
drm/amdgpu: add
Le 14/02/2024 à 16:10, Steven Rostedt a écrit :
On Wed, 14 Feb 2024 13:00:16 +0100
Christian König wrote:
+DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
For a single event you should probably use TRACE_EVENT() instead of
declaring a class. A class is only used if you have multiple events
Le 14/02/2024 à 13:09, Christian König a écrit :
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events
[018] d.h3. 2571.915968: drm_vblank_event: crtc=0,
seq=153862, time=2571916377180, high-prec=true
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/drm_atomic_uapi.c | 19 +++
drivers/gpu/drm/drm_trace.h | 28 ++--
2 files changed, 45
-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 6830892383c3
Useful to identify why sdma jobs are submitted.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 16
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu
of amdgpu_fence_sync.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 14 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
To inform tools about the relationship between the fences.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence-chain.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 9663ba1bb6ac
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 34
2
/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/
Changes from V1:
* uses trace_dma_fence_sync_to from dma-fence-chain.c
* new amdgpu events
* new drm plane commit event
Pierre-Eric Pelloux-Prayer (6):
tracing, dma-buf: add a trace_dma_fence_sync_to event
dma-buf/fence-chain
of amdgpu_fence_sync.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 14 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 34
2
On 09/03/2022 11:24, Christian König wrote:
> Am 09.03.22 um 11:10 schrieb Simon Ser:
>> On Wednesday, March 9th, 2022 at 10:56, Pierre-Eric Pelloux-Prayer
>> wrote:
>>
>>> Would it be possible to include the app parameters as well?
>>
Hi Shashank,
On 08/03/2022 19:04, Shashank Sharma wrote:
> From: Shashank Sharma
>
> This patch adds a new sysfs event, which will indicate
> the userland about a GPU reset, and can also provide
> some information like:
> - process ID of the process involved with the GPU reset
> - process name
d other drivers and it doesn't look like they end up triggering
> this case so I think this is safe to relax.
This patch fixes https://gitlab.freedesktop.org/drm/amd/-/issues/1379:
Tested-by: Pierre-Eric Pelloux-Prayer
Thanks!
P-E
>
> Signed-off-by: Bas Nieuwenhuizen
> Fixes: 816853f9dc40
Hi Bas,
2 small typos you may want to fix:
On 04/09/2020 18:07, Bas Nieuwenhuizen wrote:
> This adds modifiers for GFX9+ AMD GPUs.
>
> As the modifiers need a lot of parameters I split things out in
> getters and setters.
> - Advantage: simplifies the code a lot
> - Disadvantage: Makes it
Hi Daniel,
On 04/06/2020 10:12, Daniel Vetter wrote:
[...]
> @@ -6910,7 +6910,11 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* explicitly on fences instead
>* and in general should be called for
>* blocking commit to
Hi Christian,
Sorry I missed your original email. I just tested the patch and it works fine,
so feel free to add my Tested-by tag.
Pierre-Eric
On 09/03/2020 12:49, Christian König wrote:
> Pierre-eric, just a gentle ping on this? Could I get a tested-by?
>
> Ray can you ack or even review
Hi,
the attached patch should be an improvement over Vadim Girlin's patch
fixing LIT instruction for r600g (commit
2fe39b46e73aea37152777fe11d489e0b1bc3f92).
Instructions used in tgsi_lit have been reordered to always write to a
dst channel after the same channel in src has been read (so if src
==
dst, input values are not overwritten before being used).
I've sent the accompagnying test case to piglit ML.
Pierre-Eric
From f0cd600074ef0a086742a4a0932b8d5880fc87b3 Mon Sep 17 00:00:00 2001
From: Pierre-Eric Pelloux-Prayer pell...@gmail.com
Date: Mon, 20 Jun 2011 11:25:14 +0200
Subject
u_upload_flush() is called each time r600_flush() is used.
There is a comment specifically saying :
/* XXX This shouldn't be really necessary, but removing it breaks some
tests.
* Needless buffer reallocations may significantly increase memory
consumption,
* so getting
attached patch removed function call + comment.
Pierre-Eric
From 4596e9040bde510fd974d500af69070341871b46 Mon Sep 17 00:00:00 2001
From: Pierre-Eric Pelloux-Prayer pell...@gmail.com
Date: Fri, 10 Jun 2011 15:45:01 +0200
Subject: [PATCH 2/2] r600g: remove useless call to u_upload_flush
No regressions
31 matches
Mail list logo
