Am 26.04.22 um 19:05 schrieb Rob Clark:
On Tue, Apr 26, 2022 at 9:42 AM Christian König
<christian.koenig@xxxxxxx> wrote:
Am 26.04.22 um 18:32 schrieb Chia-I Wu:
On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu <olvaffe@xxxxxxxxx> wrote:
In practice, trace_dma_fence_init called from dma_fence_init is good
enough and almost no driver calls trace_dma_fence_emit. But drm_sched
and virtio both have cases where trace_dma_fence_init and
trace_dma_fence_emit can be apart. It is easier for visualization tools
to always use the more correct trace_dma_fence_emit when visualizing
fence timelines.
v2: improve commit message (Dmitry)
Signed-off-by: Chia-I Wu <olvaffe@xxxxxxxxx>
Cc: Rob Clark <robdclark@xxxxxxxxxxxx>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
This has been reviewed. Should we land it?
No, there are still open discussions about it.
I think if it is needed for trace visualization, that is justification
enough for me
I don't really see otherwise how a generic trace visualization tool
like perfetto would handle the case that some fence timelines have
separate events but others do not.
Well I just send a patch to completely remove the trace point.
As I said it absolutely doesn't make sense to use this for
visualization, that's what the trace_dma_fence_init trace point is good for.
The only use case is for debugging the GPU scheduler and we should
probably introduce a separate GPU scheduler specific trace point for
this instead if we should ever need it.
Regards,
Christian.
BR,
-R
Regards,
Christian.
(Or, how do I check if it has landed?)
