Calling this directly in the linker code allows us to place it between
the varying linker and uniform linker calls which allows for better
optimisation/removal of uniforms.
Also in a later patch it allows us to insert a new nir based
lower_const_arrays_to_uniforms() call after the gl_nir_link_opts()
call. This is important because it allows the linking opts to
move constant arrays to later stages if possible before
lower_const_arrays_to_uniforms() turns them into uniforms.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6541
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770>
Some backends lower constant arrays to uniforms in GLSL IR. These
create so called hidden uniforms. Since we know these are added
per stage it is safe to remove them if we detect they are dead.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770>
The remap tables are used with the GL API so there is no need to
add hidden uniforms to them. Also when we switch to lowering some
constant arrays to uniforms in NIR in a following patch there
will no longer be enough room in the tables as we assign their
size in the GLSL IR linker not the NIR linker currently.
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770>
Doing this in NIR should give better results, but also allows us to
stop calling more GLSL IR optimisations passes.
v2: Skip 8bit and 16bit type that would require further processing
I believe this is an existing bug in the GLSL IR pass also.
v3: rebuild constant initialisers as we want to call this pass
after nir has already lowered them and performed optimisations.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770>
removing this broke the ability to create system compositors
rework it a bit though so that kms handles are stored and destroyed
when the bo is freed
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16815>
These keep flaking. Icecream95 observes the issue relates to AFBC in the
discussion of the flake in issue 6604. Until the root cause can be identified
and fixed, mark the tests as known flakes for CI.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16855>
this would usually occur through dri2_wl_swrast_commit_backbuffer(),
but zink triggers this functionality using vulkan wsi, which fails to
perform these updates as expected
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16814>
In mingw's `<unknwn.h>`, it's defeind __REQUIRED_RPCNDR_H_VERSION__ to 475,
so that gcc/mingw won't raise compiling error that because directx/d3d12.h
define __REQUIRED_RPCNDR_H_VERSION__ to 500, but the maximal supported __REQUIRED_RPCNDR_H_VERSION__ in mingw
are 475.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16767>
In mingw's `<unknwn.h>`, it's defeind __REQUIRED_RPCNDR_H_VERSION__ to 475,
so that gcc/mingw won't raise compiling error that because directx/d3d12.h
define __REQUIRED_RPCNDR_H_VERSION__ to 500, but the maximal supported __REQUIRED_RPCNDR_H_VERSION__ in mingw
are 475.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16767>
Adds a small helper for handling cp dma sync. This
Also adds the missing handling for some stage
flags in write_event.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16782>
...until an entry is added to VERSIONS in zink_device_info.py.
Now that we stop obtaining feature structs of promoted extensions when the VK
impl is new enough, it's possible for things to break when someone updates
vk.xml, and extensions get promoted but the codegen is not updated to include
e.g. info->feats13 and info->props13 (or newer) in zink_device_info
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16265>
(compilation structs refer to VkPhysicalDeviceVulkanXYFeatures/Properties, as
they consist of all features added by extensions promoted in VK X.Y)
The spec prohibits this, so instead we map the fields in the compilation
structs onto the fields in extension structs.
Some extensions' feature/properties structs are not promoted, and the spec
allows including both compilation structs and extension structs in such cases.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16265>
st_texture_release_all_sampler_views uses the validate_mutex,
but st_get_texture_sampler_view_from_stobj didn't.
Since they both modify stObj->view we could have threadA in
st_get_texture_sampler_view_from_stobj with a non-NULL sv,
so expecting sv->view to be non-NULL, while threadB was in
st_texture_release_all_sampler_views clearing sv->view.
It's also needed to protect st_sampler_view::private_refcount,
which is supposed to be used from the owning context thread,
but can also be used by any context in st_texture_release_all_sampler_views.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6088
Fixes: ef5d427413 ("st/mesa: add a mechanism to bypass atomics when binding sampler views")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16779>
We were using both uint32_t and anv_cmd_dirty_mask_t, this is
a cleanup making type usage consistent. Commit also changes type of
the mask to be enum anv_cmd_dirty_bits.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16849>
Right now, we just consider the size of the accessed portion of the
push constant array, but it doesn't necessarily reflect the size
of the UBO we should declare.
Fixes: de1e941c59 ("microsoft/spirv_to_dxil: Lower push constant loads to UBO loads")
Reviewed-by: Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16703>
We're not declaring an array of bytes but an array of uint32. Let's
fix the element_count we pass to glsl_array_type().
Fixes: de1e941c59 ("microsoft/spirv_to_dxil: Lower push constant loads to UBO loads")
Reviewed-by: Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16703>
Per spec RelaxedPrecision cannot be applied to bool types, however
3DMark Wild Life does it:
OpDecorate %171 RelaxedPrecision
...
%171 = OpLogicalAnd %bool %169 %170
Fixes crash in 3DMark Wild Life on Android.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16746>
Back when STATIC_ASSERT was prepared for use in common code, the
-Werror=vla flag was removed from the MSVC compat flags. But now we're
using C++11 / C11 static asserts instead, so we can add it back again.
This should help us noticing some breakages before they happen.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16670>
Since we now require C11 and C++14, we can use the standard
static_asserts from the standard library instead of rolling our own
compiler-specific versions.
To avoid needing scopes around usage in switch cases, keep the
while-wrapping from before. This means it still can't be used outside of
functions, but that should be fine; we should probably just use
static_assert directly in those cases anyway.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16670>
For some reason, Clang doesn't love the STATIC_ASSERT implementation
we're about switch to in this *one* particular case. Other cases seems
to work fine, so let's just use static_assert directly here.
It lets us give a better error string anyway, so yay.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16670>
This will allow the use of static_assert here instead of our
compiler-specific implementation.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16670>
This macro kinda complements util_is_power_of_two_*, but is implemented
as a macro. This means that it can expand to a constant integral
expression, and thus be used in static_assert.
Because we don't really need the added complexity, this doesn't handle
zero correctly. But that's OK, because the call-sites will.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16670>
Mike Blumenkrantz
Timothy Arceri
Georg Lehmann
Adam Jackson
Alyssa Rosenzweig
SureshGuttula
Yonggang Luo
Jesse Natalie
Konstantin Seurer
Hoe Hao Cheng
Pierre-Eric Pelloux-Prayer
Tapani Pälli
Boris Brezillon
Daniel Schürmann
Samuel Pitoiset
Danylo Piliaiev
Erik Faye-Lund