Explicit token pasting is handled specially, but the token
printing code can accidentally paste identifiers. Check for
this accidental pasting and prevent it by inserting a space
if necessary.
Supersedes a similar but much more limited test to prevent pasting
`+` and `-` to make `++` and `--`.
A test is provided in glcpp/tests/150-token-accidental-concatenation.
The accidental pasting test in 068-accidental-pasting is also updated
to cover some of the other cases.
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37214>
This will allow ubo buffers to have arrays containing millions of
elements without excessive memory use on a remap table. Before this
change using the max sized array on radeonsi would result in 1.3GB
of memory being used for a remap table in a single shader.
There is also a small functional change here, previously if the
shader used more than GL_MAX_UNIFORM_BLOCK_SIZE mesa would ignore
and allow this as the original ARB_uniform_buffer_object spec
stated:
"If the amount of storage required for a uniform block exceeds
this limit, a program may fail to link."
However in OpenGL 4.3 the text was clarified and the "may" was
removed so with this change we enforce the max limit.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9953
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36997>
Missing 32-bit entry point in GLSL
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 2ce20170 ("mesa: Add support for GL_EXT_shader_clock")
Signed-off-by: Ashley Smith <ashley.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36041>
With UBSan enabled, we get the following issue:
```
../src/compiler/glsl/ir.h:116:4: runtime error: member access within address 0x555637c62c10 which does not point to an object of type 'ir_instruction'
0x555637c62c10: note: object has invalid vptr
5f 76 61 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
```
This only happens the first time a ir_variable (which derives from
ir_instruction) is created; next calls don't show the issue any more.
The problem is with the following call in the `new()` operator:
```
((ir_instruction*)((uintptr_t)p))->node_linalloc = ctx;
```
In this case, the ir_instruction structure is not fully constructed and
thus UBSan complains about it. In the next calls, as the structure is
now fully constructed it doesn't complain any more.
The right approach would be fully creating the structure, and afterwards
doing the context assignment. But this would require quite a lot of
changes, passing the context through the constructors to assign it.
A simpler solution is just disabling this check for this case, as we
know what is happening.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
It still allocates the ralloc header, which is wasteful.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
Prepare for mesh shader support, change all shared code to
use MESA_SHADER_MESH_STAGES.
Use command:
find src/gallium/auxiliary/ -type f -not -path '*/.git/*' -exec sed -i 's/\bMESA_SHADER_STAGES\b/MESA_SHADER_MESH_STAGES/g' {} +
find src/compiler -type f -not -path '*/.git/*' -exec sed -i 's/\bMESA_SHADER_STAGES\b/MESA_SHADER_MESH_STAGES/g' {} +
find src/mesa -type f -not -path '*/.git/*' -exec sed -i 's/\bMESA_SHADER_STAGES\b/MESA_SHADER_MESH_STAGES/g' {} +
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36596>
As float16_t may comes from arm_neon.h:
arm_neon.h:74:16: error: conflicting declaration 'typedef __fp16 float16_t'
74 | typedef __fp16 float16_t;
Also it is std::float16_t from <stdfloat> as part of C++23
So place it under namespace mesa to avoid conflict when upgrading xxhash.h to v0.8.3
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36654>
It's not only for GL, change to a generic name.
Use command:
find . -type f -not -path '*/.git/*' -exec sed -i 's/\bgl_shader_stage\b/mesa_shader_stage/g' {} +
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36569>
There is no such struct.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36569>
Setting variable names currently always uses ralloc, but the new
nir_variable_* helpers will mostly eliminate ralloc/malloc in a later
commit.
This just updates all places that touch nir_variable names to use the new
helpers.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36538>
Backends probably already deal with this, but these would be needed to
prevent NIR passes from moving accesses outside the critical section.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36513>
Compiling my shader-db with the gallium noop driver is 6.8% faster now.
Theoretical stat-based results are below, which don't always reflect real
results.
When compiling Heaven shaders with the gallium noop driver,
134610 calloc calls are removed.
134610 / ralloc count = 6%, so it's roughly the equivalent of 6% of
the cost of all ralloc calls that's removed. The shift from calloc to
linear_alloc increases ralloc calls by 0.4%, so the approximate reduction
is 6% -> 0.4% overhead change.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
Compiling my shader-db with the gallium noop driver is 3.6% faster now.
malloc calls from ralloc+linear_alloc are reduced by 34% when compiling
Heaven shaders with the gallium noop driver. That's due to a shift of
malloc calls from ralloc to linear_alloc.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
The type of the "new operator" parameter determines whether ir_instruction
is allocated with linear_ctx or ralloc. The ralloc operators will be
removed in the next commit.
GCC expects classes with virtual functions to have a virtual destructor,
but linear_ctx has static assertions that expects that no destructor is
present. Remove the assertions, as that's our only option. The destructor
is empty including in all derived classes, so it doesn't have to execute.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
