[Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints

[Chris Wilson]

On Fri, Jan 27, 2017 at 02:18:06PM +0000, Tvrtko Ursulin wrote:
> 
> On 27/01/2017 14:07, Chris Wilson wrote:
> >On Fri, Jan 27, 2017 at 01:59:54PM +0000, Tvrtko Ursulin wrote:
> >>On 27/01/2017 12:27, Chris Wilson wrote:
> >>>Hmm. Following on from that we can add the out tracepoint as a
> >>>fence-callback. For the moment, I'd drop guc/legacy
> >>>trace_i915_gem_request_in and we will try something more magical. Though
> >>>once we do enable the fake GuC scheduler we will have an appropriate
> >>>place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as
> >>>the odd one out, but for who arguably the in/out logic is not as
> >>>important.
> >>
> >>Fence signalled is very lazy if no one is listening, no? So until
> >>the GUC backend I thought request_in and deriving the _out from
> >>_notify in userspace would be OK. Meaning enable signalling stays
> >>until then.
> >
> >It's lazy unless we use fence_add_callback(). I was thinking of some
> >magic inside the trace_request_in macro to add something like
> >fence_add_callback(this_fence, __trace_request_out);
> >
> >It still has the problem request_out doesn't work unless request_in is
> >also being watched, but it has the advantage of being the same for all
> >generators (i.e. more convenient for userspace).
> >
> >But as it seems limited to ringbuffer, we may consider it no longer
> >required?
> 
> You mean bank on the GUC backend getting in soon? Yeah, that sounds
> reasonable. I'll drop the sw signalling from notify then.

Considering Joonas asks quite regularly "are we nearly there yet", I
think so.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre