[PATCH 1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

[PATCH 1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Long time ago execute was a fence and it made sense to have a tracepoint
corresponding to it. Nowadays it completely aligns either with request_
submit or request_in tracepoints and so is redundant.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_request.c |  2 --
 drivers/gpu/drm/i915/i915_trace.h   | 10 ----------
 2 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index e1dbb544046f..8217e19542d9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -541,8 +541,6 @@ void __i915_request_submit(struct i915_request *request)
 	/* Transfer from per-context onto the global per-engine timeline */
 	move_to_timeline(request, &engine->timeline);
 
-	trace_i915_request_execute(request);
-
 	wake_up_all(&request->execute);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index b50c6b829715..4a6a15075afa 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -685,11 +685,6 @@ DEFINE_EVENT(i915_request, i915_request_submit,
 	     TP_ARGS(rq)
 );
 
-DEFINE_EVENT(i915_request, i915_request_execute,
-	     TP_PROTO(struct i915_request *rq),
-	     TP_ARGS(rq)
-);
-
 TRACE_EVENT(i915_request_in,
 	    TP_PROTO(struct i915_request *rq, unsigned int port),
 	    TP_ARGS(rq, port),
@@ -763,11 +758,6 @@ trace_i915_request_submit(struct i915_request *rq)
 {
 }
 
-static inline void
-trace_i915_request_execute(struct i915_request *rq)
-{
-}
-
 static inline void
 trace_i915_request_in(struct i915_request *rq, unsigned int port)
 {
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

This Kconfig option was added to protect the implementation specific
internals from user expectations but so far it was mostly hassle.

Remove it so it is possible to debug request submission on any kernel
anywhere.

This adds around 4k to default i915.ko build but should have no
performance effects due inactive tracepoints being no-op-ed out and out-
of-line.

Users should remember tracepoints which are close to low level i915
implementation details are subject to change and cannot be guaranteed.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/Kconfig.debug | 11 -----------
 drivers/gpu/drm/i915/i915_trace.h  | 20 --------------------
 2 files changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
index 9de8b1c51a5c..058094235329 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -132,17 +132,6 @@ config DRM_I915_SELFTEST_BROKEN
 
 	  If in doubt, say "N".
 
-config DRM_I915_LOW_LEVEL_TRACEPOINTS
-        bool "Enable low level request tracing events"
-        depends on DRM_I915
-        default n
-        help
-          Choose this option to turn on low level request tracing events.
-          This provides the ability to precisely monitor engine utilisation
-          and also analyze the request dependency resolving timeline.
-
-          If in doubt, say "N".
-
 config DRM_I915_DEBUG_VBLANK_EVADE
 	bool "Enable extra debug warnings for vblank evasion"
 	depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index 4a6a15075afa..c0352a1b036c 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -679,7 +679,6 @@ DEFINE_EVENT(i915_request, i915_request_add,
 	    TP_ARGS(rq)
 );
 
-#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
 DEFINE_EVENT(i915_request, i915_request_submit,
 	     TP_PROTO(struct i915_request *rq),
 	     TP_ARGS(rq)
@@ -751,25 +750,6 @@ TRACE_EVENT(i915_request_out,
 			      __entry->global_seqno, __entry->completed)
 );
 
-#else
-#if !defined(TRACE_HEADER_MULTI_READ)
-static inline void
-trace_i915_request_submit(struct i915_request *rq)
-{
-}
-
-static inline void
-trace_i915_request_in(struct i915_request *rq, unsigned int port)
-{
-}
-
-static inline void
-trace_i915_request_out(struct i915_request *rq)
-{
-}
-#endif
-#endif
-
 TRACE_EVENT(intel_engine_notify,
 	    TP_PROTO(struct intel_engine_cs *engine, bool waiters),
 	    TP_ARGS(engine, waiters),
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-25 18:25:46)
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> This Kconfig option was added to protect the implementation specific
> internals from user expectations but so far it was mostly hassle.
> 
> Remove it so it is possible to debug request submission on any kernel
> anywhere.

Our job is not to let bugs into the wild ;)
 
> This adds around 4k to default i915.ko build but should have no
> performance effects due inactive tracepoints being no-op-ed out and out-
> of-line.
> 
> Users should remember tracepoints which are close to low level i915
> implementation details are subject to change and cannot be guaranteed.

That's the caveat that I feel needs fleshed out. Burying it had the
advantage of making it quite clear that you had to opt in and pick up
the pieces when it inevitably breaks.

What is wanted and what can we reasonable provide? If the tracepoints
needs to undergo major change before the next LTS, let alone for the
life of that LTS...

If we know what is wanted can we define that better in terms of
dma_fence and leave lowlevel for debugging (or think of how we achieve
the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
that.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

On 25/06/2018 21:02, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-06-25 18:25:46)
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> This Kconfig option was added to protect the implementation specific
>> internals from user expectations but so far it was mostly hassle.
>>
>> Remove it so it is possible to debug request submission on any kernel
>> anywhere.
> 
> Our job is not to let bugs into the wild ;)

I did not word that well - I actually meant debugging the engine 
timelines for unexpected stalls and/or dependencies. So more about 
userspace being able to analyse what's happening.

>> This adds around 4k to default i915.ko build but should have no
>> performance effects due inactive tracepoints being no-op-ed out and out-
>> of-line.
>>
>> Users should remember tracepoints which are close to low level i915
>> implementation details are subject to change and cannot be guaranteed.
> 
> That's the caveat that I feel needs fleshed out. Burying it had the
> advantage of making it quite clear that you had to opt in and pick up
> the pieces when it inevitably breaks.
> 
> What is wanted and what can we reasonable provide? If the tracepoints
> needs to undergo major change before the next LTS, let alone for the
> life of that LTS...
> 
> If we know what is wanted can we define that better in terms of
> dma_fence and leave lowlevel for debugging (or think of how we achieve
> the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
> that.

What is wanted is for instance take trace.pl on any kernel anywhere and 
it is able to deduce/draw the exact metrics/timeline of command 
submission for an workload.

At the moment it without low level tracepoints, and without the 
intel_engine_notify tweak, it is workload dependent on how close it 
could get.

So a set of tracepoints to allow drawing the timeline:

1. request_queue (or _add)
2. request_submit
3. intel_engine_notify
4. request_in/out

With this set the above is possible and we don't need a lot of work to 
get there.

And with the Virtual Engine it will become more interesting to have 
this. So if we had a bug report saying load balancing is not working 
well, we could just say "please run it via trace.pl --trace and attach 
perf script output". That way we could easily see whether or not is is a 
problem in userspace behaviour or else.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-26 11:46:51)
> 
> On 25/06/2018 21:02, Chris Wilson wrote:
> > If we know what is wanted can we define that better in terms of
> > dma_fence and leave lowlevel for debugging (or think of how we achieve
> > the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
> > that.
> 
> What is wanted is for instance take trace.pl on any kernel anywhere and 
> it is able to deduce/draw the exact metrics/timeline of command 
> submission for an workload.
> 
> At the moment it without low level tracepoints, and without the 
> intel_engine_notify tweak, it is workload dependent on how close it 
> could get.

Interjecting what dma-fence already has (or we could use), not sure how
well userspace can actually map it to their timelines.
> 
> So a set of tracepoints to allow drawing the timeline:
> 
> 1. request_queue (or _add)
dma_fence_init

> 2. request_submit

> 3. intel_engine_notify
For obvious reasons, no match in dma_fence.

> 4. request_in
dma_fence_emit

> 5. request out
dma_fence_signal (similar, not quite, we would have to force irq
signaling).
 
> With this set the above is possible and we don't need a lot of work to 
> get there.

From a brief glance we are missing a dma_fence_queue for request_submit
replacement.

So next question is what information do we get from our tracepoints (or
more precisely do you use) that we lack in dma_fence?

> And with the Virtual Engine it will become more interesting to have 
> this. So if we had a bug report saying load balancing is not working 
> well, we could just say "please run it via trace.pl --trace and attach 
> perf script output". That way we could easily see whether or not is is a 
> problem in userspace behaviour or else.

And there I was wanting a script to capture the workload so that we
could replay it and dissect it. :-p
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

On 26/06/2018 11:55, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-06-26 11:46:51)
>>
>> On 25/06/2018 21:02, Chris Wilson wrote:
>>> If we know what is wanted can we define that better in terms of
>>> dma_fence and leave lowlevel for debugging (or think of how we achieve
>>> the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
>>> that.
>>
>> What is wanted is for instance take trace.pl on any kernel anywhere and
>> it is able to deduce/draw the exact metrics/timeline of command
>> submission for an workload.
>>
>> At the moment it without low level tracepoints, and without the
>> intel_engine_notify tweak, it is workload dependent on how close it
>> could get.
> 
> Interjecting what dma-fence already has (or we could use), not sure how
> well userspace can actually map it to their timelines.
>>
>> So a set of tracepoints to allow drawing the timeline:
>>
>> 1. request_queue (or _add)
> dma_fence_init
> 
>> 2. request_submit
> 
>> 3. intel_engine_notify
> For obvious reasons, no match in dma_fence.
> 
>> 4. request_in
> dma_fence_emit
> 
>> 5. request out
> dma_fence_signal (similar, not quite, we would have to force irq
> signaling).

Yes not quite the same due potential time shift between user interrupt 
and dma_fence_signal call via different paths.

>   
>> With this set the above is possible and we don't need a lot of work to
>> get there.
> 
>  From a brief glance we are missing a dma_fence_queue for request_submit
> replacement.
> 
> So next question is what information do we get from our tracepoints (or
> more precisely do you use) that we lack in dma_fence?

Port=%u and preemption (completed=%u) comes immediately to mind. Way to 
tie with engines would be nice or it is all abstract timelines.

Going this direction sounds like a long detour to get where we almost 
are. I suspect you are valuing the benefit of it being generic and hence 
and parsing tool could be cross-driver. But you can also just punt the 
"abstractising" into the parsing tool.

>> And with the Virtual Engine it will become more interesting to have
>> this. So if we had a bug report saying load balancing is not working
>> well, we could just say "please run it via trace.pl --trace and attach
>> perf script output". That way we could easily see whether or not is is a
>> problem in userspace behaviour or else.
> 
> And there I was wanting a script to capture the workload so that we
> could replay it and dissect it. :-p

Depends on what level you want that. Perf script output from the above 
tracepoints would do on one level. If you wanted a higher level to 
re-exercise load balancing then it wouldn't completely be enough, or at 
least a lot of guesswork would be needed.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-26 12:24:51)
> 
> On 26/06/2018 11:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-26 11:46:51)
> >>
> >> On 25/06/2018 21:02, Chris Wilson wrote:
> >>> If we know what is wanted can we define that better in terms of
> >>> dma_fence and leave lowlevel for debugging (or think of how we achieve
> >>> the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
> >>> that.
> >>
> >> What is wanted is for instance take trace.pl on any kernel anywhere and
> >> it is able to deduce/draw the exact metrics/timeline of command
> >> submission for an workload.
> >>
> >> At the moment it without low level tracepoints, and without the
> >> intel_engine_notify tweak, it is workload dependent on how close it
> >> could get.
> > 
> > Interjecting what dma-fence already has (or we could use), not sure how
> > well userspace can actually map it to their timelines.
> >>
> >> So a set of tracepoints to allow drawing the timeline:
> >>
> >> 1. request_queue (or _add)
> > dma_fence_init
> > 
> >> 2. request_submit
> > 
> >> 3. intel_engine_notify
> > For obvious reasons, no match in dma_fence.
> > 
> >> 4. request_in
> > dma_fence_emit
> > 
> >> 5. request out
> > dma_fence_signal (similar, not quite, we would have to force irq
> > signaling).
> 
> Yes not quite the same due potential time shift between user interrupt 
> and dma_fence_signal call via different paths.
> 
> >   
> >> With this set the above is possible and we don't need a lot of work to
> >> get there.
> > 
> >  From a brief glance we are missing a dma_fence_queue for request_submit
> > replacement.
> > 
> > So next question is what information do we get from our tracepoints (or
> > more precisely do you use) that we lack in dma_fence?
> 
> Port=%u and preemption (completed=%u) comes immediately to mind. Way to 
> tie with engines would be nice or it is all abstract timelines.
> 
> Going this direction sounds like a long detour to get where we almost 
> are. I suspect you are valuing the benefit of it being generic and hence 
> and parsing tool could be cross-driver. But you can also just punt the 
> "abstractising" into the parsing tool.

It's just that this about the third time this has been raised in the
last couple of weeks with the other two requests being from a generic
tooling pov (Eric Anholt for gnome-shell tweaking, and some one
else looking for a gpuvis-like tool). So it seems like there is
interest, even if I doubt that it'll help answer any questions beyond
what you can just extract from looking at userspace. (Imo, the only
people these tracepoints are useful for are people writing patches for
the driver. For everyone else, you can just observe system behaviour and
optimise your code for your workload. Otoh, can one trust a black
box, argh.)

To have a second set of nearly equivalent tracepoints, we need to have
strong justification why we couldn't just use or extend the generic set.

Plus I feel a lot more comfortable exporting a set of generic
tracepoints, than those where we may be leaking more knowledge of the HW
than we can reasonably expect to support for the indefinite future.

> >> And with the Virtual Engine it will become more interesting to have
> >> this. So if we had a bug report saying load balancing is not working
> >> well, we could just say "please run it via trace.pl --trace and attach
> >> perf script output". That way we could easily see whether or not is is a
> >> problem in userspace behaviour or else.
> > 
> > And there I was wanting a script to capture the workload so that we
> > could replay it and dissect it. :-p
> 
> Depends on what level you want that. Perf script output from the above 
> tracepoints would do on one level. If you wanted a higher level to 
> re-exercise load balancing then it wouldn't completely be enough, or at 
> least a lot of guesswork would be needed.

It all depends on what level you want to optimise, is the way I look at
it. Userspace driver, you capture the client->driver userspace API (e.g.
cairo-trace, apitrace). But for optimising scheduling layout, we just
need a workload descriptor like wsim -- with perhaps the only tweak
being able to define latency/throughput metrics relevant to that
workload, and being able to integrate with a pseudo display server. The
challenge as I see it is being able to convince the user that it is a
useful diagnosis step and being able to generate a reasonable wsim
automatically.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

On 26/06/2018 12:48, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-06-26 12:24:51)
>>
>> On 26/06/2018 11:55, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-06-26 11:46:51)
>>>>
>>>> On 25/06/2018 21:02, Chris Wilson wrote:
>>>>> If we know what is wanted can we define that better in terms of
>>>>> dma_fence and leave lowlevel for debugging (or think of how we achieve
>>>>> the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
>>>>> that.
>>>>
>>>> What is wanted is for instance take trace.pl on any kernel anywhere and
>>>> it is able to deduce/draw the exact metrics/timeline of command
>>>> submission for an workload.
>>>>
>>>> At the moment it without low level tracepoints, and without the
>>>> intel_engine_notify tweak, it is workload dependent on how close it
>>>> could get.
>>>
>>> Interjecting what dma-fence already has (or we could use), not sure how
>>> well userspace can actually map it to their timelines.
>>>>
>>>> So a set of tracepoints to allow drawing the timeline:
>>>>
>>>> 1. request_queue (or _add)
>>> dma_fence_init
>>>
>>>> 2. request_submit
>>>
>>>> 3. intel_engine_notify
>>> For obvious reasons, no match in dma_fence.
>>>
>>>> 4. request_in
>>> dma_fence_emit
>>>
>>>> 5. request out
>>> dma_fence_signal (similar, not quite, we would have to force irq
>>> signaling).
>>
>> Yes not quite the same due potential time shift between user interrupt
>> and dma_fence_signal call via different paths.
>>
>>>    
>>>> With this set the above is possible and we don't need a lot of work to
>>>> get there.
>>>
>>>   From a brief glance we are missing a dma_fence_queue for request_submit
>>> replacement.
>>>
>>> So next question is what information do we get from our tracepoints (or
>>> more precisely do you use) that we lack in dma_fence?
>>
>> Port=%u and preemption (completed=%u) comes immediately to mind. Way to
>> tie with engines would be nice or it is all abstract timelines.
>>
>> Going this direction sounds like a long detour to get where we almost
>> are. I suspect you are valuing the benefit of it being generic and hence
>> and parsing tool could be cross-driver. But you can also just punt the
>> "abstractising" into the parsing tool.
> 
> It's just that this about the third time this has been raised in the
> last couple of weeks with the other two requests being from a generic
> tooling pov (Eric Anholt for gnome-shell tweaking, and some one
> else looking for a gpuvis-like tool). So it seems like there is
> interest, even if I doubt that it'll help answer any questions beyond
> what you can just extract from looking at userspace. (Imo, the only
> people these tracepoints are useful for are people writing patches for
> the driver. For everyone else, you can just observe system behaviour and
> optimise your code for your workload. Otoh, can one trust a black
> box, argh.)

Some of the things might be obtainable purely from userspace via heavily 
instrumented builds, which may be in the realm of possible for during 
development, but I don't think it is feasible in general both because it 
is too involved, and because it would preclude existence of tools which 
can trace any random client.

> To have a second set of nearly equivalent tracepoints, we need to have
> strong justification why we couldn't just use or extend the generic set.

I was hoping that the conversation so far established that nearly 
equivalent is not close enough for intended use cases. And that is not 
possible to make the generic ones so.

> Plus I feel a lot more comfortable exporting a set of generic
> tracepoints, than those where we may be leaking more knowledge of the HW
> than we can reasonably expect to support for the indefinite future.

I think it is accepted we cannot guarantee low level tracepoints will be 
supportable in the future world of GuC scheduling. (How and what we will 
do there is yet unresolved.) But at least we get much better usability 
for platforms up to there, and for very small effort. The idea is not to 
mark these as ABI but just improve user experience.

You are I suppose worried that if these tracepoints disappeared due 
being un-implementable someone will complain?

I just want that anyone can run trace.pl and see how virtual engine 
behaves, without having to recompile the kernel. And VTune people want 
the same for their enterprise-level customers. Both tools are ready to 
adapt should it be required. Its I repeat just usability and user 
experience out of the box.

> 
>>>> And with the Virtual Engine it will become more interesting to have
>>>> this. So if we had a bug report saying load balancing is not working
>>>> well, we could just say "please run it via trace.pl --trace and attach
>>>> perf script output". That way we could easily see whether or not is is a
>>>> problem in userspace behaviour or else.
>>>
>>> And there I was wanting a script to capture the workload so that we
>>> could replay it and dissect it. :-p
>>
>> Depends on what level you want that. Perf script output from the above
>> tracepoints would do on one level. If you wanted a higher level to
>> re-exercise load balancing then it wouldn't completely be enough, or at
>> least a lot of guesswork would be needed.
> 
> It all depends on what level you want to optimise, is the way I look at
> it. Userspace driver, you capture the client->driver userspace API (e.g.
> cairo-trace, apitrace). But for optimising scheduling layout, we just
> need a workload descriptor like wsim -- with perhaps the only tweak
> being able to define latency/throughput metrics relevant to that
> workload, and being able to integrate with a pseudo display server. The
> challenge as I see it is being able to convince the user that it is a
> useful diagnosis step and being able to generate a reasonable wsim
> automatically.

To derive wsim's from apitraces sounds much more challenging but also I 
think is orthogonal. Tracing could be always there on the low level 
whether the client is real or simulated.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-08-08 13:13:08)
> 
> On 26/06/2018 12:48, Chris Wilson wrote:
> > It's just that this about the third time this has been raised in the
> > last couple of weeks with the other two requests being from a generic
> > tooling pov (Eric Anholt for gnome-shell tweaking, and some one
> > else looking for a gpuvis-like tool). So it seems like there is
> > interest, even if I doubt that it'll help answer any questions beyond
> > what you can just extract from looking at userspace. (Imo, the only
> > people these tracepoints are useful for are people writing patches for
> > the driver. For everyone else, you can just observe system behaviour and
> > optimise your code for your workload. Otoh, can one trust a black
> > box, argh.)
> 
> Some of the things might be obtainable purely from userspace via heavily 
> instrumented builds, which may be in the realm of possible for during 
> development, but I don't think it is feasible in general both because it 
> is too involved, and because it would preclude existence of tools which 
> can trace any random client.
> 
> > To have a second set of nearly equivalent tracepoints, we need to have
> > strong justification why we couldn't just use or extend the generic set.
> 
> I was hoping that the conversation so far established that nearly 
> equivalent is not close enough for intended use cases. And that is not 
> possible to make the generic ones so.

(I just don't see the point of those use cases. I trace the kernel to
fix the kernel...)
 
> > Plus I feel a lot more comfortable exporting a set of generic
> > tracepoints, than those where we may be leaking more knowledge of the HW
> > than we can reasonably expect to support for the indefinite future.
> 
> I think it is accepted we cannot guarantee low level tracepoints will be 
> supportable in the future world of GuC scheduling. (How and what we will 
> do there is yet unresolved.) But at least we get much better usability 
> for platforms up to there, and for very small effort. The idea is not to 
> mark these as ABI but just improve user experience.
> 
> You are I suppose worried that if these tracepoints disappeared due 
> being un-implementable someone will complain?

They already do...
 
> I just want that anyone can run trace.pl and see how virtual engine 
> behaves, without having to recompile the kernel. And VTune people want 
> the same for their enterprise-level customers. Both tools are ready to 
> adapt should it be required. Its I repeat just usability and user 
> experience out of the box.

The out-of-the-box user experience should not require the use of such
tools in the first place! If they are trying to work around the kernel
(and that's the only use of this information I see) we have bugs a
plenty.

[snip because I repeated myself]

I think my issues boil down to:

 1 - people will complain no matter what (when it changes, when it is no
     longer available)

 2 - people will use it to workaround not fix; the information about kernel
     behaviour should only be used with a view to fixing that behaviour

As such, I am quite happy to have it limited to driver developers that
want to fix issues at source (OpenCL, I'm looking at you). There's tons
of other user observable information out there for tuning userspace,
why does the latency of runnable->queued matter if you will not do anything
about it? Other things like dependency graphs, if you can't keep control
of your own fences, you've already lost.

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.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

+Joonas

On 08/08/2018 13:42, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-08-08 13:13:08)
>>
>> On 26/06/2018 12:48, Chris Wilson wrote:
>>> It's just that this about the third time this has been raised in the
>>> last couple of weeks with the other two requests being from a generic
>>> tooling pov (Eric Anholt for gnome-shell tweaking, and some one
>>> else looking for a gpuvis-like tool). So it seems like there is
>>> interest, even if I doubt that it'll help answer any questions beyond
>>> what you can just extract from looking at userspace. (Imo, the only
>>> people these tracepoints are useful for are people writing patches for
>>> the driver. For everyone else, you can just observe system behaviour and
>>> optimise your code for your workload. Otoh, can one trust a black
>>> box, argh.)
>>
>> Some of the things might be obtainable purely from userspace via heavily
>> instrumented builds, which may be in the realm of possible for during
>> development, but I don't think it is feasible in general both because it
>> is too involved, and because it would preclude existence of tools which
>> can trace any random client.
>>
>>> To have a second set of nearly equivalent tracepoints, we need to have
>>> strong justification why we couldn't just use or extend the generic set.
>>
>> I was hoping that the conversation so far established that nearly
>> equivalent is not close enough for intended use cases. And that is not
>> possible to make the generic ones so.
> 
> (I just don't see the point of those use cases. I trace the kernel to
> fix the kernel...)

Yes and with virtual engine we will have a bigger reason to trace the 
kernel with a random client.

>   
>>> Plus I feel a lot more comfortable exporting a set of generic
>>> tracepoints, than those where we may be leaking more knowledge of the HW
>>> than we can reasonably expect to support for the indefinite future.
>>
>> I think it is accepted we cannot guarantee low level tracepoints will be
>> supportable in the future world of GuC scheduling. (How and what we will
>> do there is yet unresolved.) But at least we get much better usability
>> for platforms up to there, and for very small effort. The idea is not to
>> mark these as ABI but just improve user experience.
>>
>> You are I suppose worried that if these tracepoints disappeared due
>> being un-implementable someone will complain?
> 
> They already do...
>   
>> I just want that anyone can run trace.pl and see how virtual engine
>> behaves, without having to recompile the kernel. And VTune people want
>> the same for their enterprise-level customers. Both tools are ready to
>> adapt should it be required. Its I repeat just usability and user
>> experience out of the box.
> 
> The out-of-the-box user experience should not require the use of such
> tools in the first place! If they are trying to work around the kernel
> (and that's the only use of this information I see) we have bugs a
> plenty.
> 
> [snip because I repeated myself]
> 
> I think my issues boil down to:
> 
>   1 - people will complain no matter what (when it changes, when it is no
>       longer available)
> 
>   2 - people will use it to workaround not fix; the information about kernel
>       behaviour should only be used with a view to fixing that behaviour
> 
> As such, I am quite happy to have it limited to driver developers that
> want to fix issues at source (OpenCL, I'm looking at you). There's tons
> of other user observable information out there for tuning userspace,
> why does the latency of runnable->queued matter if you will not do anything
> about it? Other things like dependency graphs, if you can't keep control
> of your own fences, you've already lost.

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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Joonas Lahtinen]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Kukanova, Svetlana]

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@lists.freedesktop.org] On Behalf Of Joonas Lahtinen
Sent: Monday, August 13, 2018 12:55 PM
To: Chris Wilson <chris@chris-wilson.co.uk>; Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Joonas Lahtinen]

Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> 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? 

Hi,

You actually mentioned the prime reason why we should not go and
hastily make tracepoints a stable uAPI with regards to scheduling
information.

The scheduler's nature will be evolving when some of the scheduling
decisions are moved to GuC and the way how we get the information
will be changing at that point, so tracepoints will indeed be a
very bad mechanism for providing the information.

The kernel scheduler is definitely not going anywhere with the
introduction of more hardware scheduling capabilities, so it is a
misconception to think that the interface would need to be completely
different for when GuC is enabled.

> 
> 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).

gpuvis is a developer tool. The tracepoints behind this configure
switch are way more low-level than what the gpuvis seems to support
for AMDGPU *at all*. They seem to stick to IOCTL level. So from what
I see, we should be on-par with the competition even without any special
kernel configuration. So lets not get things mixed up.

And I remind, the tool is not shipping anywhere really (except the AUR),
but just built from source by developers in need, and they seem to be just
fine with re-compiling the kernel (as there have been no requests).

Once there is an actual request to have some metrics from vanilla
kernels through some end-user tools (not a developer tool, like here),
I'll be glad to discuss about how to provide the information the best
for them in a stable manner.

> 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.

I'm well aware of the use cases. And Dmitry is well aware of the need
for an Open Source consumer for any requested stable uAPIs. And we don't
currently have that, so there's no disconnect on information.

There's just no Open Source tool to first design and then validate the
interfaces against. There's just the debugging tool which happens to
work currently, without any guarantees that next kernel version would
not cause a substantial rework of the interfacing code.

The interface discussion would probably start from a DRM subsystem
level, so that the tool would have an equivalent level of base
experience from all drivers.

Regards, Joonas

> 
> Thank you,
> Svetlana
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Joonas Lahtinen
> Sent: Monday, August 13, 2018 12:55 PM
> To: Chris Wilson <chris@chris-wilson.co.uk>; Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

On 21/08/2018 13:06, Joonas Lahtinen wrote:
> Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
>> 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?
> 
> Hi,
> 
> You actually mentioned the prime reason why we should not go and
> hastily make tracepoints a stable uAPI with regards to scheduling
> information.
> 
> The scheduler's nature will be evolving when some of the scheduling
> decisions are moved to GuC and the way how we get the information
> will be changing at that point, so tracepoints will indeed be a
> very bad mechanism for providing the information.
> 
> The kernel scheduler is definitely not going anywhere with the
> introduction of more hardware scheduling capabilities, so it is a
> misconception to think that the interface would need to be completely
> different for when GuC is enabled.

On the last paragraph - even with the today's GuC i915 already loses 
visibility of CSB interrupts. So there is already a big difference in 
semantics of what request_in and request_out tracepoints mean. Put 
preemption into the picture and we just don't know any more when 
something started executing on the GPU, when it got preempted, 
re-submitted etc. So I think it is fair to say that moving more of 
scheduling into the GuC creates a problem for tools which want to 
represent request execution timelines.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Tvrtko Ursulin]

On 22/08/2018 13:49, Tvrtko Ursulin wrote:
> 
> On 21/08/2018 13:06, Joonas Lahtinen wrote:
>> Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
>>> 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?
>>
>> Hi,
>>
>> You actually mentioned the prime reason why we should not go and
>> hastily make tracepoints a stable uAPI with regards to scheduling
>> information.
>>
>> The scheduler's nature will be evolving when some of the scheduling
>> decisions are moved to GuC and the way how we get the information
>> will be changing at that point, so tracepoints will indeed be a
>> very bad mechanism for providing the information.
>>
>> The kernel scheduler is definitely not going anywhere with the
>> introduction of more hardware scheduling capabilities, so it is a
>> misconception to think that the interface would need to be completely
>> different for when GuC is enabled.
> 
> On the last paragraph - even with the today's GuC i915 already loses 
> visibility of CSB interrupts. So there is already a big difference in 
> semantics of what request_in and request_out tracepoints mean. Put 
> preemption into the picture and we just don't know any more when 
> something started executing on the GPU, when it got preempted, 
> re-submitted etc. So I think it is fair to say that moving more of 
> scheduling into the GuC creates a problem for tools which want to 
> represent request execution timelines.

P.S. To clarify - which is exactly why we marked those tracpoints as low 
level and why it is problematic to rely on them.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2018-08-22 15:49:52)
> 
> On 21/08/2018 13:06, Joonas Lahtinen wrote:
> > Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> >> 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?
> > 
> > Hi,
> > 
> > You actually mentioned the prime reason why we should not go and
> > hastily make tracepoints a stable uAPI with regards to scheduling
> > information.
> > 
> > The scheduler's nature will be evolving when some of the scheduling
> > decisions are moved to GuC and the way how we get the information
> > will be changing at that point, so tracepoints will indeed be a
> > very bad mechanism for providing the information.
> > 
> > The kernel scheduler is definitely not going anywhere with the
> > introduction of more hardware scheduling capabilities, so it is a
> > misconception to think that the interface would need to be completely
> > different for when GuC is enabled.

To clarify, I meant to underline that there is not going to be a steep
switching point where a transition from interface A to B, which Svetlana
referred to, would happen naturally.

The introduced interface will have to provide the information for years
and kernel versions to come, and we already have a some data that
tracepoints may not be the format of choice due to GuC.

> On the last paragraph - even with the today's GuC i915 already loses 
> visibility of CSB interrupts. So there is already a big difference in 
> semantics of what request_in and request_out tracepoints mean. Put 
> preemption into the picture and we just don't know any more when 
> something started executing on the GPU, when it got preempted, 
> re-submitted etc. So I think it is fair to say that moving more of 
> scheduling into the GuC creates a problem for tools which want to 
> represent request execution timelines.

Yes, for tools that depend on the tracepoints. That's why it is most
likely best to introduce the information in some other form, but I am
starting to sound like a broken record already :)

Regards, Joonas

> 
> Regards,
> 
> Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Kukanova, Svetlana]

> Once there is an actual request to have some metrics from vanilla kernels through some end-user tools (not a developer tool, like here), I'll be glad to discuss about how to provide the information the best for them in a stable manner.

Sorry for my ignorance, but looks like I don't understand what developer vs. end-user means here.
With regard to GPU profiling VTune's end-user is somebody who develops gfx or media applications basing on MediaSDK, OpenCL, C for Media, etc.
Or, more often it's an intel application engineer working with those people's code. 
AE in his\her turn may contact e.g. Dmitry's team if judging by VTune data he\she decides that the problem is on the deeper level of the gfx stack, not in the customer's code.
Then Dmitry's team would be experimenting with VTune and deciding if the problem is in their code or it's deeper in i915.
Don't think that i915 people use VTune (sadly:)) so here the chain is broken. Otherwise they could e.g. blame HW based on the same data.
I'm wondering who in this chain (app developer, AE, Dmitry, i915) is an "end-user" and who's a "developer"? 
Or is a "developer" a kernel developer only? 
And e.g. Dmitry is an end-user and thus he is not supposed to use tools like gpuvis or VTune?
Looks like all the chain before i915 is annoyed by the kernel-rebuilding requirement.

>The interface discussion would probably start from a DRM subsystem level, so that the tool would have an equivalent level of base experience from all drivers.

That sounds like a solution from an ideal world. I mean if DRM had a uAPI for scheduling observability and all the drivers had to implement this. And the drivers would require info from HW like GuC pointing to the necessity of uAPI support... 
Would be just great for all the tools (, developers and end-users). 
But I have no idea what kind of impulse should it be to bring this to reality. And if all the energy available to human kind at the given evolution point would be enough to at least start this. 
Or am I just too pessimistic? Are there some simple defined steps to be done to make it? Can we build a realistic plan?

E.g. is this the first step? -
> There's just no Open Source tool to first design and then validate the interfaces against. There's just the debugging tool which happens to work currently, without any guarantees that next kernel version would not cause a substantial rework of the interfacing code.

How does it usually work, I mean you can't have a widely shipped open-source consumer already using a non-existent feature that is to be requested? 
And I can't imagine what kind of existing tool should it be to decide suddenly that it needs to add GPU scheduling tracing to the list of its features.
If you want to have a new tool for GPU scheduling timeline - and it sounds like a sane idea, looks like we agree on the use cases etc. - how can you make it open source first and then get the API to be based on from i915?
Or am I just missing the point completely?
If the open-sourced MediaSDK was shipped with some distro (isn't it, btw?) - would Dmitry be eligible to request observability features for tools?

Thank you,
Svetlana

-----Original Message-----
From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
Sent: Tuesday, August 21, 2018 3:07 PM
To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> 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? 

Hi,

You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information.

The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information.

The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled.

> 
> 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).

gpuvis is a developer tool. The tracepoints behind this configure switch are way more low-level than what the gpuvis seems to support for AMDGPU *at all*. They seem to stick to IOCTL level. So from what I see, we should be on-par with the competition even without any special kernel configuration. So lets not get things mixed up.

And I remind, the tool is not shipping anywhere really (except the AUR), but just built from source by developers in need, and they seem to be just fine with re-compiling the kernel (as there have been no requests).

Once there is an actual request to have some metrics from vanilla kernels through some end-user tools (not a developer tool, like here), I'll be glad to discuss about how to provide the information the best for them in a stable manner.

> 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.

I'm well aware of the use cases. And Dmitry is well aware of the need for an Open Source consumer for any requested stable uAPIs. And we don't currently have that, so there's no disconnect on information.

There's just no Open Source tool to first design and then validate the interfaces against. There's just the debugging tool which happens to work currently, without any guarantees that next kernel version would not cause a substantial rework of the interfacing code.

The interface discussion would probably start from a DRM subsystem level, so that the tool would have an equivalent level of base experience from all drivers.

Regards, Joonas

> 
> Thank you,
> Svetlana
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> Behalf Of Joonas Lahtinen
> Sent: Monday, August 13, 2018 12:55 PM
> To: Chris Wilson <chris@chris-wilson.co.uk>; 
> Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin 
> <tursulin@ursulin.net>; Tvrtko Ursulin 
> <tvrtko.ursulin@linux.intel.com>
> Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Joonas Lahtinen]

Quoting Kukanova, Svetlana (2018-08-27 16:37:14)
> > Once there is an actual request to have some metrics from vanilla kernels
> > through some end-user tools (not a developer tool, like here), I'll be glad
> > to discuss about how to provide the information the best for them in a
> > stable manner.
> 
> Sorry for my ignorance, but looks like I don't understand what developer vs.
> end-user means here.
> With regard to GPU profiling VTune's end-user is somebody who develops gfx or
> media applications basing on MediaSDK, OpenCL, C for Media, etc.
> Or, more often it's an intel application engineer working with those people's
> code.
> AE in his\her turn may contact e.g. Dmitry's team if judging by VTune data
> he\she decides that the problem is on the deeper level of the gfx stack, not
> in the customer's code.
> Then Dmitry's team would be experimenting with VTune and deciding if the
> problem is in their code or it's deeper in i915.
> Don't think that i915 people use VTune (sadly:)) so here the chain is broken.
> Otherwise they could e.g. blame HW based on the same data.
> I'm wondering who in this chain (app developer, AE, Dmitry, i915) is an
> "end-user" and who's a "developer"?
> Or is a "developer" a kernel developer only?
> And e.g. Dmitry is an end-user and thus he is not supposed to use tools like
> gpuvis or VTune?
> Looks like all the chain before i915 is annoyed by the kernel-rebuilding
> requirement.

With end-user tool I'm referring to something that would have interest
in being packaged and shipped by a distro.

gpuvis team seems to be doing fine with the application being built from source
and being run against a specially configured kernel for their purposes. I would
assume there to be some queries about a enabling the tracepoints by default if
there was demand. At the same time I would assume them to try to get the
application packaged and into distros.

And then we would commence discussing how to provide the information in a stable
manner (most likely outside tracepoints). So far I'm not seeing such queries
from gpuvis direction.

> > The interface discussion would probably start from a DRM subsystem level, so
> > that the tool would have an equivalent level of base experience from all
> > drivers.
>
> That sounds like a solution from an ideal world. I mean if DRM had a uAPI for
> scheduling observability and all the drivers had to implement this. And the
> drivers would require info from HW like GuC pointing to the necessity of uAPI
> support...
> Would be just great for all the tools (, developers and end-users).
> But I have no idea what kind of impulse should it be to bring this to reality.
> And if all the energy available to human kind at the given evolution point
> would be enough to at least start this. 
> Or am I just too pessimistic? Are there some simple defined steps to be done
> to make it? Can we build a realistic plan?

Step is "1. Have the tool" :) There seem to be three options: 1) open sourcing
VTune 2) contributing to gpuvis project to drive the project into the above
mentioned direction. 3) writing a new project from scratch (not encouraged,
unless you have something differentiating to bring to the table).

Unless somebody actively drives the feature to some Open Source userspace
consumer, there won't be an interface for the information from kernel.
Demand from an Open Source application is a hard requirement for kickstarting
the interface discussion.

> E.g. is this the first step? -
> > There's just no Open Source tool to first design and then validate the
> > interfaces against. There's just the debugging tool which happens to work
> > currently, without any guarantees that next kernel version would not cause a
> > substantial rework of the interfacing code.
> 
> How does it usually work, I mean you can't have a widely shipped open-source
> consumer already using a non-existent feature that is to be requested? 
> And I can't imagine what kind of existing tool should it be to decide suddenly
> that it needs to add GPU scheduling tracing to the list of its features.
> If you want to have a new tool for GPU scheduling timeline - and it sounds
> like a sane idea, looks like we agree on the use cases etc. - how can you make
> it open source first and then get the API to be based on from i915?

The order is that you develop the tool and the required kernel changes
in parallel in topic branches, to demonstrate the usefulness of the tool
and suitability of the kernel interface. Then after all the patches are
reviewed (kernel + tool), kernel side is merged first, and then the tool
can start working from next kernel release.

This has been attempted to be described in the following
documentation chapter:

https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

> Or am I just missing the point completely?
> If the open-sourced MediaSDK was shipped with some distro (isn't it, btw?) -
> would Dmitry be eligible to request observability features for tools?

MediaSDK should not have anything to do with this, unless it will directly
consume the kernel interface in discussion.

The need is for some application/library/whatever userspace component to
demonstrate the suitability of the kernel interface and act as a counterpart
for the kernel interface that can be tested and debugged for changes.
This too, is explained in more detail in the above linked documentation
chapter.

Regards, Joonas

> 
> Thank you,
> Svetlana
> 
> -----Original Message-----
> From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
> Sent: Tuesday, August 21, 2018 3:07 PM
> To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
> 
> Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> > 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? 
> 
> Hi,
> 
> You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information.
> 
> The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information.
> 
> The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled.
> 
> > 
> > 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).
> 
> gpuvis is a developer tool. The tracepoints behind this configure switch are way more low-level than what the gpuvis seems to support for AMDGPU *at all*. They seem to stick to IOCTL level. So from what I see, we should be on-par with the competition even without any special kernel configuration. So lets not get things mixed up.
> 
> And I remind, the tool is not shipping anywhere really (except the AUR), but just built from source by developers in need, and they seem to be just fine with re-compiling the kernel (as there have been no requests).
> 
> Once there is an actual request to have some metrics from vanilla kernels through some end-user tools (not a developer tool, like here), I'll be glad to discuss about how to provide the information the best for them in a stable manner.
> 
> > 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.
> 
> I'm well aware of the use cases. And Dmitry is well aware of the need for an Open Source consumer for any requested stable uAPIs. And we don't currently have that, so there's no disconnect on information.
> 
> There's just no Open Source tool to first design and then validate the interfaces against. There's just the debugging tool which happens to work currently, without any guarantees that next kernel version would not cause a substantial rework of the interfacing code.
> 
> The interface discussion would probably start from a DRM subsystem level, so that the tool would have an equivalent level of base experience from all drivers.
> 
> Regards, Joonas
> 
> > 
> > Thank you,
> > Svetlana
> > 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> > Behalf Of Joonas Lahtinen
> > Sent: Monday, August 13, 2018 12:55 PM
> > To: Chris Wilson <chris@chris-wilson.co.uk>; 
> > Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin 
> > <tursulin@ursulin.net>; Tvrtko Ursulin 
> > <tvrtko.ursulin@linux.intel.com>
> > Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Kukanova, Svetlana]

OK, so no end-user queries matter, just the queries from the tools for end-users do, right?

And with making the open-source tool (shipped by distros, etc.) suitable for negotiations we need to hurry while at least the trace-point mechanism is not yet completely broken and can be used to show usefulness and to have at least something that can be taken to distro?

If the new tool and kernel changes required by it are developed in parallel - you don't have that "shipped by a distro" condition, BTW, right? Or in case of parallel discussion you're deciding if the suggested tool  has rights to exist?

-----Original Message-----
From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
Sent: Wednesday, August 29, 2018 5:52 PM
To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

Quoting Kukanova, Svetlana (2018-08-27 16:37:14)
> > Once there is an actual request to have some metrics from vanilla kernels
> > through some end-user tools (not a developer tool, like here), I'll be glad
> > to discuss about how to provide the information the best for them in a
> > stable manner.
> 
> Sorry for my ignorance, but looks like I don't understand what developer vs.
> end-user means here.
> With regard to GPU profiling VTune's end-user is somebody who develops gfx or
> media applications basing on MediaSDK, OpenCL, C for Media, etc.
> Or, more often it's an intel application engineer working with those people's
> code.
> AE in his\her turn may contact e.g. Dmitry's team if judging by VTune data
> he\she decides that the problem is on the deeper level of the gfx stack, not
> in the customer's code.
> Then Dmitry's team would be experimenting with VTune and deciding if the
> problem is in their code or it's deeper in i915.
> Don't think that i915 people use VTune (sadly:)) so here the chain is broken.
> Otherwise they could e.g. blame HW based on the same data.
> I'm wondering who in this chain (app developer, AE, Dmitry, i915) is an
> "end-user" and who's a "developer"?
> Or is a "developer" a kernel developer only?
> And e.g. Dmitry is an end-user and thus he is not supposed to use tools like
> gpuvis or VTune?
> Looks like all the chain before i915 is annoyed by the kernel-rebuilding
> requirement.

With end-user tool I'm referring to something that would have interest
in being packaged and shipped by a distro.

gpuvis team seems to be doing fine with the application being built from source
and being run against a specially configured kernel for their purposes. I would
assume there to be some queries about a enabling the tracepoints by default if
there was demand. At the same time I would assume them to try to get the
application packaged and into distros.

And then we would commence discussing how to provide the information in a stable
manner (most likely outside tracepoints). So far I'm not seeing such queries
from gpuvis direction.

> > The interface discussion would probably start from a DRM subsystem level, so
> > that the tool would have an equivalent level of base experience from all
> > drivers.
>
> That sounds like a solution from an ideal world. I mean if DRM had a uAPI for
> scheduling observability and all the drivers had to implement this. And the
> drivers would require info from HW like GuC pointing to the necessity of uAPI
> support...
> Would be just great for all the tools (, developers and end-users).
> But I have no idea what kind of impulse should it be to bring this to reality.
> And if all the energy available to human kind at the given evolution point
> would be enough to at least start this. 
> Or am I just too pessimistic? Are there some simple defined steps to be done
> to make it? Can we build a realistic plan?

Step is "1. Have the tool" :) There seem to be three options: 1) open sourcing
VTune 2) contributing to gpuvis project to drive the project into the above
mentioned direction. 3) writing a new project from scratch (not encouraged,
unless you have something differentiating to bring to the table).

Unless somebody actively drives the feature to some Open Source userspace
consumer, there won't be an interface for the information from kernel.
Demand from an Open Source application is a hard requirement for kickstarting
the interface discussion.

> E.g. is this the first step? -
> > There's just no Open Source tool to first design and then validate the
> > interfaces against. There's just the debugging tool which happens to work
> > currently, without any guarantees that next kernel version would not cause a
> > substantial rework of the interfacing code.
> 
> How does it usually work, I mean you can't have a widely shipped open-source
> consumer already using a non-existent feature that is to be requested? 
> And I can't imagine what kind of existing tool should it be to decide suddenly
> that it needs to add GPU scheduling tracing to the list of its features.
> If you want to have a new tool for GPU scheduling timeline - and it sounds
> like a sane idea, looks like we agree on the use cases etc. - how can you make
> it open source first and then get the API to be based on from i915?

The order is that you develop the tool and the required kernel changes
in parallel in topic branches, to demonstrate the usefulness of the tool
and suitability of the kernel interface. Then after all the patches are
reviewed (kernel + tool), kernel side is merged first, and then the tool
can start working from next kernel release.

This has been attempted to be described in the following
documentation chapter:

https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

> Or am I just missing the point completely?
> If the open-sourced MediaSDK was shipped with some distro (isn't it, btw?) -
> would Dmitry be eligible to request observability features for tools?

MediaSDK should not have anything to do with this, unless it will directly
consume the kernel interface in discussion.

The need is for some application/library/whatever userspace component to
demonstrate the suitability of the kernel interface and act as a counterpart
for the kernel interface that can be tested and debugged for changes.
This too, is explained in more detail in the above linked documentation
chapter.

Regards, Joonas

> 
> Thank you,
> Svetlana
> 
> -----Original Message-----
> From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
> Sent: Tuesday, August 21, 2018 3:07 PM
> To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
> 
> Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> > 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? 
> 
> Hi,
> 
> You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information.
> 
> The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information.
> 
> The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled.
> 
> > 
> > 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).
> 
> gpuvis is a developer tool. The tracepoints behind this configure switch are way more low-level than what the gpuvis seems to support for AMDGPU *at all*. They seem to stick to IOCTL level. So from what I see, we should be on-par with the competition even without any special kernel configuration. So lets not get things mixed up.
> 
> And I remind, the tool is not shipping anywhere really (except the AUR), but just built from source by developers in need, and they seem to be just fine with re-compiling the kernel (as there have been no requests).
> 
> Once there is an actual request to have some metrics from vanilla kernels through some end-user tools (not a developer tool, like here), I'll be glad to discuss about how to provide the information the best for them in a stable manner.
> 
> > 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.
> 
> I'm well aware of the use cases. And Dmitry is well aware of the need for an Open Source consumer for any requested stable uAPIs. And we don't currently have that, so there's no disconnect on information.
> 
> There's just no Open Source tool to first design and then validate the interfaces against. There's just the debugging tool which happens to work currently, without any guarantees that next kernel version would not cause a substantial rework of the interfacing code.
> 
> The interface discussion would probably start from a DRM subsystem level, so that the tool would have an equivalent level of base experience from all drivers.
> 
> Regards, Joonas
> 
> > 
> > Thank you,
> > Svetlana
> > 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> > Behalf Of Joonas Lahtinen
> > Sent: Monday, August 13, 2018 12:55 PM
> > To: Chris Wilson <chris@chris-wilson.co.uk>; 
> > Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin 
> > <tursulin@ursulin.net>; Tvrtko Ursulin 
> > <tvrtko.ursulin@linux.intel.com>
> > Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
> > 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

[Joonas Lahtinen]

Quoting Kukanova, Svetlana (2018-09-03 15:22:20)
> OK, so no end-user queries matter, just the queries from the tools for
> end-users do, right?

End-user queries do matter, but we don't have the bandwidth to implement
all the tools/software in the world. So for those reasons, we need to
have the interest from a party that is ready to implement the software.

So to proceed at a technical level, interest from developer of a tool is
needed. Simple as that.

> And with making the open-source tool (shipped by distros, etc.) suitable
> for negotiations we need to hurry while at least the trace-point mechanism
> is not yet completely broken and can be used to show usefulness and to have
> at least something that can be taken to distro?

I'm not sure I understood the question, but anything shipping to distros
as stable tool should not depend on tracepoints. Not even initially, as
tracepoints are volatile to change between kernel updates.

> If the new tool and kernel changes required by it are developed in parallel -
> you don't have that "shipped by a distro" condition, BTW, right? Or in case of
> parallel discussion you're deciding if the suggested tool  has rights to
> exist?

Usually a tool/software would be already established before it requests
some kernel changes. That'd of course require it to be useful before
introducing the new interfaces.

If the tools existence is completely reliant on some new interface provided
by kernel (like here), then we would like to get a green light from some
distro that they are interested in packaging the suggested software to
accompany the kernel changes. It all comes down to negotiating and
collaborating with the community.

This is pretty theoretical discussion before there is somebody stepping
up to develop and maintain the tool. So I'll stop here until that
happens.

Regards, Joonas

> -----Original Message-----
> From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
> Sent: Wednesday, August 29, 2018 5:52 PM
> To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
> 
> Quoting Kukanova, Svetlana (2018-08-27 16:37:14)
> > > Once there is an actual request to have some metrics from vanilla kernels
> > > through some end-user tools (not a developer tool, like here), I'll be glad
> > > to discuss about how to provide the information the best for them in a
> > > stable manner.
> > 
> > Sorry for my ignorance, but looks like I don't understand what developer vs.
> > end-user means here.
> > With regard to GPU profiling VTune's end-user is somebody who develops gfx or
> > media applications basing on MediaSDK, OpenCL, C for Media, etc.
> > Or, more often it's an intel application engineer working with those people's
> > code.
> > AE in his\her turn may contact e.g. Dmitry's team if judging by VTune data
> > he\she decides that the problem is on the deeper level of the gfx stack, not
> > in the customer's code.
> > Then Dmitry's team would be experimenting with VTune and deciding if the
> > problem is in their code or it's deeper in i915.
> > Don't think that i915 people use VTune (sadly:)) so here the chain is broken.
> > Otherwise they could e.g. blame HW based on the same data.
> > I'm wondering who in this chain (app developer, AE, Dmitry, i915) is an
> > "end-user" and who's a "developer"?
> > Or is a "developer" a kernel developer only?
> > And e.g. Dmitry is an end-user and thus he is not supposed to use tools like
> > gpuvis or VTune?
> > Looks like all the chain before i915 is annoyed by the kernel-rebuilding
> > requirement.
> 
> With end-user tool I'm referring to something that would have interest
> in being packaged and shipped by a distro.
> 
> gpuvis team seems to be doing fine with the application being built from source
> and being run against a specially configured kernel for their purposes. I would
> assume there to be some queries about a enabling the tracepoints by default if
> there was demand. At the same time I would assume them to try to get the
> application packaged and into distros.
> 
> And then we would commence discussing how to provide the information in a stable
> manner (most likely outside tracepoints). So far I'm not seeing such queries
> from gpuvis direction.
> 
> > > The interface discussion would probably start from a DRM subsystem level, so
> > > that the tool would have an equivalent level of base experience from all
> > > drivers.
> >
> > That sounds like a solution from an ideal world. I mean if DRM had a uAPI for
> > scheduling observability and all the drivers had to implement this. And the
> > drivers would require info from HW like GuC pointing to the necessity of uAPI
> > support...
> > Would be just great for all the tools (, developers and end-users).
> > But I have no idea what kind of impulse should it be to bring this to reality.
> > And if all the energy available to human kind at the given evolution point
> > would be enough to at least start this. 
> > Or am I just too pessimistic? Are there some simple defined steps to be done
> > to make it? Can we build a realistic plan?
> 
> Step is "1. Have the tool" :) There seem to be three options: 1) open sourcing
> VTune 2) contributing to gpuvis project to drive the project into the above
> mentioned direction. 3) writing a new project from scratch (not encouraged,
> unless you have something differentiating to bring to the table).
> 
> Unless somebody actively drives the feature to some Open Source userspace
> consumer, there won't be an interface for the information from kernel.
> Demand from an Open Source application is a hard requirement for kickstarting
> the interface discussion.
> 
> > E.g. is this the first step? -
> > > There's just no Open Source tool to first design and then validate the
> > > interfaces against. There's just the debugging tool which happens to work
> > > currently, without any guarantees that next kernel version would not cause a
> > > substantial rework of the interfacing code.
> > 
> > How does it usually work, I mean you can't have a widely shipped open-source
> > consumer already using a non-existent feature that is to be requested? 
> > And I can't imagine what kind of existing tool should it be to decide suddenly
> > that it needs to add GPU scheduling tracing to the list of its features.
> > If you want to have a new tool for GPU scheduling timeline - and it sounds
> > like a sane idea, looks like we agree on the use cases etc. - how can you make
> > it open source first and then get the API to be based on from i915?
> 
> The order is that you develop the tool and the required kernel changes
> in parallel in topic branches, to demonstrate the usefulness of the tool
> and suitability of the kernel interface. Then after all the patches are
> reviewed (kernel + tool), kernel side is merged first, and then the tool
> can start working from next kernel release.
> 
> This has been attempted to be described in the following
> documentation chapter:
> 
> https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> 
> > Or am I just missing the point completely?
> > If the open-sourced MediaSDK was shipped with some distro (isn't it, btw?) -
> > would Dmitry be eligible to request observability features for tools?
> 
> MediaSDK should not have anything to do with this, unless it will directly
> consume the kernel interface in discussion.
> 
> The need is for some application/library/whatever userspace component to
> demonstrate the suitability of the kernel interface and act as a counterpart
> for the kernel interface that can be tested and debugged for changes.
> This too, is explained in more detail in the above linked documentation
> chapter.
> 
> Regards, Joonas
> 
> > 
> > Thank you,
> > Svetlana
> > 
> > -----Original Message-----
> > From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com] 
> > Sent: Tuesday, August 21, 2018 3:07 PM
> > To: Intel-gfx@lists.freedesktop.org; Kukanova, Svetlana <svetlana.kukanova@intel.com>; Chris Wilson <chris@chris-wilson.co.uk>; Tvrtko Ursulin <tursulin@ursulin.net>; Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
> > 
> > Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> > > 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? 
> > 
> > Hi,
> > 
> > You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information.
> > 
> > The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information.
> > 
> > The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled.
> > 
> > > 
> > > 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).
> > 
> > gpuvis is a developer tool. The tracepoints behind this configure switch are way more low-level than what the gpuvis seems to support for AMDGPU *at all*. They seem to stick to IOCTL level. So from what I see, we should be on-par with the competition even without any special kernel configuration. So lets not get things mixed up.
> > 
> > And I remind, the tool is not shipping anywhere really (except the AUR), but just built from source by developers in need, and they seem to be just fine with re-compiling the kernel (as there have been no requests).
> > 
> > Once there is an actual request to have some metrics from vanilla kernels through some end-user tools (not a developer tool, like here), I'll be glad to discuss about how to provide the information the best for them in a stable manner.
> > 
> > > 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.
> > 
> > I'm well aware of the use cases. And Dmitry is well aware of the need for an Open Source consumer for any requested stable uAPIs. And we don't currently have that, so there's no disconnect on information.
> > 
> > There's just no Open Source tool to first design and then validate the interfaces against. There's just the debugging tool which happens to work currently, without any guarantees that next kernel version would not cause a substantial rework of the interfacing code.
> > 
> > The interface discussion would probably start from a DRM subsystem level, so that the tool would have an equivalent level of base experience from all drivers.
> > 
> > Regards, Joonas
> > 
> > > 
> > > Thank you,
> > > Svetlana
> > > 
> > > -----Original Message-----
> > > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> > > Behalf Of Joonas Lahtinen
> > > Sent: Monday, August 13, 2018 12:55 PM
> > > To: Chris Wilson <chris@chris-wilson.co.uk>; 
> > > Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin 
> > > <tursulin@ursulin.net>; Tvrtko Ursulin 
> > > <tvrtko.ursulin@linux.intel.com>
> > > Subject: Re: [Intel-gfx] [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@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint
URL   : https://patchwork.freedesktop.org/series/45352/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4375 -> Patchwork_9415 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9415 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9415, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/45352/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9415:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_gttfill@basic:
      fi-pnv-d510:        SKIP -> PASS

    
== Known issues ==

  Here are the changes found in Patchwork_9415 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_chamelium@hdmi-hpd-fast:
      fi-kbl-7500u:       SKIP -> FAIL (fdo#103841, fdo#102672)

    
    ==== Possible fixes ====

    igt@gem_exec_gttfill@basic:
      fi-byt-n2820:       FAIL (fdo#106744) -> PASS

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-bxt-dsi:         INCOMPLETE (fdo#103927) -> PASS

    igt@prime_vgem@basic-fence-flip:
      fi-ilk-650:         FAIL (fdo#104008) -> PASS

    
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744


== Participating hosts (44 -> 39) ==

  Missing    (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

    * Linux: CI_DRM_4375 -> Patchwork_9415

  CI_DRM_4375: 24b1806d544318f5a365c1ef715dc467940af59c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9415: 2db4981bca67578e03040067bdae2fe1a6306a1a @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2db4981bca67 drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
f9db7d32dc47 drm/i915/tracepoints: Remove i915_request_execute tracepoint

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9415/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint
URL   : https://patchwork.freedesktop.org/series/45352/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4375_full -> Patchwork_9415_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9415_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9415_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9415_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-vebox:
      shard-kbl:          SKIP -> PASS

    igt@gem_mocs_settings@mocs-rc6-bsd2:
      shard-kbl:          PASS -> SKIP

    
== Known issues ==

  Here are the changes found in Patchwork_9415_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_gtt:
      shard-glk:          PASS -> INCOMPLETE (fdo#103359, k.org#198133)

    igt@gem_exec_schedule@preemptive-hang-render:
      shard-snb:          SKIP -> INCOMPLETE (fdo#105411)

    igt@gem_softpin@noreloc-s3:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665)

    igt@kms_flip@flip-vs-expired-vblank:
      shard-glk:          PASS -> FAIL (fdo#105189)

    igt@kms_flip@plain-flip-fb-recreate:
      shard-glk:          PASS -> FAIL (fdo#100368)

    
    ==== Possible fixes ====

    igt@gem_ctx_switch@basic-all-light:
      shard-hsw:          INCOMPLETE (fdo#103540) -> PASS

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
      shard-glk:          FAIL (fdo#105703) -> PASS

    igt@kms_flip@2x-plain-flip-fb-recreate:
      shard-glk:          FAIL (fdo#100368) -> PASS

    igt@kms_flip@flip-vs-expired-vblank:
      shard-hsw:          FAIL (fdo#102887, fdo#105363) -> PASS

    igt@kms_flip_tiling@flip-to-x-tiled:
      shard-glk:          FAIL (fdo#104724, fdo#103822) -> PASS +1

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4375 -> Patchwork_9415

  CI_DRM_4375: 24b1806d544318f5a365c1ef715dc467940af59c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9415: 2db4981bca67578e03040067bdae2fe1a6306a1a @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9415/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx