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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Fri Jan 27 14:18:06 UTC 2017

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.



More information about the Intel-gfx mailing list