On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote: > On Tue, Jul 01, 2014 at 05:16:30PM +0000, Mateo Lozano, Oscar wrote: > > > The issue is they need: > > > > > > A) A buffer object. > > > B) Bound to GGTT. > > > C) That userspace knows the GGTT offset of, so that they can program > > > OABUFFER with it. > > > D) That userspace can map so that they can read the reported counters. > > > > > > They used to create a bo, call bo_pin on it, use args->offset to program > > > OABUFFER (via MI_LOAD_REGISTER_IMM, I imagine), map it and read the > > > counter values. They cannot do this anymore. > > > > The answer might be that all of this needs to be done by the kernel > > itself, but then we need to provide an interface to userspace... > > Yes. If you need to pin a buffer for a register, then it needs to be > handled by the kernel. Especially one that provides information about > other users. Short-circuiting the entire discussion here. Afaik there's two OA modes: - inline with the batch with MI_REPORT_PERF - global with the ringbuffer setup with the OABUFFER registers The later should indeed be fully controlled by the kernel as Chris suggested and exposed as an off-cpu performance monitoring unit through the perf subsystem. Chris has rfc patches floating somewhere to do this for other gpu perf data. One fun thing here is the coordination between these two OA modes since iirc they both use the same setup registers for the performance counter configuration. No idea yet how to solve this. But really userspace shouldn't program ggtt offset, not even debug/performance measuring tools. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
