if the starts array has been reset, then the counter will be inaccurate,
and some of the members will leak, so this needs to iterate over the capacity
of the array instead of the contents
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21534>
For instance, with "piglit/arb_shading_language_include-api -auto -fbo" or
"piglit/shader_runner tests/spec/arb_shading_language_include/execution/replacement.shader_test -auto -fbo":
Direct leak of 66 byte(s) in 6 object(s) allocated from:
#0 0x7fa4b59050 in __interceptor_strdup (/usr/lib64/libasan.so.6+0x59050)
#1 0x7f9a098fe0 in validate_and_tokenise_sh_incl ../src/mesa/main/shaderapi.c:3383
#2 0x7f9a0a43e8 in _mesa_NamedStringARB ../src/mesa/main/shaderapi.c:3547
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21553>
This changes instances of d3d12_varying_info to d3d12_varying_info*,
significantly reducing the size of the d3d12_shader_key,
d3d12_gs_variant_key, and d3d12_tcs_variant_key.
Associated changes to key fill, compare, hashing, and gs and tcs variant
maps significantly reduce the amount of time spent clearing and
comparing memory.
The biggest win here is not having to re-zero _or_ re-fill varyings in
d3d12_fill_shader_key, validate_geometry_shader_variant, and
validate_tess_ctrl_shader_variant.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21527>
The spec citation says it's just for when the RT write message BTI might
point to a different RT, and if we don't have any color attachments then
we won't have one of those at all.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21508>
on tilers it's important to know whether a query is ended mid-renderpass
so that the query begin can occur inside/outside of the renderpass
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21533>
Now both GLSL and SPIR-V will produce the scoped barriers, so no
need to handle the old ones.
Control barriers are still present in some cases, so keep that
for now.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3339>
Only emit anything if this is a control barrier, i.e. contains an
execution scope. Also change the assertion to look at that scope
instead of the memory scope.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3339>
When the option is enabled, lower memory barriers to the
unified nir_intrinsic_scoped_barrier.
The translation of the following is based on
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt
- memoryBarrier()
- memoryBarrierBuffer()
- memoryBarrierImage()
- memoryBarrierShared()
- groupMemoryBarrier()
Also use scoped barrier for the memory counterparts of the GLSL
(control) barrier() when the option is enabled. The execution
part of a (control) barrier() remains using the old intrinsic.
For memoryBarrierAtomicCounter() there's no corresponding
nir_var_atomic_counter mode. Since atomic counters are lowered
to SSBOs, use the nir_var_mem_ssbo mode in the scoped barrier
instead.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3339>
A scoped barrier only has a control barrier behavior if there's
an execution scope.
Fixes: 13d900de0d ("llvmpipe: set nir_shader_compiler_options::use_scoped_barrier")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3339>
autotune already divides draw-cost by # of draws, but only increments
the draw-cost once per multi-draw. We could either _also_ account for
draw-cost by multiply by # of draws for treat multi-draw as a single
draw. The latter saves an integer multiply per draw.
Fixes a performance regression triggered by transition from GMEM to
sysmem rendering.
This reverts commit 6bfee9e669.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21543>
It's started rendering something different again, with a similar sort of
bad rendering to what's linked in the bug report (though this time it's a
'P' that became a white square). Commit range 65b62db0..964323fe has
nothing particularly likely in it, so I expect this is some sort of cache
flushing fail or something.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21565>
No longer need to redirect, since the renderer should use the fixed
decoder for VkDrmFormatModifierPropertiesListEXT::drmFormatModifierCount
by now.
This reverts commit 525b8c582f.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21395>
Follow-up to previous commit, this time to fix encoding/decoding for
VkDrmFormatModifierPropertiesListEXT::drmFormatModifierCount. Fixes a
workaround (WA1) in the venus-protocol.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21395>
If a dual source blend colour is never written, src1 will be null and it will be
invalid to dereference it. src1 is dereferenced both for the f2fN instruction
but also if a dual blend factor is used... even if the latter isn't strictly
valid, segfaulting in the NIR pass seems a lot meaner than blending with zero.
The referenced commit hosed Asahi, causing anything that used blending to crash.
Panfrost is unaffected since it always supplies a dual colour due to our crude
construction of blend shaders.
Fixes: 8313016543 ("nir/lower_blend: Consume dual stores")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21544>
