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