While both clang and gcc can handle designated initializers in C++,
MSVC only does with the C++20 support enabled. So move the initialization
of builtins to a C file.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
Remove constructors from glsl_type so it can be used as a
POD ("plain old data") struct, allowing the builtins to be
initialized directly in memory.
For other types, we now allocate them from glsl_type_cache's mem_ctx,
instead of using the global allocator.
As a side-effect of how the new helpers work, we can completely
create the mock key types for struct/interface lookup without
allocating any memory.
Note there's no `make_sampler_type` since all the sampler types
are created through direct initialization.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
Since now all the data referenced by it is allocated with the cache's
mem_ctx, it is sufficient to just free it, and then reset the cache
state to be ready for a next initialization if it happens.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
These are used only by types created at runtime. Since those will follow
the lifetime of the glsl_type_cache, we can use its mem_ctx for all the types.
Without a mem_ctx, there's nothing to be done in the destructor, so remove it.
Note some keys are calculated by building a mock type, so we need to create
a tmp_ctx in some cases. We'll get rid of them in a later commit.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
For now we use a temporary glsl_type_params struct, we will be able to
use the glsl_type directly once we make it a POD ("plain old data")
struct by getting rid of its constructors and destructors.
Note that since the name is statically allocated, there's no need to
strdup() it, deallocate it and also no need to have a mem_ctx.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
Unlike for simpler types, struct types have a runtime cache, that's used to
ensure same type can be compared to same pointer. The existing code was bypassing
it, potentially breaking that invariant. One potential issue would be when
decoding/encoding types, the resulting type would be pointer-different than what
was stored.
This hasn't caused a visible issue, but the (incomplete) special handling for struct
builtins is in the way of other changes.
Change the code to use get_struct_instance(), and also only ever load those if the
parser need the types, since some of them are deprecated types that we might never
want to load.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25006>
We don't need to carry this value around, its only used a single time in
the linker. Instead simply extract it from gl_shader when we need it.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25105>
llvm16 + opaque pointers uses a ptr to event for the opaque type,
llvm 17 fixes this properly, but the fix doesn't look too backportable.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25165>
GLSL doesn't use that type. SPIR-V used for a while but later started
relying on its own data structures and stopped using it.
See ca62e849d3 ("nir/spirv: Stop using glsl_type for function types")
If we were ever to add this one again, would be better to have a way to
grab a key for lookup that did not require allocations, right now that's
needed to inject return type as the first element in params array.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25160>
We can use the static version of the empty string. There's no worry
about freeing that string incorrectly since what is being deallocated
later is the whole mem_ctx.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25160>
Avoid code duplication because it need to be used in following commits
Fixes: 1a8dd84ec6 ("nir: Propagate the type sampler type change to the used variable.")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25145>
This adds a driver control to instruct NIR to not inline
all functions.
It adds a very simple inlining heuristic that works for
what I've played with, but will probably need to grow some
better ideas.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
Don't inline linked functions here, let nir_inline_functions do the job
when we get to it.
Instead just copy over the implementation and any other pieces need.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
the array dimensionality needs to match nir_add_inlinable_uniforms even if
only the first member is used
Fixes: 0c0fb216dd ("nir/inline_uniforms: Allow possibility of more than one UBO")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25063>
Originally written by Ian Romanick for the Intel backend, but ported
to the new nir_opt_barrier_modes() common optimization pass. Ian's
original explanation and commit message follows:
Shared memory only exists within a workgroup, so synchronizing it beyond
workgroup scope is nonsense.
Basically every SPIR-V compiler generates operations like
OpMemoryBarrier(/*Memory*/Device,
/*Semantics*/AcquireRelease | WorkgroupMemory)
This is suggested in numerous places, including
https://github.com/KhronosGroup/GLSL/blob/master/extensions/khr/GL_KHR_vulkan_glsl.txt.
Even Mesa's glsl_to_nir pass does this. This advice, which has been
copy-and-pasted everywhere, is contrary to issue 13 in the original
GL_ARB_compute_shader spec:
"Since shared memory is only accessible to threads within a single
work group, memoryBarrierShared() also only requires synchronization
with other threads in the same work group."
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24842>
Many shaders issue full memory barriers, which may need to synchronize
access to images, SSBOs, shared local memory, or global memory.
However, many of them only use a subset of those memory types - say,
only SSBOs.
Shaders may also have patterns such as:
1. shared local memory access
2. barrier with full variable modes
3. more shared local memory access
4. image access
In this case, the barrier is needed to ensure synchronization between
the various shared memory operations. Image reads and writes do also
exist, but they are all on one side of the barrier, so it is a no-op for
image access. We can drop the image mode from the barrier here too.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24842>
The first parameter should be on the first line, and any subsequent
lines should line up.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24842>
These patterns are broken in the following scenario:
%1 = f2fmp %0
%2 = fddx %1
%3 = ... // non quad uniform
if %3 {
%4 = f2f32 %2
...
}
Which would turn into
%3 = ...
if %3 {
%4 = fddx %0
...
}
Yet another example that shows why derivative instructions should be
be intrinsics, not alu.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25014>
The condition
!param->type->is_vector() || !param->type->is_scalar()
alawys evaluates to true:
* type is not scalar or vector -> true
* type is vector, i.e. num_components > 1 -> num_components == 1 is
false and !is_scalar() == true
* type is scalar, i.e. num_components == 1 -> num_components > 1 is
false and !is_vector() == true
There is no comment explaining why such code has been written, therefore
this seems to be a mistake.
To maintain consistency with the surrounding code,
glsl_type_is_scalar_or_vector has been used instead of
replacing || with &&.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24914>
