On Tue, Apr 26, 2022 at 10:08 AM Christian König christian.koenig@amd.com wrote:
Am 26.04.22 um 19:05 schrieb Rob Clark:
On Tue, Apr 26, 2022 at 9:42 AM Christian König christian.koenig@amd.com 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@gmail.com 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@gmail.com Cc: Rob Clark robdclark@chromium.org Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org
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.
Hmm, AFAIU from Chia-I, virtgpu has a separation of init and emit.. OTOH if using separate events in these special cases is better, then I'm ok with that and can revert this patch. Chia-I is more familiar with the visualization end of it, so I'll let him comment on whether that is a workable approach.
BR, -R
Regards, Christian.
BR, -R
Regards, Christian.
(Or, how do I check if it has landed?)