On Gfx9 we only use 2 L3 config depending on SLM use or not. So it's
the same config for all Gfx pipelines.
On Gfx11+ there is only one config (since SLM is allocated from
somewhere else).
So avoid store this on the pipeline, pick the config when flushing the
pipeline.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36512>
Since the pipeline concept is going to go away into the runtime, this
gives us finer control over runtime flushing.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36512>
The vulkan runtime code doesn't allow to use the pipeline layout and
instead just provides an array of set layouts.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36512>
If the mov node being handled here has modifiers, it cannot be
trivially removed. This happens in some shaders, so handle it
in the identity mov check for that optimization.
Fixes: d6987daef9 ("lima: ppir: introduce an optimizer")
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36490>
CTA synchronizes between all threads within the same workgroup, so we
should use that over GPU which has some more severe performance
implications.
Sadly it doesn't appear like we can rely on .CTA to work for global
memory so let's keep using GPU for those for now.
Speeds up vk_cooperative_matrix by roughly 40%
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36482>
The HW returns the wrong result for gl_SampleMaskIn when
post_depth_coverage is enabled together with FSR. This is especially
problematic since we use gl_SampleMaskIn to lower gl_HelperInvocation.
Disable the extension as a workaround.
We are currently unaware of any apps that use VK_EXT_post_depth_coverage
so disabling it should not be a problem.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35788>
This ralloc garbage collection shouldn't be needed since we trash
the IR after glsl_to_nir anyway.
Freeing the ralloc context is moved after glsl_to_nir.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36425>
NIR is going to use exec_node/list without the C++ code, and may switch to
a different linked list implementation in the future.
GLSL is going to use ir_exec_node/list, which we want to keep private
for GLSL, so that we can change it easily.
Thus, it's better to fork the C++ version of list.h for Intel.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36425>
This separates the GLSL IR exec_node from the NIR exec_node,
so that we can change the GLSL IR version.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36425>
anv_slab_bo_deinit() eventually calls down to anv_device_release_bo()
which locks a yet to be initilized device->bo_cache->mutex leading to:
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x79c25ee54bd8)'
Reorder anv_slab_bo_init() to occur after anv_bo_cache_init() and
anv_slab_bo_deinit() before anv_bo_cache_finish()
Fixes: 3bf6d42fda ("anv: Add the base infrastructure to support memory pool")
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36479>
After commit 2dcd6bed6a ("util: enforce unreachable()'s argument being
a literal string", 2023-04-17) the compiler effectively emit errors when
an argument that is not a string literal is passed to UNREACHABLE(str),
however the compiler still allows the macro to be called without
arguments, which can be confusing.
Implement the type check outside of the assert() call so that we have
two types of errors:
1. The compiler will error out when the argument passed to the macro is
not a string literal because the concatenation with an empty string
will not be allowed.
2. The compiler will error out when no arguments are passed to the macro
because the invocation of assert() will be invalid.
This also has the nice side-effect of removing the extra empty string
printed in the assert() messages; after the changes the messages will
look like:
Assertion `!"Invalid type"' failed.
instead of:
Assertion `!"" "Invalid type"' failed.
Fixes: 2dcd6bed6a ("util: enforce unreachable()'s argument being a literal string", 2023-04-17)
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
In the C23 standard unreachable() is now a predefined function-like
macro in <stddef.h>
See https://android.googlesource.com/platform/bionic/+/HEAD/docs/c23.md#is-now-a-predefined-function_like-macro-in
And this causes build errors when building for C23:
-----------------------------------------------------------------------
In file included from ../src/util/log.h:30,
from ../src/util/log.c:30:
../src/util/macros.h:123:9: warning: "unreachable" redefined
123 | #define unreachable(str) \
| ^~~~~~~~~~~
In file included from ../src/util/macros.h:31:
/usr/lib/gcc/x86_64-linux-gnu/14/include/stddef.h:456:9: note: this is the location of the previous definition
456 | #define unreachable() (__builtin_unreachable ())
| ^~~~~~~~~~~
-----------------------------------------------------------------------
So don't redefine it with the same name, but use the name UNREACHABLE()
to also signify it's a macro.
Using a different name also makes sense because the behavior of the
macro was extending the one of __builtin_unreachable() anyway, and it
also had a different signature, accepting one argument, compared to the
standard unreachable() with no arguments.
This change improves the chances of building mesa with the C23 standard,
which for instance is the default in recent AOSP versions.
All the instances of the macro, including the definition, were updated
with the following command line:
git grep -l '[^_]unreachable(' -- "src/**" | sort | uniq | \
while read file; \
do \
sed -e 's/\([^_]\)unreachable(/\1UNREACHABLE(/g' -i "$file"; \
done && \
sed -e 's/#undef unreachable/#undef UNREACHABLE/g' -i src/intel/isl/isl_aux_info.c
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
The unreachable(str) macro defined in src/util/macros.h is defined to
accept a literal string as an argument.
However the way it checks that the argument is a string literal, by
prepending an empty string where the argument is used, i.e.:
#define unreachabel(str) assert(!"" str)
still allows users to call the macro with no arguments.
This is confusing, so pass an empty string to all invocations of
unreachable() for consistency.
This is done with the following command:
git grep -l '[^_]unreachable();' -- "src/**" | sort | uniq | \
while read file; \
do \
sed -e 's/\([^_]\)unreachable();/\1unreachable("");/g' -i "$file";
done
This should not change the behaviour of the callers of unreachable() in
a meaningful way, but there will be some cosmetic consequence.
The changed invocations will now print:
Assertion `!"" ""' failed.
instead of
Assertion `!""' failed.
But this is also what happens for the invocations that do pass an
argument, for instance `unreachable("Invalid type")` currently prints:
Assertion `!"" "Invalid type"' failed.
So all invocations now also have the same output style.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
A subsequent change is going to add a macro named UNREACHABLE() to
src/util/macros.h which will conflict with the lexer state name
UNREACHABLE in src/compiler/glsl/glcpp/glcpp-lex.l
Use the name NOT_REACHABLE in glcpp-lex.l instead of UNREACHABLE, just
to avoid the name clash with the future macro.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
Fixes the following CTS tests:
- dEQP-GLES3.functional.fbo.msaa.2_samples.rg8
- dEQP-GLES3.functional.fbo.msaa.4_samples.rg8
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36494>
Fixes the following CTS tests:
- dEQP-GLES3.functional.fbo.msaa.2_samples.r8
- dEQP-GLES3.functional.fbo.msaa.4_samples.r8
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36494>
To support "surfaceless" builds on Android it is required to still have
HMI symbol exported by the library while no other android-specific code is
needed.
Reviewed-by: Gurchetan Singh <gurchetansingh@google.com>
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36459>
Context buffer initialization in the nxp-imx kernel driver
(lf-6.6.3-1.0.0) indicates that this state is only defined
when the GPU supports MSAA_FRAGMENT_OPERATION.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36358>
