aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/main/performance_monitor.h
Commit message (Collapse)AuthorAgeFilesLines
* mesa: don't leak performance monitors on context destroyIlia Mirkin2013-12-041-0/+3
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.0" <[email protected]>
* mesa: Add core support for the GL_AMD_performance_monitor extension.Kenneth Graunke2013-09-261-0/+85
This provides an interface for applications (and OpenGL-based tools) to access GPU performance counters. Since the exact performance counters available vary between vendors and hardware generations, the extension provides an API the application can use to get the names, types, and minimum/maximum values of all available counters. Counters are also organized into groups. Applications create "performance monitor" objects, select the counters they want to track, and Begin/End monitoring, much like OpenGL's query API. Multiple monitors can be in flight simultaneously. v2: Pass ctx to all driver hooks (suggested by Christoph), and attempt to fix overallocation of bitsets (caught by Christoph). Incomplete. v3: Significantly rework core data structures. Store counters in groups rather than in a global list. Use their array index in the group's counter list as the ID rather than trying to store a globally unique counter ID. Use bitsets for active counters within a group, and also track which groups are active so that's easy to query. v4: Remove _mesa_ prefix on static functions; detect out of memory conditions in new_performance_monitor(); make BeginPerfMonitor hook return a boolean rather than setting m->Active or raising an error. Switch to GLuint/unsigned for NumGroups, NumCounters, and MaxActiveCounters (which also means switching a bunch of temporary variable types). All suggested by Brian Paul. Also, remove commented out code at the bottom of the block. Finally, fix the dispatch sanity test (noticed by Ian Romanick). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> [v3] Reviewed-by: Ian Romanick <[email protected]>