We use the same key in autotune to track historical data about a given
framebuffer state, to inform the decision about using gmem vs sysmem
rendering. Which means we need the key to stick around during the
flush, even if the batch is removed from the batch-cache before the
flush.
Fixes: 507f701d9e ("freedreno: Fix batch flush race condition")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11450>
The invalidate would take it out of the bc tracking, so you could go
allocate a new batch->idx matching this one, while this one is still in
the bc using that idx.
You can't generate any new rendering with the ctx's old batches at this
point, anyway, so just flush for simplicity.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11439>
As we move the batch cache from screen to context, it cleans up the diff a
ton to separate this mechanical change out, and makes the API generally
more consistent (since you usually have to pass the ctx anyway).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11368>
We need to remove the batch cache entry before marking as flushed.
Note that we are already holding the batch lock, to prevent flushing
something that another context is emitting cmdstream to, but there is
a window between batch cache lookup (under screen lock) and acquiring
the batch lock that could previously result in batch cache lookup
returning a flushed batch.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11200>
Somehow fairly recently the traces CI job started hitting timeouts, not
all the time but enough to be inconvenient for CI. I tracked it down to
getting into a situation where `ctx->batch->flush == true`, which causes
an infinite loop in the draw_vbo and clear paths (because
fd_batch_lock_submit() checks for flushed batch but fd_context_batch()
does not). I'm not entirely sure how we get into that state, or what
triggered this (seems possibly triggered by !10937). But it is easy
enough to recover.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11196>
For autotune, the lifetime of it's hashtable keys doesn't match the
batch, so we'll need to clone the key before inserting into the
hashtable.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9535>
For threaded_context, to properly handle replace_buffer_storage, we'll
need to handle multiple "iterations" of a resource using the same
tracking in order to implement transfer_map() correctly.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9323>
Use clangs thread-safety annotations to implement a virtual lock
protecting context fields that should only be accessed from driver-
thread. This should let the compiler help us detect problems where
ctx is used unsafely from things that could be called by the fe/st
thread.
This does end up sprinkled far and wide, it would be nice if the
compiler could be a bit smarter about understanding call-graphs
(at least with static fxns), but at least it makes it clear where
things are called from which thread.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9061>
This protects better against another context triggering a batch flush
and unref while the first context is doing resource tracking.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7342>
It is smaller than a pointer, and doesn't run into problems of context
destroy/create cycle ending up with the same address.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7342>
These were actually just wrappers for the screen->lock, left over from
moving things around a long time ago. Lets drop them to make things
more explicit (that we are locking the screen, not the context).
Involves a bit of shuffling things around to untangle header deps, but
no functional change.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7342>
Two potential problems, batch re-ordering doesn't really play nicely
with fence_server_sync(), so when we switch away from one batch, detect
the case that we need to sync, and if so flush. The alternative of
trying to track that later batches depend on an earlier batch that had
an in-fence is hairy, and the normal use-case would be to sync at the
beginning of the frame.
But this brings up the second problem, which is that typically we'll get
told to sync on an in-fence before the first draw, which means before
mesa/st flushes down the framebuffer state to the driver. Which means
we don't yet have the correct batch to attach the fence to. So we need
to track the in-fence on the context, and transfer it to the batch
before draws, etc.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6575>
Something I cooked up in the process of debugging the issue fixed in the
next commit. Might come in useful again in the future.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5188>
xxhash is faster than fnv1a in almost all circumstances, so we're
switching to it globally.
Signed-off-by: Dmytro Nester <dmytro.nester@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4020>
Previously we tried to normalize nr_samples to MAX2(1, nr_samples) to
avoid having to deal with 0 vs 1 everywhere. But this causes problems
in mesa/st, for example st_finalize_texture() will think there is a
nr_samples mismatch and recreate the texture. Somehow this manifests
as corrupt x11 font rendering on generations that do not support MSAA
(but apparently works fine on a5xx and a6xx which do support MSAA.)
Fixes: cf0c7258ee freedreno/a5xx: MSAA
Signed-off-by: Rob Clark <robdclark@gmail.com>
There is not much to do in freedreno - tile layout and multisample
state for gmem renderings is programmed based on the pfb sample count,
while resolve blits take the destination sample count from the resource.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Needs to specify nondraw when creating a batch through
fd_bc_alloc_batch since it'd better create a batch through
it rather than fd_batch_create.
Signed-off-by: Rob Clark <robdclark@gmail.com>
pipe_framebuffer_state can have samples=0 in various cases, which is
actually the same thing as samples=1. So use the _get_num_samples()
helper to populate the key, to avoid this looking like two distinct
fb states to the cache.
Signed-off-by: Rob Clark <robdclark@gmail.com>
It is possible for a batch to be freed under our feet when flushing, so
it is best to hold a reference to all of them up-front.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The cache doesn't hold a (strong) reference to the batch. So we
shouldn't be trying to drop a reference, as that leads to:
#0 0x0000ffffbecb37a0 in raise () from /lib64/libc.so.6
#1 0x0000ffffbeca159c in abort () from /lib64/libc.so.6
#2 0x0000ffffbecacf48 in __assert_fail_base () from /lib64/libc.so.6
#3 0x0000ffffbecacfa8 in __assert_fail () from /lib64/libc.so.6
#4 0x0000ffffbd28def0 in pipe_reference_described (ptr=0x4f47130, reference=0x0, get_desc=0xffffbd2e0f08 <__fd_batch_describe>) at ../src/gallium/auxiliary/util/u_inlines.h:88
#5 0x0000ffffbd28e188 in fd_batch_reference_locked (ptr=0x4f40de0, batch=0x0) at ../src/gallium/drivers/freedreno/freedreno_batch.h:258
#6 0x0000ffffbd28e9a8 in fd_bc_invalidate_resource (rsc=0x4f40ca0, destroy=true) at ../src/gallium/drivers/freedreno/freedreno_batch_cache.c:244
#7 0x0000ffffbd293778 in fd_resource_destroy (pscreen=0xedc170, prsc=0x4f40ca0) at ../src/gallium/drivers/freedreno/freedreno_resource.c:644
#8 0x0000ffffbd922674 in u_transfer_helper_resource_destroy (pscreen=0xedc170, prsc=0x4f40ca0) at ../src/gallium/auxiliary/util/u_transfer_helper.c:144
#9 0x0000ffffbd29527c in pipe_resource_reference (ptr=0x4f455d8, tex=0x0) at ../src/gallium/auxiliary/util/u_inlines.h:144
#10 0x0000ffffbd29548c in fd_surface_destroy (pctx=0x1012720, psurf=0x4f455d0) at ../src/gallium/drivers/freedreno/freedreno_surface.c:78
#11 0x0000ffffbd1f9c48 in pipe_surface_reference (ptr=0x4f471d0, surf=0x0) at ../src/gallium/auxiliary/util/u_inlines.h:113
#12 0x0000ffffbd1f9ef4 in util_copy_framebuffer_state (dst=0x4f471c8, src=0x0) at ../src/gallium/auxiliary/util/u_framebuffer.c:114
#13 0x0000ffffbd2e0e30 in __fd_batch_destroy (batch=0x4f47130) at ../src/gallium/drivers/freedreno/freedreno_batch.c:225
#14 0x0000ffffbd28e1b0 in fd_batch_reference_locked (ptr=0xfffffffff010, batch=0x0) at ../src/gallium/drivers/freedreno/freedreno_batch.h:262
#15 0x0000ffffbd28e6b0 in fd_bc_invalidate_context (ctx=0x1012720) at ../src/gallium/drivers/freedreno/freedreno_batch_cache.c:190
#16 0x0000ffffbd2e2b6c in fd_context_destroy (pctx=0x1012720) at ../src/gallium/drivers/freedreno/freedreno_context.c:139
#17 0x0000ffffbd2c3280 in fd5_context_destroy (pctx=0x1012720) at ../src/gallium/drivers/freedreno/a5xx/fd5_context.c:56
#18 0x0000ffffbd5b7a8c in st_destroy_context_priv (st=0xfd72f0, destroy_pipe=true) at ../src/mesa/state_tracker/st_context.c:281
Signed-off-by: Rob Clark <robdclark@gmail.com>
Get rid of "gmem" (ie. tiling) ringbuffer, and just emit setup commands
directly to "draw" ringbuffer for compute (and in future for blits not
using the 3d pipe). This way we can have a simple flat cmdstream buffer
and bypass setup related to 3d pipe.
Signed-off-by: Rob Clark <robdclark@gmail.com>
ctx->last_fence isn't such a terribly clever idea, if batches can be
flushed out of order. Instead, each batch now holds a fence, which is
created before the batch is flushed (useful for next patch), that later
gets populated after the batch is actually flushed.
Signed-off-by: Rob Clark <robdclark@gmail.com>
pipe_mutex_unlock() was made unnecessary with fd33a6bcd7.
Replaced using:
find ./src -type f -exec sed -i -- \
's:pipe_mutex_unlock(\([^)]*\)):mtx_unlock(\&\1):g' {} \;
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
replace pipe_mutex_lock() was made unnecessary with fd33a6bcd7.
Replaced using:
find ./src -type f -exec sed -i -- \
's:pipe_mutex_lock(\([^)]*\)):mtx_lock(\&\1):g' {} \;
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Prep-work for next patch, mostly move to tracking last_fence as a
pipe_fence_handle (created now only in fd_gmem_render_tiles()), and a
bit of superficial renaming.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Marek Olšák
Rob Clark
Emma Anholt
Eric Anholt
Dmitriy Nester
Rob Clark
Kristian H. Kristensen
Eric Engestrom
Hyunjun Ko
Timothy Arceri