Quoting Pierre-Loup A. Griffais (2018-12-18 20:14:49) > > On 12/18/18 3:33 AM, Chris Wilson wrote: > > Quoting Michael Sartain (2018-12-18 01:26:03) > >> I'm writing to try and make a case for Tvrtko's "Remove > >> DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig" patch: > >> > >> https://lists.freedesktop.org/archives/intel-gfx/2018-June/169052.html > > > > I'd recommend we just remove the tracepoints as in the very near future > > we will break them and the outlook seems bleak that we can support the > > same information in the future. > > Is it due to moving to a more async (or HW-assisted) submission model? > If so, I assume/hope there's still a way to reflect on when things > completed after the fact? You could still emit tracepoints at the time > when that becomes known, with the time delta marked in the tracepoint > itself. gpuvis supports this, but the syntax it currently uses for it > isn't necessarily important. There's not much value in looking at these > tracepoints fly by in realtime, so being deferred a bit works well for > all scenarios where examining a GPU scheduling trace is useful. When you combine HW-assisted scheduling with the Virtual Engine work we have ongoing, there will basically be a situation where the KMD only indicates to hardware which contexts are ready to execute, and it'll just care when *some* requests finish that userspace is making wait IOCTLs on. So kernel's view will just be that it wrote a request to logical ring, indicated that it's runnable (if it previously wasn't) and then it might or might not want an interrupt on completion. The motive is quite naturally to reduce the flow of unnecessary information between the CPU and GPU during execution. And that reduces a lot with HW-assisted scheduling. But it also reduces the ability to introspect that information from kernel driver. Wiring that information to flow back from the hardware is one task. But forcing kernel to shape hardware events back to tracepoints seems forceful considering current state of tracepoints. There would have to be a triggered kernel activity reading the hardware event ring and converting it to special tracepoints with the timestamp as parameter information specifically for gpuvis to understand. Or you could try to do that live but you would have to basically reintroduce the communication between GPU and kernel driver we just used enormous engineering efforts to get rid of :) Either way, triggered or live, the usefulness with generic ftrace tooling would be reduced. And all this would have to be stable, enabled-by-default in distros with varying application versions (gpuvis), kernel versions and firmware versions (HW-assisted scheduling) through the unversioned tracepoint interface. Having to jump through such hoops makes one think why does the GPU event log have to come through tracepoints? It seem backwards to make kernel go the extra mile, when userspace could just grab the data from an alternative source in well-defined form and interleave the information when displaying. For all that is worth, the thread to read the GPU events and turn them into special tracepoints could be implemented in a userspace daemon, just like you might import syslog from remote system. To me, it seems almost as if folks are too preoccupied with thinking if we somehow can do this through tracepoints, to stop and actually think if we should. Regards, Joonas > > > -Chris > > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx