Closed skyreflectedinmirrors closed 1 year ago
Omniperf depends on the underlying profiler (which for most people is rocprofiler) for filtering. Current filtering in rocprofiler is limited. I've implemented a proof of concept of more flexible filtering, will ask for internal feedback in a week or so, and then propose it to the rocprofiler team. Soon (hopefully...), you'll be able to filter to your hearts desire. Than doesn't mean we shouldn't document the current filtering capabilities in some level of detail until the Mother of all Filtering Methods becomes available and can be supported by OmniPerf too, of course.
Agreed -- probably we want to document "filtering mechanisms by profiler", defaulted to rocprofiler, and leave space for "others below"
Hoping @rwvo 's approach gets adoption from rocporfiler. In the future, we may begin officially supporting alternative profilers and when that time comes we'll document those in the profiling section.
For now, we added specificity for the profiling filters available via rocprofiler.
https://github.com/AMDResearch/omniperf/blob/a346db7646b0a935f4cac51d131b4a585f065c05/src/docs/profiling.md?plain=1#L318
We don't really describe this at all. Currently this is a filter based on the global dispatch index of kernels in a run. It's also not clear how this combines with the kernel name filtering. I suspect that if you filter to e.g., dispatch X, but dispatch X does not match your kernel name filter you get no results.
@rwvo may be interested in revamping this... for reasons :)