Quoting Tvrtko Ursulin (2018-06-26 11:46:51) > > On 25/06/2018 21:02, Chris Wilson wrote: > > If we know what is wanted can we define that better in terms of > > dma_fence and leave lowlevel for debugging (or think of how we achieve > > the same with generic bpf? kprobes)? Hmm, I wonder how far we can push > > that. > > What is wanted is for instance take trace.pl on any kernel anywhere and > it is able to deduce/draw the exact metrics/timeline of command > submission for an workload. > > At the moment it without low level tracepoints, and without the > intel_engine_notify tweak, it is workload dependent on how close it > could get. Interjecting what dma-fence already has (or we could use), not sure how well userspace can actually map it to their timelines. > > So a set of tracepoints to allow drawing the timeline: > > 1. request_queue (or _add) dma_fence_init > 2. request_submit > 3. intel_engine_notify For obvious reasons, no match in dma_fence. > 4. request_in dma_fence_emit > 5. request out dma_fence_signal (similar, not quite, we would have to force irq signaling). > With this set the above is possible and we don't need a lot of work to > get there. >From a brief glance we are missing a dma_fence_queue for request_submit replacement. So next question is what information do we get from our tracepoints (or more precisely do you use) that we lack in dma_fence? > And with the Virtual Engine it will become more interesting to have > this. So if we had a bug report saying load balancing is not working > well, we could just say "please run it via trace.pl --trace and attach > perf script output". That way we could easily see whether or not is is a > problem in userspace behaviour or else. And there I was wanting a script to capture the workload so that we could replay it and dissect it. :-p -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
