Per OpenGL Shading Language, section 8.11. "Atomic Memory Functions"
first argument "mem" of all atomicOP functions is inout.
The same is true for ARB_shader_storage_buffer_object and
GL_INTEL_shader_atomic_float_minmax
For implicit conversion of inout parameters it is required for type
to support bi-directional conversion, since there is no such types
in glsl - implicit conversion is effectively prohibited.
Alternatively we could have marked atomic_var parameter of built-in
atomicOP functions as inout, however it opens another can of worms
during NIR lowerings.
Fixes: ea0a1f5beb
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2837
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4887>
If a shader has no defined version force_glsl_version was
previous ignored and the shader would default to 110. This updates
the code so that those shaders are forced to a new level also.
We reused the existing code to make sure a sensible value is set
for the version.
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11602>
builtin_builder::~builtin_builder() and builtin_builder::release()
are running into race condition. This leads lightsmark to crash at
the end because both calls ralloc_free which mutates the arguments state
This patch fixes lightsmark2008 crash
Fixes: e4da8b9c33 ("mesa/compiler: rework tear down of builtin/types")
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11385>
Be consistent with other usages in Vulkan and SPIR-V, and the recently
added workgroup_size field.
Acked-by: Emma Anholt <emma@anholt.net>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11190>
The CAP for packed transform feedback concerns packing of unrelated
variables into the same varying slot. (On Mali, transform feedback is
implemented on a per-slot basis, so different variables need different
slots to be written to different buffers.) However, this requirement is
tangential to the packing of arrays, matrices, and structures inherent
to GLSL. These array-like values need to be packed /within/ their slot,
even though drivers using the CAP (just Panfrost) cannot pack
independent values in the slot. Transform feedback of individual
elements is not independent, after all.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10778>
We need to duplicate the subscripted members even if they happen to be
aligned, since the other elements may be passed into the consumer
shader. Fixes on Panfrost:
dEQP-GLES3.functional.transform_feedback.array_element.interleaved.lines.highp_float
Note: the test did pass on main previously due to an elaborate set of
driver hacks. I don't believe the old behaviour was correct regardless.
Only Panfrost is affected by this change and the next, as every other
driver sets PIPE_CAP_PACKED_STREAM_OUTPUT.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10778>
From the ARB_enhanced_layouts spec:
"As with input layout qualifiers, all shaders except compute shaders
allow *location* layout qualifiers on output variable declarations,
output block declarations, and output block member declarations. Of
these, variables and block members (but not blocks) additionally
allow the *component* layout qualifier."
We previously had compile tests in piglit to make sure this was not a
compile error but no execution tests.
Fixes: d99a040bbf ("i965: enable ARB_enhanced_layouts for gen8+")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10763>
This fixes linking failures with new GL45 linkage tests, no
regressions spotted on existing tests.
v2: add spec reference (Samuel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10373>
This fixes the
dEQP-GLES3.functional.shaders.invariance.{low,medium,high}p.loop_4 tests when
run in a VM with virgl on a host with iris. virgl mangles the GLSL shaders and
emits shader code for the host driver that contains vec4 arrays. As such, the
test did not fail when running directly on the host.
The test also did not fail if the host was using i965. Disabling
PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY in iris was sufficient to work around it,
so I believe that i965 didn't show the problem because after arrays were split
by optimize_split_arrays(), even though the invariant/precise qualifiers were
lost, do_common_optimization() would be called again and thus
propagate_invariance() would propagate the qualifiers to the new variables
produced by optimize_split_arrays().
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10292>
Doing so allow you to easily tell what the pass did using the existing
infrastructure in the OPT macro.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10292>
One exception is src/amd/addrlib/, for which -Wimplicit-fallthrough is
explicitly disabled.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
Undefine __STDC_VERSION__ for C files to avoid mismatch with C11/C17.
Define __STDC_VERSION__ for C++ files to use <inttypes.h> path.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10196>
When formatting the error here, we're currently casting an
ast_type_qualifier as a string.
But we don't need to use a string here at all, because we know from
context exactly what qualifier we're talking about, because the
if-statements explicitly check for the uniform-qualifier.
So let's just hard-code the format-string to reference the right
qualifier instead of the string-shenanigans. The latter cannot do the
right thing.
Fixes: 2d03f48a65 ("glsl: Add parsing for GLSL uniform blocks.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9911>
This arugment is not present int the format-string, so we shouldn't pass
it to _mesa_glsl_error either.
Noticed by Coverity.
Fixes: 02dc74fbd7 ("glsl: parse invocations layout qualifier for ARB_gpu_shader5")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9911>
Sources outside of src/util path should include "util/string_buffer.h"
Fixes the following building error in Android:
external/mesa/src/compiler/glsl/ast_type.cpp:25:10: fatal error: 'string_buffer.h' file not found
^~~~~~~~~~~~~~~~~
1 error generated.
Fixes: eeec9d56ad ("compiler/glsl: clean up output")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10156>
When lowering precision on integers from GLSL ES, we can end up with
16 bit integer loop counters. So let's tolerate this as well.
This was probably not caught earlier because most NIR drivers disable
GLSL-level loop-unrolling, and no non-NIR driver sets LowerPrecisionInt16
to true. This was discovered while trying to wire up int16 support for
Zink, which doesn't currently disable GLSL loop-unrolling.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10125>
It's really hard to make sure we have the right amount of %s in the
format string, so let's change how we generate this string.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9896>
The reason the member has a leading underscore is because volatile is a
keyword in C. We don't want to carry that detail into the error-string,
so let's drop the underscore.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9896>
This format-string seems to have been incorrect since it's inception.
But there's also been commits that have both forgotten to add and remove
flags as appropriate as well.
Let's correct the format-list. This was done by counting by hand. A
better solution for the long-term is coming in a future commit.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9896>
Per OpenGL 4.6 spec:
"If no xfb_stride qualifier is specified for a
binding point, the stride is derived by identifying the variable associated with the
binding point having the largest offset, and then adding the offset and the size of
the variable, in basic machine units. If any variable associated with the binding
point contains double-precision floating-point components, the derived stride is
aligned to the next multiple of eight basic machine units. If a binding point has no
xfb_stride qualifier and no associated output variables, its stride is zero."
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2333>
1) Per GL_ARB_enhanced_layouts if explicit location is set for varying,
each struct member, array element and matrix row will take
separate location. With GL_ARB_gpu_shader_fp64/GL_ARB_gpu_shader_int64
they may take two locations.
Examples:
| layout(location=0) dvec3[2] a; | layout(location=4) vec2[4] b; |
| | |
| 32b 32b 32b 32b | 32b 32b 32b 32b |
| 0 X X Y Y | 4 X Y 0 0 |
| 1 Z Z 0 0 | 5 X Y 0 0 |
| 2 X X Y Y | 6 X Y 0 0 |
| 3 Z Z 0 0 | 7 X Y 0 0 |
Previously it wasn't taken into account.
2) Captured double-precision variables should be aligned to
8 bytes per GL_ARB_gpu_shader_fp64:
"If any variable captured in transform feedback has double-precision
components, the practical requirements for defined behavior are:
...
(c) each double-precision variable captured must be aligned to a
multiple of eight bytes relative to the beginning of a vertex."
v2: fix `output_size` calculations
( Andrii Simiklit <andrii.simiklit@globallogic.com> )
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1667
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2333>
When packing varyings when there is only 32bit of space
left in slot 64bit type is attempted to be divided between
current and next slot. However there is neither code for
splitting the 64bit type nor for assembling it back.
Instead we add 32bit padding.
The above happens only in structs because their
members aren't sorted by packing order.
Example of the issue:
struct S {
vec3 a;
double d;
};
out flat S s;
Before, the packing went as:
slot 32b 32b 32b 32b
0 a.x a.y a.z d
1 d 0 0 0
After:
slot 32b 32b 32b 32b
0 a.x a.y a.z 0
1 d d 0 0
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2333>
Section 8.9.4 (Compatibility Profile Texture Functions) of the
GLSL 4.20 spec outlines a number of builtin texture functions that
have been moved to compatibility shaders.
This change enforces those restrictions. Note we don't worry about
enforcing restrictions on the EXT_gpu_shader4 extensions of these
functions because EXT_gpu_shader4 should only be enabled for compat
already.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9887>
Fix defects reported by Coverity Scan.
uninit_member: Non-static class member buffer_block_index is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member ubo_byte_offset is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member shader_type is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member next_sampler is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member next_bindless_sampler is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member next_image is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member next_bindless_image is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member next_subroutine is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member field_counter is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member current_var is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member explicit_location is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member record_array_count is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member record_next_sampler is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member record_next_image is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member record_next_bindless_sampler is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member record_next_bindless_image is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member targets is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member shader_samplers_used is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member shader_shadow_samplers is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member num_bindless_samplers is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member num_bindless_images is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7910>
When we encounter a bindless image here, lower_deref returns a
NULL-pointer, and calling record_images_used will try to dereference
that NULL-pointer.
So let's dig out the var from the source instruction instead of the
result of the lowering.
Fixes: 5910c938a2 ("nir/glsl: gather bitmask of images used by program")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9895>
Specifically, fix this error (which is covered in existing tests):
../src/compiler/glsl/glcpp/pp.c:198:28: runtime error: applying non-zero offset 1 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/compiler/glsl/glcpp/pp.c:198:28 in
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9669>
valgrind returns exit code 126 if it can't write to the file passed to
--log-file. Hopefully it'll be the same for any other invalid valgrind
command line parameters or internal errors as well.
Using a different exit code (31) for this was hiding the fact that the
valgrind test wasn't actually working.
v2:
* Use exit code 126; can't treat any non-0 exit code as failure because
glcpp is expected to exit with non-0 for some of the input we feed it
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
Use pipes for direct communication between child & parent process.
Using tempfiles sometimes resulted in hitting the meson timeout if there
was high filesystem pressure (I saw a single unlink system call take as
long as 4 seconds; attempts to re-use a single tempfile just shifted the
delays to truncate/close systems calls).
As a bonus, this gets the valgrind test actually working as intended.
It wasn't working because the tempfile passed to --log-file didn't exist
(due to the earlier os.close(fd)?).
v2:
* Wrap .read() in "with open()" (Dylan Baker)
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
Once it's actually working as intended again, it may need that much
time.
v2:
* Bump to 240 seconds, still hit timeouts with 180.
* Don't change test priority.
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
valgrind flagged members of gl_ctx->Extensions being used uninitialized:
==23417== Conditional jump or move depends on uninitialised value(s)
==23417== at 0x112642: _glcpp_parser_handle_version_declaration.part.0 (glcpp-parse.y:2493)
==23417== by 0x11A515: glcpp_lex_update_state_per_token (glcpp-lex.l:132)
==23417== by 0x11A515: glcpp_lex (glcpp-lex.l:547)
==23417== by 0x114D46: glcpp_parser_lex (glcpp-parse.y:2302)
==23417== by 0x114D46: glcpp_parser_parse (glcpp-parse.c:1871)
==23417== by 0x11ADC6: glcpp_preprocess (pp.c:238)
==23417== by 0x111384: main (glcpp.c:174)
==23417== Uninitialised value was created by a stack allocation
==23417== at 0x111295: main (glcpp.c:136)
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
These qualifiers were removed in GLSL 4.20 and GLSL ES 3.00. For
desktop GL they are now only allowed if the shader is declared as
a compatibility shader.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9552>
gl_MaxVaryingFloats was not removed from core until 4.20 and is still
available in compat shaders. Found while writing some new CTS to test
the correct declarations of this constant.
Fixes: 0ebf4257a385i ("glsl: define some GLES3 constants in GLSL 4.1")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9514>
This reverts commit 6c8cc9be12.
A spec bug was resolved confirming the original behaviour. Also it
seems the game Foundation no longer depends on the incorrect
behaviour.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9486>
This replaces the new_src parameter of nir_ssa_def_rewrite_uses_after()
with an SSA def, and rewrites all the users as needed.
Acked-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9383>