lavapipe can only do up to 4bits, so this isn't just a binary check
Fixes: 0daa61553d ("zink: check if multisample support exists for shader image formats")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9713>
It will take some more extensive work to plumb this through the backends
(although that should increase the benefit further), but this is already
worth a nearly 4x speedup in piglit drawoverhead tests with no state
change, so this seems like a useful intermediate step.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
In the normal case, we'll be pushing multi-draw (eventually) down into
the backend, but there are still a few remaining edge cases where we
can't deal with it.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
Not sure if we need this for a2xx. For a3xx and a4xx we need it for sw
xfb which needs to know the trimmed # of vertices in the VS. We do not
need it on a6xx, and unlikely need it for anything a5xx+.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
The draw resource-tracking logic looks like it never was updated to
account for HS/DS/GS stages. Add it bitmask of bound stages so we only
have to loop over the bound stages.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
aa1ddb6fe3 skipped the tracking for the
!dirty case, but we can do a bit better and track at bind time whether
the state change is one that requires resource tracking.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
Doesn't change anything yet, but this will let us more easily add
mapping from dirty gallium state to dirty gen-specific state-groups.
Note that the mapping from shader-state to global state in
fd_context_dirty_shader() optimizes out for release builds. This
is kind of important, in the next patch we'll want ffs(SOME_CONST)
to optimize away even more.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
Get this out of the way first to avoid some register push/pop. Only
reloc->bo is needed after writing the address into cmdstream, so this
turns msm_submit_append_bo() into a tail call.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
"OBJECT" rb's are long lived, and generating them is not a hotpath, but
relocs to "STREAMING" rb's are a hot path. But we can decouple these.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9581>
Context batches tend to have a lot of multi-LRI and, if we want to be
able to parse those registers nicely, we really handle it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9729>
I chose to drop "HW" from the name of this field because on Gen11
it applies to both HW and SW binding tables, so it's a bit of a
misnomer.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9729>
As the structs are used for TE and NTE change the naming of the
struct members to be more generic.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8103>
Fix defects reported by Coverity Scan.
member_not_init_in_gen_ctor: The compiler-generated constructor for this class does not initialize s.
member_not_init_in_gen_ctor: The compiler-generated constructor for this class does not initialize st.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8657>
This make sure we don't trigger assert in pipe_reference
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: John Bates <jbates@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9722>
historically zink has been bound to 4 gfx batches and then a separate compute batch
was added. this is not ideal for a number of reasons, the primary one being that if
an application performs 5 glFlush commands, the fifth one will force a gpu stall
this patch aims to do the following, all of which are necessarily done in the same patch
because they can't be added incrementally and still have the same function:
* rewrite batch tracking for resources/views/queries/descriptors/...
|originally this was done with a single uint32_t as a bitmask, but that becomes cumbersome
to track as batch counts increase, not to mention it becomes doubly-annoying
when factoring in separate compute batches with their own ids. zink_batch_usage gives
us separate tracking for gfx and compute batches along with a standardized api for
managing usage
* flatten batch objects to a gfx batch and a compute batch
|these are separate queues, so we can use an enum to choose between an array[2] of
all batch-related objects
* switch to monotonic batch ids with batch "states"
|with the flattened queues, we can just use monotonic uints to represent batch ids,
thus freeing us from constantly using bitfield operations here and also enabling
batch counts to scale dynamically by allocating/caching "states" that represent a batch
for a given queue
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9547>
this race condition between destroying ubo backing memory in lavapipe and
performing descriptor updates can be triggered from more than just queries,
so forcing the update just before the Problem Area seems like the best way to
permanently resolve the issue
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9711>
This adds a HAVE_COMPRESSION macro, which is undefined if neither zlib
nor zstd are present, and is used to no-op compress.h/c. This also has
a side effect of fixing SCons, since it won't define this macro.
Fixes: d7ecbd5bf8 ("util: create some standalone compression helpers")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9689>
This is the race condition: thread 1 check reference count of resource
and then find out out it's zero and then it begin to destroy it. Around
the same time, thread 2 gets the lock and get the resource from the hash
table and plan to use it. Then this resource gets destroyed while it's
still in use.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9701>
When we encounter a situation when we need to swizzle, which the CB can't
resolve in one pass, swap the channel order on the next clear, so that we
don't have to swizzle.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9615>
