On Thu, Apr 10, 2014 at 02:07:21PM +0800, Zhenyu Wang wrote: > On 2014.03.28 10:21:50 -0700, bradley.d.volkin@xxxxxxxxx wrote: > > From: Brad Volkin <bradley.d.volkin@xxxxxxxxx> > > > > There is some thought that the data from the performance counters enabled > > via OACONTROL should only be available to the process that enabled counting. > > To limit snooping, require that any batch buffer which sets OACONTROL to a > > non-zero value also sets it back to 0 before the end of the batch. > > > > I think this might be too strict although there's good point in this. > But it makes almost impossible to insert mi report count command to probe > GPU statistics from kind of third-party tool or lib. At least in the case of mesa you _must_ use mesa (or whatever your gl library is) to insert the MI_PERF cmd at just the rigth spots in the command stream and ofc flush all outstanding vertices and similar things. If you want a global perf sampling support then I think we need to wire up the time-based sampling the hw provides to the perf subsystem. And figure out how to coordinate between mesa wanting to use OA and perf (probably just reject mesa batches or something like that). > Could we have a i915.enable_cmd_parser config that can disable this? As is I don't see a compelling reason. Also if you require the users of your perf tuning tooling to use a module option, you're doing it wrong. This stuff should Just Work. -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
