Move a bit more of the logic shared by all query types (active tracking,
etc) into common code. This avoids introducing a 3rd copy of that logic
for a5xx.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This is also used in gmem code, which executes from the "bottom half"
(ie. from the flush_queue worker thread), so it cannot be in fd_context.
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the state accessed from GMEM+submit factored out of fd_context and
into fd_batch, now it is possible to punt this off to a helper thread.
And more importantly, since there are cases where one context might
force the batch-cache to flush another context's batches (ie. when there
are too many in-flight batches), using a per-context helper thread keeps
various different flushes for a given context serialized.
TODO as with batch-cache, there are a few places where we'll need a
mutex to protect critical sections, which is completely missing at the
moment.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Push query state down to batch, and use the resource tracking to figure
out which batch(es) need to be flushed to get the query result.
This means we actually need to allocate the prsc up front, before we
know the size. So we have to add a special way to allocate an un-
backed resource, and then later allocate the backing storage.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Switch to using a pipe_resource (rather than an fd_bo directly) for hw
query result buffers. This is first step towards making queries work
properly with reordered batches, since we'll need the additional
dependency tracking to know which batches to flush.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Note that I originally also had a entry-point that would construct a key
and do lookup from a pipe_surface. I ended up not needing that (yet?)
but it is easy-enough to re-introduce later if we need it for the blit
path.
For now, not enabled by default, but can be enabled (on a3xx/a4xx) with
FD_MESA_DEBUG=reorder.
Signed-off-by: Rob Clark <robdclark@gmail.com>
To flush batches out of order, the gmem code needs to not depend on
state from fd_context (since that may apply to a more recent batch).
So this all moves into batch.
The one exception is the gmem/pipe/tile state itself. But this is
only used from gmem code (and batches are flushed serially). The
alternative would be having to re-calculate GMEM layout on every
batch, even if the dimensions of the render targets are the same.
Note: This opens up the possibility of pushing gmem/submit into a
helper thread.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Introduce the batch object, to track a batch/submit's worth of
ringbuffers and other bookkeeping. In this first step, just move
the ringbuffers into batch, since that is mostly uninteresting
churn.
For now there is just a single batch at a time. Note that one
outcome of this change is that rb's are allocated/freed on each
use. But the expectation is that the bo pool in libdrm_freedreno
will save us the GEM bo alloc/free which was the initial reason
to implement a rb pool in gallium.
The purpose of the batch is to eventually facilitate out-of-order
rendering, with batches associated to framebuffer state, and
tracking the dependencies on other batches.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We need "NULL" state to be a valid bit in the bitmask, because timestamp
queries are not restricted to draw/etc stages (ie. the only commands to
submit may just be to read the timestamp). And just because there are
no draws, isn't a reason to skip the flush and return zero.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Coverity doesn't realize idx will never be negative. Throw in some
assert()s to help it out.
(Hopefully assert() isn't getting compiled out for coverity build.. but
there seems to be just one way to find out. We might have to change
these to assume())
Fixes CID 1362442, 1362443
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Never can happen, since query would not have been created in the first
place if pidx(query_type) return negative. Lets let coverity realize
this.
CID 1362460
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Some hw queries need their sample memory locations to have certain
alignment. At the moment that isn't an issue, since the only hw query
is occlusion, so all samples have the same size. But when others are
added with different sample sizes, this starts to be a problem.
All current and immediately upcoming hw queries simply need their
sample address aligned to their size, so let's use that for now.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Add enable hook for hw query providers. Some will need to configure
perfctr selector registers, which we want to do at the start of the
submit.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
GL_AMD_performance_monitor must return an error when a monitoring
session cannot be started.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Fixes a few issues, including a potential empty-IB (which triggers gpu
hangs in piglit occlusion_query_meta_no_fragments)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Real GPU queries need some infrastructure to track samples per tile and
accumulate the results. But fortunately this can be shared across GPU
generation.
See:
https://github.com/freedreno/freedreno/wiki/Queries#hardware-queries
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Rob Clark
Marek Olšák
Rob Clark
Samuel Pitoiset