| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The batch might not have stage == FD_STAGE_BLIT set because
fd_blitter_pipe_begin was sticking the stage on some random batch (or none
at all) rather than the one that would be used in the meta operation.
What we actually wanted to be looking at was set_active_query_state(),
which is already called by util_blitter and whose state we just needed to
track.
Fixes piglit occlusion_query_meta_no_fragments. I haven't changed
query_hw.c's stage handling to clean the rest up because I don't have a
db410c/db820c at home to iterate over the piglit tests.
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4356>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4356>
|
| |
|
|
|
|
|
|
|
|
| |
When we switch batches and start a new draw, we need to cap the queries in
the previous batch and start queries again in the new one.
FD_STAGE_NULL got renamed to 0 so that it would naturally return
!is_active and end the queries at the end of the batch.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4356>
|
| |
|
|
|
|
|
|
|
|
| |
The driver can't determine PIPE_QUERY_PRIMITIVES_GENERATED or
PIPE_QUERY_PRIMITIVES_EMITTED once we support geometry or
tessellation, since these stages add primitives at runtime. Use the
WRITE_PRIMITIVE_COUNTS event to write back the primitive counts and
implement a hw query for this.
Reviewed-by: Rob Clark <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For batch queries we have N different query_type's for one query, so
mapping a single query_type to a sample_provider doesn't really work
out. Instead add a new constructor to construct a query directly
from a sample_provider.
Also, the sample buffer size needs to be determined at runtime, as
it depends on the number of query_types.
Signed-off-by: Rob Clark <[email protected]>
|
| |
|
|
|
|
|
|
| |
Take the query object, rather than the ctx. The ctx ptr isn't hugely
useful but for back queries we will need the query object to properly
get the results.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
Some queries on a4xx and all queries on a5xx can do result accumulation
on CP so we don't need to track per-tile samples. We do still need to
handle pausing/resuming while switching batches (in case the query is
active over multiple draws which are executed out of order).
So introduce new accumulated-query helpers for these sorts of queries,
since it doesn't really fit in cleanly with the original query infra-
structure.
Signed-off-by: Rob Clark <[email protected]>
|
