Hi, On Fri, 2021-02-12 at 18:20 -0800, Rob Clark wrote: > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin > <lionel.g.landwer...@intel.com> wrote: ... > > In our implementation that precision (in particular when a drawcall > > ends) comes at a stalling cost unfortunately. > > yeah, stalling on our end too for per-draw counter snapshots.. but if > you are looking for which shaders to optimize that doesn't matter > *that* much.. they'll be some overhead, but it's not really going to > change which draws/shaders are expensive.. just mean that you lose out > on pipelining of the state changes
I don't think it makes sense to try doing this all in one step. Unless one has resources of Google + commitment for maintaining it, I think doing those steps with separate, dedicated tools can be better fit for Open Source than trying to maintain a monster that tries to do everything of analyzing: - whether performance issue is on GPU side, CPU side, or code being too synchronous - where the bottlenecks are on GPU side - where the bottlenecks are on CPU side - what are the sync points IMHO: - Overall picture should not have too many details, because otherwise one can start chasing irrelevancies [1] - Rest of analysis works better when one concentrate on one performance aspect (shown by the overall picture) at the time. So that activity could have tool dedicated for that purpose - Eero [1] Unless one has HW assisted tool that really can tell *everything* like ARM ETM and Intel PT with *really good* post-processing & visualization tooling. I don't think are usable outside of large companies though because of HW requirements and using them taking a lot of time / expertise (1 sec trace is gigs of data). PS. For checking on shader compiles, I've used two steps: * script to trace frame updates & shader compiles (with ftrace uprobe on appropriate function entry points) + monitor CPU usage & GPU usage (for GPU, freq or power usage is enough) -> shows whether FPS & GPU utilization dip with compiles. Frame updates & compiles are rare enough that ftrace overhead doesn't matter * enable Mesa shader debugging, because in next step one wants to know what shaders they are and how they're compiled _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev