If the clone_append was to a chunk of the same u_trace that gets
process_chunk()ed after where we're cloning from, then the payloads would
have been unreffed in the previous chunk's cleanup_chunk().
Fixes use-after-frees with turnip gmem rendering that resulted in
corrupted payloads.
Fixes: 14e45cb21e ("util/u_trace: refcount payloads")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35379>
ANGLE requires VK_EXT_transform_feedback or vertexPipelineStoresAndAtomics
to enable OpenGL ES 3.1 support. As we currently don't support this extension,
we enable support for vertexPipelineStoresAndAtomics via DRICONF
to allow XFB emulation on hardware without speculative behaviors around vertices (v13+).
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34758>
We only use the acquisition time for calculating latency for perfetto
tracks later, and the acquisition time should ideally be the start of the
perfetto flow.
This has been more or less true with very small error margin for vk wsi,
but the wayland EGL buffer handling is a lot more complicated. Moving the
time check into the flow start will make re-using this code for EGL much
simpler.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32757>
This enables implementations to pass context data between begin and
end tracing points, which is useful for more complex performance monitoring.
The change is minimal and only affects the function signatures and return
values, with no functional changes to existing behavior.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34893>
AArch64 supports non-temporal (streaming) loads and writes.
util_streaming_load_memcpy() is extended to support AArch64
non-temporal loads using inline assembly.
The mesa_util_sse41 name is updated to mesa_util_simd to reflect
support for non-x86 architectures.
This makes copies from non-cacheable to cacheable memory about 20%
faster on a Rock 5B.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34606>
'X4.exe' is the executable. But there is also a script 'X4' that is used to
launch the game. This script is what steam uses.
This updates driconf to match that.
This also brings the executable in line with other configs for the game.
Fixes: 5532f13566 ("driconf: override vendor id for X4 Foundations on NVK")
Fixes: 8654a7727f ("driconf: set vk_zero_vram driconf for X4 Foundations")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34168>
This had two uses, neither of them very good. On s390x we used it to
store the fact of our s390-ness, which we can replace with
DETECT_ARCH_S390. On x64 we used it to communicate AMD-Zen-ness to the
L3 topology detection code, which we can replace with a local parameter.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34820>
The glapi assembly code used to use this to force some symbols to stay
in the link even if they would normally get garbage-collected. We're not
doing that anymore. If we ever need it again we can add it back, and not
conflate its definition with the PUBLIC macro state while we're at it.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34820>
You need to re-emit name interning when incremental state is lost, so this
is the right home for the HT of "have we interned this name?". The
emitter function is still on the datasource because it needs the
templating to get the tracecontext type, but now getting the locked
datasource is not really necessary other than being way more ergonomic
than repeating the template parameters.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22350>
Will be useful if app doesn't specify depth direction correctly.
E.g. the capture of "Sons of The Forest" I have has a shader
where `gl_FragDepth` has `layout(depth_less)`, but the output for different
fragments is actually sometimes less, sometimes more than the original depth
by a tiny margin.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34423>
In function ‘SHA1Update’,
inlined from ‘SHA1Pad’ at ../../../../../../../mesa/src/util/sha1/sha1.c:157:2,
inlined from ‘SHA1Final’ at ../../../../../../../mesa/src/util/sha1/sha1.c:168:2:
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 1 [-Wstringop-overread]
135 | SHA1Transform(context->state, (uint8_t *)&data[i]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: note: referencing argument 2 of type ‘const uint8_t[64]’ {aka ‘const unsigned char[64]’}
../../../../../../../mesa/src/util/sha1/sha1.c: In function ‘SHA1Final’:
../../../../../../../mesa/src/util/sha1/sha1.c:55:1: note: in a call to function ‘SHA1Transform’
55 | SHA1Transform(uint32_t state[5], const uint8_t buffer[SHA1_BLOCK_LENGTH])
| ^~~~~~~~~~~~~
In function ‘SHA1Update’,
inlined from ‘SHA1Pad’ at ../../../../../../../mesa/src/util/sha1/sha1.c:159:3,
inlined from ‘SHA1Final’ at ../../../../../../../mesa/src/util/sha1/sha1.c:168:2:
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 1 [-Wstringop-overread]
135 | SHA1Transform(context->state, (uint8_t *)&data[i]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: note: referencing argument 2 of type ‘const uint8_t[64]’ {aka ‘const unsigned char[64]’}
../../../../../../../mesa/src/util/sha1/sha1.c: In function ‘SHA1Final’:
../../../../../../../mesa/src/util/sha1/sha1.c:55:1: note: in a call to function ‘SHA1Transform’
55 | SHA1Transform(uint32_t state[5], const uint8_t buffer[SHA1_BLOCK_LENGTH])
| ^~~~~~~~~~~~~
In function ‘SHA1Update’,
inlined from ‘SHA1Pad’ at ../../../../../../../mesa/src/util/sha1/sha1.c:160:2,
inlined from ‘SHA1Final’ at ../../../../../../../mesa/src/util/sha1/sha1.c:168:2:
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 8 [-Wstringop-overread]
135 | SHA1Transform(context->state, (uint8_t *)&data[i]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../../../mesa/src/util/sha1/sha1.c:135:25: note: referencing argument 2 of type ‘const uint8_t[64]’ {aka ‘const unsigned char[64]’}
../../../../../../../mesa/src/util/sha1/sha1.c: In function ‘SHA1Final’:
../../../../../../../mesa/src/util/sha1/sha1.c:55:1: note: in a call to function ‘SHA1Transform’
55 | SHA1Transform(uint32_t state[5], const uint8_t buffer[SHA1_BLOCK_LENGTH])
| ^~~~~~~~~~~~~
Reaching this code is impossible for the SHA1Update() calls in SHA1Pad().
Use assume() to inform the compiler of this.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34785>
The first pass computes which shader instructions contribute to each
output. It can be used to query how data flows within shaders towards
outputs.
The second pass computes which shader input components and which types of
memory loads are used to compute shader outputs.
The third pass uses the second pass to gather which input components are
used to compute pos and clip dist outputs, which input components are used
to compute all other outputs, and which input components are used to
compute both. This will be used by compaction in nir_opt_varyings for
drivers that split TES into a separate position cull shader and varying
shader to make it less likely that the same vec4 inputs are needed in both.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32262>
Emma Anholt