Instead of trusting in nil::Image::align_B, force it to the sparse
binding size because we know we're going to try and sparse bind it.
Otherwise, small sparse images could fail to bind at the bind step.
Fixes: 7321d151a9 ("nvk: Add support for sparse images")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
(cherry picked from commit 04bdbb71de)
With the weak symbols changes and -Dvulkan-beta this fails to link.
Co-authored-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Fixes: 2953c93cca ("vulkan Add enqueue entrypoint for CmdDispatchGraphAMDX")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30057>
(cherry picked from commit 24aab6bfaf)
This is an issue happening on radeonsi after the commit
6f8e6fb99c "mesa/st: use compute pbo download for readpixels".
This commit enables a new code path which has this memory leak.
For instance, this issue is triggered on radeonsi with
"piglit/bin/glsl-fs-raytrace-bug27060 -auto -fbo":
Too many leaks! Only the first 5000 leaks encountered will be reported.
Indirect leak of 327424 byte(s) in 5582 object(s) allocated from:
#0 0x7fe27fa4d7ef in __interceptor_malloc (/usr/lib64/libasan.so.6+0xb17ef)
#1 0x7fe2717fd4df in ralloc_size ../src/util/ralloc.c:118
#2 0x7fe272dbbae4 in calc_dom_children ../src/compiler/nir/nir_dominance.c:138
#3 0x7fe272dbbae4 in nir_calc_dominance_impl ../src/compiler/nir/nir_dominance.c:192
#4 0x7fe272b7f4a2 in nir_metadata_require ../src/compiler/nir/nir_metadata.c:40
#5 0x7fe272ba0d50 in nir_opt_cse_impl ../src/compiler/nir/nir_opt_cse.c:43
#6 0x7fe272ba0d50 in nir_opt_cse ../src/compiler/nir/nir_opt_cse.c:67
#7 0x7fe272686f83 in gl_nir_opts ../src/compiler/glsl/gl_nir_linker.c:92
#8 0x7fe271a31e69 in create_conversion_shader ../src/mesa/state_tracker/st_pbo_compute.c:701
#9 0x7fe271a353fa in create_conversion_shader_async ../src/mesa/state_tracker/st_pbo_compute.c:810
#10 0x7fe271806ea8 in util_queue_thread_func ../src/util/u_queue.c:309
#11 0x7fe27186379a in impl_thrd_routine ../src/c11/impl/threads_posix.c:67
#12 0x7fe27ea9a7c3 (/lib64/libc.so.6+0x867c3)
...
SUMMARY: AddressSanitizer: 1384704 byte(s) leaked in 17291 allocation(s).
Fixes: 5dab7673e1 ("mesa/st: add specialized pbo download shaders")
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/30068>
(cherry picked from commit f3c9ea9b8d)
These flags are set at the end of the job based on its buffer usage and
then checked by following jobs.
If an application toggles stencil and depth tests alternatigly in
a sequence of jobs while also relying on previous contents to render,
with the current assignment the reload flags for depth or stencil may
be cleared incorrectly and a depth/stencil buffer may not be properly
reloaded.
Cc: mesa-stable
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30065>
(cherry picked from commit aa4d0836fe)
Currently on each pop we reset the PopAttribState to the value from the
last push. But if we assume a sequence "push(X), push(Y), changeX(),
pop(), pop()": the first pop will remove X from PopAttribState, so the
second pop will not even try to restore X, leaving a wrong value forever.
Fix this by "bubbling up" the changed states that were not restored by pop.
Fixes: 68030bbf ("mesa: only pop states in glPopAttrib that have been changed since glPushAttrib")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11417
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30038>
(cherry picked from commit b0b1907fa5)
The NVIDIA proprietary driver exposes a DRM device these days and this
can trip up NVK as it advertises an NVIDIA device id. We fail to
enumerate but the check for nouveau happens too late and we throw a
warning. This means tha if NVK is even installed side-by-side with the
proprietary driver, we spam warnings on every device enumeration. It's
better to fail silently.
Fixes: 83786bf1c9 ("nvk: add vulkan skeleton")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11441
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30035>
(cherry picked from commit 73ec9f0183)
This adds a magic number and the device name to the binary in order to
verify we indeed have a binary we can parse and matches the device.
Also save the binary header explicitly in little-endian order, so that we
at least make sure that's always the same.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29946>
(cherry picked from commit f08f770f16)
this otherwise tries to use the depth component and a UNORM format,
which returns all zeroes
cc: mesa-stable
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29841>
(cherry picked from commit ef0a156670)
Coverity has spotted a place where we could in theory overflow. In
reality it wont happen as the potential overflow is a bitfield with a
maximum of two values. Add an `assume()` statement to help out the
compiler and document our assumption.
fixes: dc1aedef2b
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29825>
(cherry picked from commit dc604f340a)
Gallium/tests/trivial requires dynamic pipe loader at runtime, that is,
$prefix/$libdir/gallium-pipe/pipe_*.so must get built and installed.
so let's build it if build-tests is enabled.
v2:
- Fix error of meson when both of clover and tests are enabled (dbaker)
Signed-off-by: Luc Ma <luc@sietium.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27180>
(cherry picked from commit 6b5a12611b)
812b3415 added rules for upcasts with comparisons with a variety of
types. The float & unsigned rules should be ok, but the signed integer rules are
unsound as currently implemented. This can cause end-to-end miscompiles.
I originally hit this issue while debugging a large real world OpenCL kernel. I
found the bug symptoms changed when disabling loop unrolling, which tipped me
off to a compiler bug. I've reduced it to a minimal test case. Imagine my
surprise when I find out the NIR my backend ingested was already constant folded
to be wrong.
In the minimal test case, during optimization we have NIR:
32 %6 = ....
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
1 %45 = ilt %9, %44 (0x1)
This is a simple check (int64_t)%6 < 1.
nir_opt_algebraic turns this into:
32 %6 = ...
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
64 %55 = load_const (0x0000000080000000 = 2147483648)
1 %56 = ilt %55 (0x80000000), %44 (0x1)
64 %57 = load_const (0x000000007fffffff = 2147483647)
1 %58 = ilt %57 (0x7fffffff), %44 (0x1)
32 %59 = i2i32 %44 (0x1)
1 %60 = ilt %6, %59
1 %61 = ior %58, %60
1 %62 = iand %56, %61
This pile of math constant-folds to an unconditional "false"! The problem is
%56. At first glance, INT32_MIN < 1 is true so %56 should be true. Indeed, it
should. But here's the kicker: both constants are 64-bit here, so the ilt
operation is a 64-bit comparison -- that left-hand side is INT32_MIN
zero-extended to 64-bit for the signed comparison at 64-bit. So in fact, it
evaluates to false, causing the whole expression to go false. If we're going to
do a 64-bit comparison for %56, then we need to sign-extend the bound. So we'll
just adjust the Python and be on our way, right?
Unfortunately the issue is deeper. According to the comment in the generated
nir_opt_algebraic.c file, the guilty algebraic rule is:
('ilt', ('i2i64', 'a@32'), '#b') =>
('iand', ('ilt', -2147483648, 'b'), ('ior', ('ilt', 2147483647, 'b'), ('ilt', 'a', ('i2i32', 'b'))))
From a Python perspective? That rule is correct. -2147483648 < 1 is a true
statement. Adjusting the Python rule is not the appropriate solution here, since
the issue is more fundamental and might affect other rules. The real problem is
the translation of that Python replacement tree into C, incorrectly
zero-extending -2147483648 into 0x0000000080000000 instead of sign-extending to
0xffffffff80000000.
Crawling down the rabbit hole of the generated algebraic file, we see the
constant encoded as:
{ .constant = {
{ nir_search_value_constant, 64 },
nir_type_int, { -0x80000000 /* -2147483648 */ },
} },
NIR correctly translates the negative constant to a C level negate operation of
its absolute value. This maps to the correct sign-extension...
...for all constants except for INT_MIN. Because that constant lacks a ULL
suffix, it is a 32-bit integer. And for this integer (only), negating it hits
signed integer overflow (UB!) and then we end up with an effective
zero-extension when going to 64-bit.
This patch fixes the end-to-end miscompile.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Closes: #11402
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29952>
(cherry picked from commit 270446ee21)
This fixes spec@!opengl 1.0@gl-1.0-polygon-line-aa
spec@!opengl 1.1@clipflat and multiple piglit tests
failures on VGPU9 device
Fixes: 76725452 ("gallium: move vertex stride to CSO")
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29947>
(cherry picked from commit 8b8f347e4b)
This is not safe when we have conditional spills since we could be
spilling disabled lanes with undefined values that could overwrite
valid data for those lanes from a previous spill of the same temp
that was unconditional (or that condionally enabled those same
lanes).
Fixes some Piglit OpenCL tests as well as the following OpenCL tests:
integer_divideAssign
integer_moduloAssign
integer_mad_sat
integer_ops integer_divideAssign
integer_ops integer_mad_sat
integer_ops integer_moduloAssign
integer_ops quick_char_math
integer_ops quick_short_math
math_brute_force half_powr
math_brute_force pow
math_brute_force pown
math_brute_force powr
math_brute_force rootn
Fixes: 597560e27c ('broadcom/compiler: always enable per-quad on spill operations')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29909>
(cherry picked from commit d1f8351f3c)
The multop instruction implicitly writes rtop which is not preserved
acrosss thread switches. We can spill the sources of the multop
(since these would happen before multop) and the destination of
umul24 (since that would happen after umul24).
Fixes some OpenCL tests when V3D_DEBUG=opt_compile_time is used to
choose a different compile configuration.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29909>
(cherry picked from commit 38b7f411a1)
In a scenario where two non-concurrent cmdbufs are submitted to the
compute queue and with the second one using DGCC, the driver would have
chained the CS of the first cmdbuf to the new IB created right after
the DGC IB is executed.
Found while working on DGC task shader with vkd3d-proton.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29913>
(cherry picked from commit fec9b56f17)
nir_opt_preamble sometimes adds useless expressions, in which case we
may have stc instructions and no corresponding use of the constant.
Things can go sideways when these aren't included in the constlen, so
far only observed when earlypreamble is enabled.
Fixes: ccc64b7e00 ("ir3: Plumb through store_uniform_ir3 intrinsic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29903>
(cherry picked from commit c42f6597f9)
radv has a comment in radv_meta_dcc_retile.c:
* BPE is always 4 at the moment and the rest is derived from the tilemode.
radeonsi has in si_retile_dcc:
/* We have only 1 variant per bpp for now, so expect 32 bpp. */
assert(tex->surface.bpe == 4);
This fixes ext_image_dma_buf_import-modifiers for radeonsi.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29612>
(cherry picked from commit abd048124a)
We shouldn't use this extension at all if we're not using the HTML
builder. This should hopefully fix this issue a bit more fundamentally.
This caused issues when using the spelling extension, something I do
locally from time to time.
Fixes: f72033bb70 ("docs: add bootstrap extension")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29888>
(cherry picked from commit f4e7204e73)
