summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/radeon/r600_query.h
Commit message (Collapse)AuthorAgeFilesLines
* gallium/radeon: implement get_query_result_resource (v2)Nicolai Hähnle2016-09-291-0/+7
| | | | | | | v2: fix a comment (Gustaw Smolarczyk) Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: zero all query buffersNicolai Hähnle2016-09-291-1/+1
| | | | | | | To ensure that fences are properly initialized. Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeonsi: add save_qbo_stateNicolai Hähnle2016-09-291-0/+7
| | | | | | | | Save compute shader state that will be used for the ARB_query_buffer_object implementation. Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeonsi: add HUD queries for counting VS/PS/CS partial flushesMarek Olšák2016-09-051-0/+3
| | | | | | Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: rename the num-cs-flushes query to num-ctx-flushesMarek Olšák2016-09-051-1/+1
| | | | | | | num-cs-flushes will mean compute shader flushes Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add a driver query for AMDGPU_INFO_NUM_EVICTIONSMarek Olšák2016-08-261-0/+1
| | | | | | If the kernel driver doesn't support it, it returns 0. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* gallium/radeon: add HUD queries for mapped VRAM/GTTMarek Olšák2016-08-101-0/+2
| | | | | | mainly for monitoring visible VRAM congestion Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: don't re-create queries for DCC stat gatheringMarek Olšák2016-06-291-0/+2
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add a HUD query for PS draw ratio stats from separate DCCMarek Olšák2016-06-291-0/+1
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add flag R600_QUERY_HW_FLAG_BEGIN_RESUMESMarek Olšák2016-06-291-0/+2
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: boolean -> bool, TRUE -> true, FALSE -> falseMarek Olšák2016-06-251-15/+15
| | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Vedran Miletić <vedran@miletic.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add driver queries for compute/dma call stats and spillsMarek Olšák2016-06-141-0/+4
| | | | | | also print the average count per frame Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeon: handle query buffer allocation and mapping failuresNicolai Hähnle2016-04-211-1/+1
| | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94984 Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeon: wire end_query return value to sw/hw_endNicolai Hähnle2016-04-211-2/+2
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: use enums in r600_query.hMarek Olšák2016-04-181-20/+23
| | | | | Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: remove R600_QUERY_HW_FLAG_TIMERMarek Olšák2016-04-121-2/+1
| | | | | | | not used anymore Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: re-order the SQ_xx performance counter blocksNicolai Hähnle2016-02-051-18/+4
| | | | | | | | This is yet another change motivated by appeasing AMD GPUPerfStudio's hardcoding of performance counter group numbers. Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Acked-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: add GPIN driver query groupNicolai Hähnle2016-02-051-0/+10
| | | | | | | | | This group was used by older versions of AMD GPUPerfStudio (via AMD_performance_monitor) to identify the GPU family, and GPUPerfStudio still complains when it isn't available. Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Acked-by: Marek Olšák <marek.olsak@amd.com>
* radeon: delay the generation of driver query names until first useNicolai Hähnle2015-11-261-5/+5
| | | | | | | This shaves a bit more time off the startup of programs that don't actually use performance counters. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeonsi: implement AMD_performance_monitor for CIK+Nicolai Hähnle2015-11-251-0/+121
| | | | | | | | | | | | | | | | | | Expose most of the performance counter groups that are exposed by Catalyst. Ideally, the driver will work with GPUPerfStudio at some point, but we are not quite there yet. In any case, this is the reason for grouping multiple instances of hardware blocks in the way it is implemented. The counters can also be shown using the Gallium HUD. If one is interested to see how work is distributed across multiple shader engines, one can set the environment variable RADEON_PC_SEPARATE_SE=1 to obtain finer-grained performance counter groups. Part of the implementation is in radeon because an implementation for older hardware would largely follow along the same lines, but exposing a different set of blocks which are programmed slightly differently. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeon: re-prepare query buffers on begin_query for predicate queriesNicolai Hähnle2015-11-201-0/+1
| | | | | | | | | | | | | | | | The point of prepare_buffer is to ensure that the query buffer contains valid initial data for conditional rendering: as long as the buffer is initialized correctly, the GPU is able to tell whether query results have been written already (and wait or fall back to unconditional rendering if desired). This means prepare_buffer needs to be called again when a buffer is reused. Conversely, for queries that cannot be used for conditional rendering (notably pipeline statistics), we can re-use buffers immediately, and they do not need to be initialized. Reviewed-by: Marek Olšák <marek.olsak@amd.com> Tested-by: Andy Furniss <adf.lists@gmail.com>
* radeon: count cs dwords separately for query begin and endNicolai Hähnle2015-11-181-1/+2
| | | | | | This will be important for perfcounter queries. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeon: expose r600_query_hw functions for reuseNicolai Hähnle2015-11-181-0/+10
| | | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com> [Fixed a rebase conflict and re-tested before pushing.]
* radeon: implement r600_query_hw_get_result via function pointersNicolai Hähnle2015-11-181-0/+4
| | | | | | We will need the clear_result override for the batch query implementation. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeon: split hw query buffer handling from cs emitNicolai Hähnle2015-11-181-0/+20
| | | | | | | | | The idea here is that driver queries implemented outside of common code will use the same query buffer handling with different logic for starting and stopping the corresponding counters. Reviewed-by: Marek Olšák <marek.olsak@amd.com> [Fixed a rebase conflict and re-tested before pushing.]
* radeon: convert hardware queries to the new styleNicolai Hähnle2015-11-181-0/+39
| | | | | | | | | Move r600_query and r600_query_hw into the header because we will want to reuse the buffer handling and suspend/resume logic outside of the common radeon code. Reviewed-by: Marek Olšák <marek.olsak@amd.com> [Fixed a rebase conflict and re-tested before pushing.]
* radeon: add query handler function pointersNicolai Hähnle2015-11-181-0/+12
| | | | | | | | The goal here is to be able to move the implementation details of hardware- specific queries (in particular, performance counters) out of the common code. Reviewed-by: Marek Olšák <marek.olsak@amd.com> [Fixed a rebase conflict and re-tested before pushing.]
* radeon: move R600_QUERY_* constants into a new query header fileNicolai Hähnle2015-11-181-0/+49
More query-related structures will have to be moved into their own header file to support hardware-specific performance counters. Reviewed-by: Marek Olšák <marek.olsak@amd.com>