When I initially started writing these lists, I expected the lists to be
much less uniform in what bits were required. Turns out I was wrong, and
this ended up really neat and orderly.
I'm sure we're missing some defacto requirements here and there,
especially for the early versions. This list is based on what we check
for in version.c, and it's better than nothing.
Suggested by Mike Blumenkrantz.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9602>
Triple backticks doesn't mean anything in RST, so this becomes quoted
strings containing backticks. That's not what I meant here...
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9602>
It used to be that this intrinsic was never created and texture
instructions were always used.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 50881d59e6 ("compiler/spirv: fix image sample queries")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9686>
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>
Once the glcpp valgrind test works as intended again, it would delay
the dependent test jobs by ~1-4 minutes.
The meson-clover job would run the glcpp valgrind test multiple times
and take more than 10 minutes to finish.
valgrind can't work in the meson-android job, would need an ARM backend.
v2:
* Disable in meson-clover as well.
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>
Instead of using tempfiles to communicate between child & parent
process. The latter sometimes resulted in hitting the meson timeout if
there was high filesystem pressure.
Fixes: ccaa5b034f "intel/tools: rewrite run-test.sh in python"
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
this flushes any pending updates and avoids trying to access constant buffers
which have been unset (and are also potentially deleted)
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9692>
llvmpipe has some crazy dependency ordering with constant buffers that
I don't want to mess with, so instead this ensures that descriptors are
always updated as early in the command stream as possible, avoiding any
use-after-free scenarios which might result from lavapipe freeing memory
in a still-bound descriptor that's pending an update
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9692>
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>
The template path was buggy but CTS only tested it with Vulkan 1.1 enabled.
It was just missing the dstArrayElement offset.
Fixes: 41f7fa273d ("lavapipe: add support for VK_KHR_descriptor_update_template")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9675>
Like with the sample qualifier on all GPUs, use pixel on older HW when
MSAA rasterization is disabled to get reliable results. Since I ran many
CI jobs on this, this updates the A530 TF flakes list, though I don't
think that this MR necessarily made it flakier (we were already struggling
on a5xx TF, which was what was motivating me to look at this!)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9641>
After some research, I found out that the alignment needs to be set
on the return value of the load, rather than on the pointer.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: 14ad82b4e9 "ac/llvm: Emit more efficient code for load_shared."
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9688>
Switch from the old piglit to the new piglit-runner executor.
Acked-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9680>
MSVC warns (loudly) about a mismatch between the generated functions in
u_format_table.c and the definition of util_format_[un]pack_description,
specifically having 'restrict' in the function but not in the pointer
type in the struct.
So, add 'restrict' everywhere - to the function types, and to the rest
of the implementations that are assigned to those structs.
v2: util_format_unpack_description is used in gallium/auxiliary/translate
Fixes: 5785fdac ("u_format: Mark the generated pack/unpack src/dst args as restrict.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9670>
this was only implemented for textures (I assume because drivers which implement
the corresponding intrinsic don't support multisampled images), but it's also
used for shader images
Fixes: 22fdb2f855 ("nir/spirv: Update to the latest revision")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9682>
