start and stop times are messed up in the timeline

[nscottnichols]

See above. The gemm_kernels get longer with concurrency (not really though).

[TApplencourt]

16:31:17.989105498 - x4502c7s3b0n0 - vpid: 108330, vtid: 108330 - lttng_ust_ze_profiling:event_profiling_results: { hEvent: 0x0000558d37421748, status: ZE_RESULT_SUCCESS, timestampStatus: ZE_RESULT_SUCCESS, globalStart: 246864525, globalEnd: 246959461, contextStart: 1544473391, contextEnd: 1544556308 } Dur_global 94936 | Dur_context: 82917
16:31:17.989110352 - x4502c7s3b0n0 - vpid: 108330, vtid: 108330 - lttng_ust_ze_profiling:event_profiling_results: { hEvent: 0x0000558d37422e88, status: ZE_RESULT_SUCCESS, timestampStatus: ZE_RESULT_SUCCESS, globalStart: 241283408, globalEnd: 249658502, contextStart: 1520439954, contextEnd: 1528794268 } Dur_global 8375094 | Dur_context: 8354314

Look like to be a L0 thingy. We cannot really know when a kernel "really" start executing...

[ze_synchronized_timestamp_data_ext_t](https://oneapi-src.github.io/level-zero-spec/level-zero/1.11/core/api.html#_CPPv436ze_synchronized_timestamp_data_ext_t) context

    [out] context-active data; only includes clocks while device context was actively executing.

But in the timline context ~= global, so this will not solve our problem. : (