Joonas, sorry for interfering; could you please explain more regarding the options for tracing scheduling events better than tracepoints? After scheduling moves to GuC tools will have to switch to something like GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution? I know gpuvis is not the only attempt to use tracepoints for the same purpose. (there're trace.pl and S.E.A. and of course VTune though it probably is not considered to be existing as it's not open source). And assuming this movement towards GuC is it not too late to invent a completely new way to provide tools with scheduling info from kmd? Could we just improve the existing way and let it live its last years\months? gpuvis works w\o modifying kernel for AMDgpu showing HW queue and HW execution; it cosplays Microsoft GPUView which works out-of-the-box on Windows too. Thus it appears that intel gfx on linux is the most closed platform, not bothering of observability (or even bothering about how to forbid observability). Not long ago the MediaSDK team diagnosed a problem with their workloads looking at VTune timelines - seeing the difference between the time request came to kmd and time it went runnable & comparing the queues on 2 engines they understood that their requests have dependencies that were definitely unexpected. MediaSDK reported the problem to driver people and it was fixed. I can add Dmitry Rogozhkin to discussion if the usefulness of scheduling timeline in tools is questionable, as far as I remember this wasn't the only use case they had, I'm sure he can add more. Thank you, Svetlana -----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Joonas Lahtinen Sent: Monday, August 13, 2018 12:55 PM To: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; Intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Tvrtko Ursulin <tursulin@xxxxxxxxxxx>; Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> Subject: Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option Quoting Tvrtko Ursulin (2018-08-08 15:56:01) > On 08/08/2018 13:42, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-08-08 13:13:08) > This is true, no disagreement. My point simply was that we can provide > this info easily to anyone. There is a little bit of analogy with perf > scheduler tracing/map etc. > > > I don't see any value in giving the information away, just the cost. > > If you can convince Joonas of its merit, and if we can define just > > exactly what ABI it constitutes, then I'd be happy to be the one who > > says "I told you so" in the future for a change. > > I think Joonas was okay in principle that we soft-commit to _trying_ > to keep _some_ tracepoint stable-ish (where it makes sense and after > some discussion for each) if IGT also materializes which auto-pings us > (via > CI) when we break one of them. But I may be misremembering so Joonas > please comment. Currently gpuvis, using these, seems to be only packaged in one AUR repo, and they do make a not in the wiki how you need to configure kernel for debugging. And there's been no apparent demand for them to have it in stock kernel. And even when we do get demand for having gpuvis or another tool working from vanilla kernel, tracepoints being a rather tricky subject, I would start the discussion by going through alternative means of providing the information the tool needs and considering those. So lets still keep this option as it was introduced. The whole "tracepoints as stable uAPI" idea is a can of worms which is only dug into when other options are exhausted. Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx -------------------------------------------------------------------- Joint Stock Company Intel A/O Registered legal address: Krylatsky Hills Business Park, 17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
