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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux