diff options
author | Kenneth Graunke <[email protected]> | 2013-11-13 15:36:29 -0800 |
---|---|---|
committer | Kenneth Graunke <[email protected]> | 2013-11-21 15:01:14 -0800 |
commit | 2af1aedeca3db2de7c503e9d3b1fec81b9861f1a (patch) | |
tree | 3109cb06c58becff14ca9a41e0328a2a864ad0e7 /src/mesa/swrast/s_span.c | |
parent | 1172974ddddd785e7441d0eb68cc561b4e8d010f (diff) |
i965: Take "bookend" OA snapshots at the start/end of each batch.
Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts. Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.
To work around both of these problems, we have to snapshot the
performance counters at the beginning and end of each batch, similar to
how we handle query objects on platforms that don't support hardware
contexts. I call these "bookend" snapshots.
Since there can be multiple performance monitors active at a time, we
store the bookend snapshots in a global BO, shared by all monitors.
For monitors that span multiple batches, acquiring results involves
adding up three segments:
BeginPerfMonitor --> End of Batch 1 ("head")
Start of Batch 2 --> End of Batch 2
... ("middle")
Start of Batch N-1 --> End of Batch N-1
Start of Batch N --> EndPerfMonitor ("tail")
Monitors that refer to bookend BO snapshots are considered "unresolved".
We delay resolving them (and adding up deltas to obtain the results) as
long as possible to avoid blocking on mapping monitor->oa_bo.
We can also run out of space in the bookend BO, at which point we have
to resolve all unresolved monitors. Then we can throw away the
snapshots and begin writing at the beginning of the buffer.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Diffstat (limited to 'src/mesa/swrast/s_span.c')
0 files changed, 0 insertions, 0 deletions