this is the earliest place the batch_id is available now, so check it
here since ctx->curr_batch isn't actually a thing anymore
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13247>
when dispatch is fast enough, some tests fire off cmdbufs so quickly that the normal
oom flushing and batch pruning in end_batch isn't sufficient to keep memory
usage down
to combat this, start throwing in stalls after submission to clean out a bunch of cmdbufs
while preventing further ones from being submitted
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13247>
Translate PIPE_BIND_SCANOUT as ISL_SURF_USAGE_DISPLAY_BIT,
instead of PIPE_BIND_DISPLAY_TARGET.
PIPE_BIND_DISPLAY_TARGET isn't used for dri images and seem to
be set only for fake winsys buffers (which aren't displayed).
The trouble is that a fake buffer could be multisampled and we
cannot have multisampled surface with display bit.
Ported from iris 82b4666783
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Tested-by: Jason Ekstrand <jason@jlekstrand.net>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5464
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13260>
Make u_vector_init a wrapper to u_vector_init_pot. Let both take
(element_count, element_size) as parameters.
Motivated by eed0fc4caf ("vulkan/wsi/wayland: fix an invalid
u_vector_init call")
v2: rename u_vector_init_pot to u_vector_init_pow2
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13201>
This reverts the following commit from main:
commit f6abb3445b
Author: Marek Olšák <maraeo@gmail.com>
Date: Fri Oct 1 15:46:48 2021 -0400
mesa: use simple_mtx_t for TexMutex
change mtx_recursive -> mtx_plain, there's no recursive locking
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13152>
Contrary to the claim in the commit message, there is recursive locking.
The meta stuff used by i965 does GL operations while the texture is
locked. If we don't allow recursive locks, it will deadlock. No, it's
not great, but it's the current state of affairs. Once we delete i965
in favor of crocus and any other users of meta, we can restore the above
patch. Until then, we need mtx_recursive.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13254>
With a tiny bit more code-gen, we can now not only throw the error but
also log back to the client exactly which feature was missing.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
We have to be a bit careful here. Calling log functions during instance
initialization can be a bit sketchy. However, we know that __vk_log_impl
only ever touches the callbacks lists if instance->base.client_visible
so it's safe to call vk_error as soon as we've set up instance_callbacks.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Now that we no longer have every driver in the tree defining their own
__vk_errorf and __vk_errorv, we don't need to worry about the symbol
collision anymore and can use the "real" names for the common ones.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Also switch all our calls to use the closest object to the error and let
vk_error sort out which object to actually use.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
The VK_ERROR_FRAGMENTED_POOL and VK_ERROR_OUT_OF_POOL_MEMORY errors are
not as exceptional cases as most. These are expected to be hit by
applications in the normal course of doing their thing. Probably best
not to spam stderr and the debug logs with them.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
These helpers have quite a bit of smarts in them to log errors to chase
the object chain as needed and log errors to roughly the appropriate
object. For instance, VK_ERROR_OUT_OF_DEVICE_MEMORY always goes to a
device while VK_ERROR_OUT_OF_HOST_MEMORY always goes to the instance.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Instance-level objects won't have a device pointer so we can't rely on
that. Instead, we should look at the object type and try to chase it
back to an instance. Sadly, we can't do that for certain display and
WSI objects. However, we never use the vk_log* helpers for those.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
The VK_ERROR_FRAGMENTED_POOL and VK_ERROR_OUT_OF_POOL_MEMORY errors are
not as exceptional cases as most. These are expected to be hit by
applications in the normal course of doing their thing. Probably best
not to spam stderr and the debug logs with them.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
If the instance isn't client-visible yet (i.e. foo_instance_to_handle
hasn't been called), then the instance is still under construction and
we should log using vk_debug_message_instance. This makes the vk_log*
macros work regardless of whether the instance is fully constructed or
not.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
When dealing with debug logging, it's useful to track when an object's
construction is finished and it's now visible to the client. We can
detect this pretty easily by setting a flag the first time foo_to_handle
is called. As long as drivers only ever call that function at the end
of object construction (they all do to my knowledge), this should be a
reliable mechanism for detecting when a client knows about a handle.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
It's no longer used and just makes the init/finish path more
complicated.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Now that all drivers have been patched to convert sysvals to input
varyings when they have too, we can safely declare PointCoord as a sysval
too.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
Now that all spirv_to_nir() users take care of converting sysvals to
varyings, we can unconditionally declare FragCoord as a sysval.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
This is an attempt at simplifying the spirv_to_nir() backend when it
comes to choosing between system values and input varyings. Let's patch
drivers to do the sysval to input varying conversion on their own so we
can get rid of the frag_coord_is_varying field in spirv_to_nir_options
and unconditionally create create sysvals for FragCoord, FrontFacing and
PointCoord inputs instead of adding new xxx_is_{sysval,varying} flags.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
Allow backends to turn some sysvals into input varyings so the frontend
(in our case spirv_to_nir()) doesn't have to bother selecting which
one is expected.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
Gallium caches sampler states for TBOs. Now if a buffer is first
attached to a TBO specifying one format, and later attached by
specifying another format and this TBO is then used, that would lead
to an assertion failure in debug builds, or to invalid rendering in
release builds, because the TBO picks the original, wrong format for
the sampler view.
Resolve this by signalling the change to Gallium (and other drivers), so
that Gallium clears the sampler view cache.
Fixes: f0ecd36ef8
st/mesa: add an entirely separate codepath for setting up buffer views
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13230>
Rather than having an ever increasing list of parameters to
threaded_context_create(), split out a struct for optional
flags and parameters. This should reduce churn in adding
new options.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13207>
We perform a FMASK expand when transitioning to GENERAL or TRANSFER_DST
layout, so storage images always have an identity FMASK.
radeonsi doesn't appear to expand the FMASK for read-only storage images,
so the sample index adjustment is still needed there.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12214>
I think it somehow worked fine previously, but this is more correct.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12214>
Mike Blumenkrantz
Marek Olšák
Dave Airlie
Jordan Justen
Chia-I Wu
Jason Ekstrand
Boris Brezillon
Jason Ekstrand
Gert Wollny
Rob Clark
Rhys Perry