Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 26.04.22 um 19:40 schrieb Chia-I Wu:
[SNIP]
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.
I am a bit confused by this.  _emit and _signaled are a great way to
see how many fences are pending from cpu's point of view.  How does
_emit make no sense and _init is good instead?

We had exactly that confusion now multiple times and it's one of the main reasons why I want to remove the _emit trace point.

See the when you want to know how many fences are pending you need to watch out for init/destroy and *NOT* emit.

The reason is that in the special case where emit makes sense (e.g. the GPU scheduler fences) emit comes later than init, but pending on the CPU and taking up resources are all fences and not just the one emitted to the hardware.

On the other hand when you want to measure how much time each operation took on the hardware you need to take a look at the differences of the signal events on each timeline.

So there isn't really any use case for the emit trace point, except when you want to figure out how much latency the scheduler introduce. Then you want to take a look at init and emit, but that isn't really that interesting for performance analyses.

Regards,
Christian.




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux