On Sun, Jul 14, 2013 at 01:28:11PM -0700, Ben Widawsky wrote: > On Fri, Jul 12, 2013 at 06:08:27PM +0100, Chris Wilson wrote: > > The TRACE_EVENT_CONDITION is supposed to generate more efficient code > > than if (cond) trace(), which is what we are currently using inside the > > register access functions. > > > > v2: Rebase onto uncore > > > > Signed-off-by: Chris Wilson <[email protected]> > > One thing I've thought about this is a trace_on_once, or trace_on_poll > would be cool for polled reads. Obviously we can post-process it, but we > always risk losing events if we fill up too much of the ringbuffer with > stuff we don't care about.
I see what you mean, having a singular entry would be better than none. We could use a local variable and a new macro. > In any case, I very much like the condition added to the trace itself, > and reading probably the same docs as you agree it should be faster. > > Looking over our code. It looks like I missed trace events when writing > the PTEs in i915_gem_gtt.c. Can you get around to fixing those up? Indeed, we need to do a review of what tracepoints we have and we need. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
