aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/state_tracker/st_cb_perfmon.c
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: delay initialization of performance countersNicolai Hähnle2015-11-251-11/+17
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* st/mesa: add support for batch driver queries to perfmonNicolai Hähnle2015-11-201-7/+76
| | | | | | | v2 + v3: forgot null-pointer checks (spotted by Samuel Pitoiset) Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* st/mesa: maintain active perfmon counters in an arrayNicolai Hähnle2015-11-201-32/+49
| | | | | | | | | | | It is easy enough to pre-determine the required size, and arrays are generally better behaved especially when they get large. v2: make sure init_perf_monitor returns true when no counters are active (spotted by Samuel Pitoiset) Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* st/mesa: use BITSET_FOREACH_SET to loop through active perfmon countersNicolai Hähnle2015-11-201-5/+2
| | | | | Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* st/mesa: store mapping from perfmon counter to query typeNicolai Hähnle2015-11-201-42/+32
| | | | | | | | | Previously, when a performance monitor was initialized, an inner loop through all driver queries with string comparisons for each enabled performance monitor counter was used. This hurts when a driver exposes lots of queries. Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* st/mesa: map semantic driver query types to underlying typeNicolai Hähnle2015-11-201-0/+3
| | | | | Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* gallium: remove pipe_driver_query_group_info field typeNicolai Hähnle2015-11-201-30/+0
| | | | | | | | | | | | | | | | | | | This was only used to implement an unnecessarily restrictive interpretation of the spec of AMD_performance_monitor. The spec says A performance monitor consists of a number of hardware and software counters that can be sampled by the GPU and reported back to the application. I guess one could take this as a requirement that counters _must_ be sampled by the GPU, but then why are they called _software_ counters? Besides, there's not much reason _not_ to expose all counters that are available, and this simplifies the code. v3: add a missing change in the nouveau driver (thanks Samuel Pitoiset) Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Samuel Pitoiset <[email protected]>
* st/mesa: fix pipe_query_result result initializerBrian Paul2015-05-051-1/+1
| | | | | | Fixes MSVC build error. Reviewed-by: Ilia Mirkin <[email protected]>
* st/mesa: fix st_NewPerfMonitor() declarationBrian Paul2015-05-051-1/+1
| | | | | | Was missing the context parameter. Fixes MSVC warning. Reviewed-by: Ilia Mirkin <[email protected]>
* st/mesa: implement GL_AMD_performance_monitorChristoph Bumiller2015-05-061-0/+425
This is based on the original patch of Christoph Bumiller. v2 (Samuel Pitoiset): - improve Gallium interface for this extension - rewrite some parts of the original code - fix compilation errors and piglit tests v3: - only enable this extension when the underlying driver expose GPU counters - get rid of the ring buffer of queries v4: - add a debug message when the maximum number of counters has been reached Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Martin Peres <[email protected]>