Rewrite the code to use linear_asprintf and always flip the
dimensions in place if the element type is an array. The new
code will now (correctly) flip even in the case of unsized arrays.
The flipping is done by swapping the ranges [a, b) and [b, c), as
shown below, with element type int[...] and an array of length 4.
```
+--------------- a: first bracket in the name
| +---------- b: end of the element name
| | +------- c: end of the array name
| | |
int[...][4]$
will be transformed into
int[4][...]$
```
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23278>
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>
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>
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>
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>
Caio Oliveira