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>
(cherry picked from commit 50881d59e6)
The calculate_tess_lds_size function already returns the size in blocks
of the encoding granule, but we forgot to adjust config->lds_size.
This variable is not used to actually set the LDS size used for TCS,
but by ACO to make scheduling decisions.
Fossil DB stats on Sienna Cichlid:
Please note that the +3729.43% is NOT a regression.
The real LDS size used didn't change, it was just reported incorrectly.
Totals from 1342 (0.96% of 139391) affected shaders:
VGPRs: 60880 -> 80240 (+31.80%); split: -0.05%, +31.85%
CodeSize: 3378456 -> 3381224 (+0.08%); split: -0.23%, +0.31%
LDS: 687104 -> 26312192 (+3729.43%)
MaxWaves: 29794 -> 23962 (-19.57%)
Instrs: 644194 -> 644610 (+0.06%); split: -0.32%, +0.39%
Cycles: 2675068 -> 2676804 (+0.06%); split: -0.31%, +0.38%
VMEM: 428840 -> 517418 (+20.66%); split: +22.53%, -1.88%
SMEM: 91831 -> 88587 (-3.53%); split: +5.70%, -9.23%
VClause: 22740 -> 19384 (-14.76%); split: -16.18%, +1.42%
SClause: 19116 -> 18373 (-3.89%); split: -4.34%, +0.46%
Copies: 66662 -> 63448 (-4.82%); split: -5.55%, +0.73%
Fixes: cf89bdb9ba "radv: align the LDS size in calculate_tess_lds_size()"
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9557>
Vertex attribute bounds checking is supposed to be done per-attribute:
is_oob = index * stride + attrib_offset + attrib_size > buffer_size
but we were obtaining num_records by dividing the buffer size by the
stride, making it per-vertex:
is_oob = index * stride + (stride - 1) >= buffer_size
An example from Dead Cells (Wine) is:
attribute bindings: 0, 1, 2
attribute formats: r32g32, r32g32, r32g32b32a32
attribute offsets: 0, 0, 0
binding buffers: all the same buffer
binding offsets: 0, 8, 16
binding sizes: 128, 120, 112
binding strides: 32, 32, 32
Workaround this issue without switching to per-attribute descriptors by
rounding up the division. This is still incorrect, but it should now no
longer consider in-bounds attributes out-of-bounds.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3796
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4199
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9557>
Fixes several dEQP-VK.robustness.robustness2.* tests on GFX8. Generations
other than GFX8 don't fail the tests because bounds-checking is done using
the index (making it per-vertex).
fossil-db (Polaris):
Totals from 1387 (0.99% of 140385) affected shaders:
(no statistics affected)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 03a0d39366 ("aco: use MUBUF in some situations instead of splitting vertex fetches")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9557>
ACO attempts to store the output of an instruction in the same register
occupied by its operands where possible. Importantly this only works if
the operands are large enough to store the result register size. The code
failed to consider subdword operands when checking for this, causing
entire register slots to be freed up even though subdword parts were still
used.
In Mafia 3, this affected the following code:
v2b: %363:v[2][0:16], v2b: %362:v[2][16:32] = p_split_vector %360:v[2]
v1: %116:v[2] = v_cvt_f32_f16 %362:v[2][16:32]
v1: %117:v[2] = v_cvt_f32_f16 %363:v[2][0:16]
where v[2] is allocated to %116 even though its original lower 16 bits are
still used in the instruction after.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3717
Fixes: 031edbc4a5
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9557>
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>
(cherry picked from commit 684f97de80)
Before we introduced the submission thread in 829699ba63, once we
returned from vkQueueSubmit, all signaled syncobj would have a
i915_request/dma-fence waiting to be signaled by some work that would
submitted to HW by i915.
After this submission thread that is no longer the case. We added a
few checks in places like vkQueuePresentKHR() to wait for the binary
semaphores to materialize before we would hand things over to the WSI
code.
Unfortunately 829699ba63 forgot to reset the signaled binary
semaphore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 829699ba63 ("anv: implement shareable timeline semaphores")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4276
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry-picked from commit cb74cd816c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9554>
Starting with d0d039a4d3, we emit writes to the push constant chunk
of the payload to stomp out-of-bounds data to zero for Vulkan. Then, in
369eab9420, we started emitting shader preamble code for emulated
push constants on Gen12.5 parts. In either of these cases, we can run
into issues if we don't have a proper live range for some of the payload
registers where they get used for something and then smashed by our push
handling code. We've not seen many issues with this yet because it only
happens when you have dead push constants.
Fixes: d0d039a4d3 "anv: Emit pushed UBO bounds checking code..."
Fixes: 369eab9420 "intel/fs: Emit code for Gen12-HP indirect..."
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9501>
(cherry picked from commit b9e9f92f73)
The container is moved from before and hence returns size 0. To get the
correct value, the new instruction container must be used instead.
This was flagged by clang-tidy. The fixed call still triggers the
corresponding diagnostic, hence this change silences it by adding a
redundant clear() after move.
Fixes: 7f1b537304 ("aco: add new NOP insertion pass for GFX6-9")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9432>
(cherry picked from commit 97c97781f6)
We need to iterate the whole row, we can't be clever and only look at
one side, the symmetry doesn't work like that. See the original paper.
total instructions in shared programs: 69392 -> 69322 (-0.10%)
instructions in affected programs: 9002 -> 8932 (-0.78%)
helped: 82
HURT: 28
Instructions are helped.
total bundles in shared programs: 32225 -> 32155 (-0.22%)
bundles in affected programs: 4286 -> 4216 (-1.63%)
helped: 82
HURT: 28
Bundles are helped.
total quadwords in shared programs: 56102 -> 56102 (0.00%)
quadwords in affected programs: 0 -> 0
helped: 0
HURT: 0
total registers in shared programs: 4552 -> 4572 (0.44%)
registers in affected programs: 298 -> 318 (6.71%)
helped: 18
HURT: 38
Registers are HURT.
total threads in shared programs: 3772 -> 3775 (0.08%)
threads in affected programs: 84 -> 87 (3.57%)
helped: 15
HURT: 14
Inconclusive result (value mean confidence interval includes 0).
total spills in shared programs: 0 -> 0
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 0 -> 0
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
Fixes: 66ad64d73d ("pan/midgard: Implement linearly-constrained register allocation")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9338>
(cherry picked from commit 4f969d796d)
libpanfrost_lib depends on libpanfrost_bifrost for 'bifrost_compile_shader_nir' symbol
libpanfrost_lib depends on libpanfrost_bifrost_disasm for 'disassemble_bifrost' symbol
LOCAL_STATIC_LIBRARIES requires proper ordering to make the symbols available
Fixes the following building error happening with Android P:
FAILED: out/target/product/x86_64/obj/SHARED_LIBRARIES/gallium_dri_intermediates/LINKED/gallium_dri.so
external/mesa/src/panfrost/lib/decode.c:534: error: undefined reference to 'disassemble_bifrost'
external/mesa/src/panfrost/lib/pan_shader.c:145: error: undefined reference to 'bifrost_compile_shader_nir'
Cc: 20.3 21.0 <mesa-stable@lists.freedesktop.org>
Fixes: 166630f ("android: pan/bi: Separate disasm/compiler targets")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9265>
(cherry picked from commit 97b7786e6b)
We have to choose between:
1) Stop handling two identical GPUs
2) Stop having crashes with other layers active.
3) Fix the Vulkan Loader.
Since nobody seems to want to spend enough effort to do 3 the
effective choice is between 1 and 2. This is choosing 2, as
two identical GPUs is pretty uncommon since crossfire doesn't
work on Linux anyway.
(And it would only work sporadically as the game needs to enable the
extension)
CC: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8414>
(cherry picked from commit 38ce8d4d00)
fmin(-A, -B) is -fmax(A, B), and fmax(-A, -B) is -fmin(A, B). Therefore
the logic joining A and B should toggle between ior and iand for the
negated versions.
At the very least, a shader from Euro Truck Simulator 2 in shader-db is
affected by this. The KIL instruction in the (ARB assembly) shader ends
up with the wrong logic. This is _probably_ the source of
https://gitlab.freedesktop.org/mesa/mesa/-/issues/1346.
That said, the issue mentions that Mesa 18.0.5 works, but commit
68420d8322 ("nir: Simplify min and max of b2f") was added in 17.3.
Moreover, I was not able to reproduce the error in the ETS2 shader from
shader-db from any Mesa commit near the time the original fd.o bugzilla
was submitted (December 2018). 🤷
In fact, the current error in that shader starts with 9167324a86
("nir/algebraic: Mark some logic-joined comparison reductions as
exact"). That's a bit of a red herring as 9167324a86 just sets off a
chain of replacements that eventually leads to the incorrect min/max of
b2f patterns fixed by this commit.
The other affected shaders in the shader-db results are from Cargo
Commander. These are also ARB assembly shaders.
I think any ARB assembly shader that uses the pattern
SLT r0, ...;
...
KIL -r0;
will suffer from issues related to this.
This change fixes the piglit
tests/spec/arb_fragment_program/kil-of-slt.shader_test test added in
https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/454.
shader-db results:
All Gen6+ platforms had similar result. (Ice Lake shown)
total instructions in shared programs: 20034604 -> 20034486 (<.01%)
instructions in affected programs: 3885 -> 3767 (-3.04%)
helped: 47
HURT: 2
helped stats (abs) min: 2 max: 4 x̄: 2.64 x̃: 2
helped stats (rel) min: 2.33% max: 8.33% x̄: 3.48% x̃: 3.39%
HURT stats (abs) min: 3 max: 3 x̄: 3.00 x̃: 3
HURT stats (rel) min: 13.64% max: 16.67% x̄: 15.15% x̃: 15.15%
95% mean confidence interval for instructions value: -2.83 -1.99
95% mean confidence interval for instructions %-change: -3.84% -1.60%
Instructions are helped.
total cycles in shared programs: 979881379 -> 979879406 (<.01%)
cycles in affected programs: 119873 -> 117900 (-1.65%)
helped: 46
HURT: 3
helped stats (abs) min: 10 max: 756 x̄: 45.41 x̃: 26
helped stats (rel) min: 0.53% max: 19.72% x̄: 1.67% x̃: 1.26%
HURT stats (abs) min: 28 max: 56 x̄: 38.67 x̃: 32
HURT stats (rel) min: 1.44% max: 3.54% x̄: 2.75% x̃: 3.27%
95% mean confidence interval for cycles value: -70.83 -9.70
95% mean confidence interval for cycles %-change: -2.23% -0.57%
Cycles are helped.
Iron Lake and GM45 had similar results. (Iron Lake shown)
total instructions in shared programs: 8115098 -> 8115076 (<.01%)
instructions in affected programs: 2592 -> 2570 (-0.85%)
helped: 32
HURT: 2
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 0.88% max: 2.70% x̄: 1.35% x̃: 1.31%
HURT stats (abs) min: 5 max: 5 x̄: 5.00 x̃: 5
HURT stats (rel) min: 17.24% max: 18.52% x̄: 17.88% x̃: 17.88%
95% mean confidence interval for instructions value: -1.15 -0.15
95% mean confidence interval for instructions %-change: -1.83% 1.39%
Inconclusive result (%-change mean confidence interval includes 0).
total cycles in shared programs: 238189718 -> 238189802 (<.01%)
cycles in affected programs: 75076 -> 75160 (0.11%)
helped: 3
HURT: 31
helped stats (abs) min: 2 max: 130 x̄: 44.67 x̃: 2
helped stats (rel) min: 0.18% max: 5.70% x̄: 2.02% x̃: 0.19%
HURT stats (abs) min: 2 max: 70 x̄: 7.03 x̃: 4
HURT stats (rel) min: 0.07% max: 6.41% x̄: 0.53% x̃: 0.15%
95% mean confidence interval for cycles value: -7.27 12.21
95% mean confidence interval for cycles %-change: -0.33% 0.94%
Inconclusive result (value mean confidence interval includes 0).
No fossil-db changes on any Intel platform.
Fixes: 68420d8322 ("nir: Simplify min and max of b2f")
Closes: #1346
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9122>
(cherry picked from commit 7e127c1fca)
Fixes 'nir_tex_src_coord' param was provided to NIR 'txf' operation as a
vec3 for TEXTURE_1D_ARRAY target, causing an assert.
Only following targets require vec3: TEXTURE_2D_ARRAY, TEXTURE_3D,
TEXTURE_CUBE, TEXTURE_CUBE_ARRAY. The rest must use vec2.
Packing layer value into Y-coordinate the same way it was done in
'create_fs' in commit 2bf6dfac.
Fixes: a01ad311 ("st/mesa: Add NIR versions of the PBO upload/download
shaders. ")
Signed-off-by: Yevhenii Kharchenko <yevhenii.kharchenko@globallogic.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9014>
(cherry picked from commit 1516b6bd9a)
They've all supported it since either forever or Iron Lake which is
equivalent to forever for Vulkan.
From Kenneth Graunke's GitLab review:
"Linear blending of depth buffer data is usually fairly nonsense
(something's 2 meters away? another thing's 6 meters away? let's
just report 4 meters?)...but it's definitely a thing we can do, so
we may as well let apps do it, and trust them not when it doesn't
make sense."
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9110>
(cherry picked from commit 56d005c21c)
Test the sampler->conversion for NULL pointer before dereferencing it.
Fixes: Regressions in VulkanCTS.
Fixes: 226316116c "intel/anv: Fix condition to set MipModeFilter for YUV surface"
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 69e94e8939)
On Intel platforms before Gen6, there is no min or max instruction.
Instead, a comparison instruction (*more on this below) and a SEL
instruction are used. Per other IEEE rules, the regular comparison
instruction, CMP, will always return false if either source is NaN. A
sequence like
cmp.l.f0.0(16) null<1>F g30<8,8,1>F g22<8,8,1>F
(+f0.0) sel(16) g8<1>F g30<8,8,1>F g22<8,8,1>F
will generate the wrong result for min if g22 is NaN. The CMP will
return false, and the SEL will pick g22.
To account for this, the hardware has a special comparison instruction
CMPN. This instruction behaves just like CMP, except if the second
source is NaN, it will return true. The intention is to use it for min
and max. This sequence will always generate the correct result:
cmpn.l.f0.0(16) null<1>F g30<8,8,1>F g22<8,8,1>F
(+f0.0) sel(16) g8<1>F g30<8,8,1>F g22<8,8,1>F
The problem is... for whatever reason, we don't emit CMPN. There was
even a comment in lower_minmax that calls out this very issue! The bug
is actually older than the "Fixes" below even implies. That's just when
the comment was added. That we know of, we never observed a failure
until #4254.
If src1 is known to be a number, either because it's not float or it's
an immediate number, use CMP. This allows cmod propagation to still do
its thing. Without this slight optimization, about 8,300 shaders from
shader-db are hurt on Iron Lake.
Fixes the following piglit tests (from piglit!475):
tests/spec/glsl-1.20/execution/fs-nan-builtin-max.shader_test
tests/spec/glsl-1.20/execution/fs-nan-builtin-min.shader_test
tests/spec/glsl-1.20/execution/vs-nan-builtin-max.shader_test
tests/spec/glsl-1.20/execution/vs-nan-builtin-min.shader_test
Closes: #4254
Fixes: 2f2c00c727 ("i965: Lower min/max after optimization on Gen4/5.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Iron Lake and GM45 had similar results. (Iron Lake shown)
total instructions in shared programs: 8115134 -> 8115135 (<.01%)
instructions in affected programs: 229 -> 230 (0.44%)
helped: 0
HURT: 1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9027>
(cherry picked from commit 3c31364f5e)
Mip Mode Filter must be set to MIPFILTER_NONE for Planar YUV surfaces.
Add the missing condition to check for planar format.
Fixes: b24b93d584 "anv: enable VK_KHR_sampler_ycbcr_conversion"
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 226316116c)
On Gen7, we have to split shuffles into two MOVs for 64-bit types so we
can't handle source modifiers. On Gen12.5, we have to use integer types
all the time so we can't use them there either. Fixing that will be a
different commit but it interacts with this one.
Fixes: 90c9f29518 "i965/fs: Add support for nir_intrinsic_shuffle"
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9068>
(cherry picked from commit 3ce6ca7214)
We can't move the shuffle to a new block so this only works if the
shuffle and the bcsel are in the same block. Fortunately, in the
motivating case, this is true.
Also, we have to be careful around discard. We could try really hard to
just avoid moving them past discard but we choose to simply bail if we
see a discard instead.
Fixes: 4ff4d4e569 "nir/opt_intrinsic: Optimize bcsel(b, shuffle..."
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9068>
(cherry picked from commit ceb6986d34)
asan on llvmpipe with piglit tests/spec/arb_gl_spirv/execution/ssbo/array-indirect.shader_test
reported.
=================================================================
==3288325==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f5b2d6513cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
#1 0x7f5b2a1ae810 in ralloc_size ../src/util/ralloc.c:133
#2 0x7f5b2a1ae7e1 in ralloc_context ../src/util/ralloc.c:120
#3 0x7f5b2b210177 in gl_nir_link_uniform_blocks ../src/compiler/glsl/gl_nir_link_uniform_blocks.c:585
#4 0x7f5b2af7f52d in gl_nir_link_spirv ../src/compiler/glsl/gl_nir_linker.c:614
#5 0x7f5b2a3b76fa in st_link_nir ../src/mesa/state_tracker/st_glsl_to_nir.cpp:765
#6 0x7f5b2a3ace7b in st_link_shader ../src/mesa/state_tracker/st_glsl_to_ir.cpp:65
#7 0x7f5b2a471165 in _mesa_glsl_link_shader ../src/mesa/program/ir_to_mesa.cpp:3122
#8 0x7f5b2a97a6d8 in link_program ../src/mesa/main/shaderapi.c:1311
#9 0x7f5b2a97a6d8 in link_program_error ../src/mesa/main/shaderapi.c:1419
#10 0x7f5b2a97df45 in _mesa_LinkProgram ../src/mesa/main/shaderapi.c:1911
#11 0x7f5b299b59e5 in stub_glLinkProgram /mnt/devel/gl/piglit/tests/util/piglit-dispatch-gen.c:33956
#12 0x40a71a in link_and_use_shaders /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:1604
#13 0x415722 in init_test /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5225
#14 0x4164ce in piglit_init /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5597
#15 0x7f5b29a214e9 in run_test /mnt/devel/gl/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
#16 0x7f5b29a103fe in piglit_gl_test_run /mnt/devel/gl/piglit/tests/util/piglit-framework-gl.c:229
#17 0x407847 in main /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:72
#18 0x7f5b2928f1e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
SUMMARY: AddressSanitizer: 48 byte(s) leaked in 1 allocation(s).
Fixes: 57239192 ("nir/linker: add gl_nir_link_uniform_blocks.c")
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8974>
(cherry picked from commit 14b2dc0013)
This should no longer be necessary since the mark_block_wqm() we use to
flag break conditions as WQM now adds block to the worklist. With them
added to the worklist, get_block_needs() will add WQM to block_needs.
Adding WQM to block_needs here without adding the block to the worklist
(like we do here) can cause issues because it does not ensure that the
predecessors' branches are in WQM (needed for it to be possible to
transition to WQM in the block). This happened in an Overwatch shader.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 661922f6ac ("aco: add block to worklist in mark_block_wqm()")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4066
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8446>
(cherry picked from commit f0074a6f05)
The base mask previously used was 0xffffffff. This is not correct (but
should still work) for 16-bit and 8-bit values, but it means the high
32-bits of 64-bit values will get chopped off.
Instead of just restricting the pattern to 32-bits (as was done before
00b28a50b2), this extends the optimization in two ways:
1. Make it correct for other bit sizes.
2. Make it work for arbitrary shift counts.
This has the added benefit of reducing the number of patterns actually
added (7 previously, 4 now).
The "Reassociate for improved CSE" part is just reverted to its
pre-00b28a50b2c behavior. I doubt that pattern is likely to have much
impact outside 32-bits.
This change fixes the piglit tests
tests/spec/arb_gpu_shader_int64/fs-shl-of-shr-int64.shader_test and
tests/spec/arb_gpu_shader_int64/fs-iand-of-iadd-int64.shader_test.
All of the shaders helped in shader-db are vertex shaders on platforms
with vector-oriented vertex processing. The shaders contain ((x >> 16)
<< 16). These platforms set lower_extract_word, so the optimization
that transforms (x >> 16) to extract_u16 doesn't trigger. With only ~60
shaders involved, I didn't bother trying to add extract_XYZ versions of
these patterns to try to get those cases.
Fixes: 00b28a50b2 ("nir/algebraic: trivially enable existing 32-bit patterns for all bit sizes")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Haswell and earlier Intel GPUs had simlar results. (Haswell shown)
total instructions in shared programs: 16397554 -> 16397496 (<.01%)
instructions in affected programs: 7961 -> 7903 (-0.73%)
helped: 58
HURT: 0
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 0.36% max: 1.89% x̄: 0.99% x̃: 0.78%
95% mean confidence interval for instructions value: -1.00 -1.00
95% mean confidence interval for instructions %-change: -1.13% -0.85%
Instructions are helped.
total cycles in shared programs: 1035483770 -> 1035483504 (<.01%)
cycles in affected programs: 75922 -> 75656 (-0.35%)
helped: 44
HURT: 2
helped stats (abs) min: 2 max: 12 x̄: 6.14 x̃: 2
helped stats (rel) min: 0.05% max: 1.67% x̄: 0.87% x̃: 0.72%
HURT stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
HURT stats (rel) min: 0.06% max: 0.06% x̄: 0.06% x̃: 0.06%
95% mean confidence interval for cycles value: -7.28 -4.29
95% mean confidence interval for cycles %-change: -1.03% -0.63%
Cycles are helped.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8852>
(cherry picked from commit 6b0443a900)
The polygon list is written by tiler jobs and read by fragment ones,
and nothing should re-use the heap until the fragment job is done.
4fec6c9448 ("panfrost: Add the tiler heap to fragment jobs") fixed
this for the !multi-context case by adding the heap BO to fragment job.
But the tiler heap is shared accross contexts, and vertex/tiler+fragment
job submission is done through 2 separate ioctls, meaning that
vertex/tiler and fragment jobs from 2 different context might be
interleaved.
Add a lock at the device level to ensure tiler/vertex+fragment jobs are
submitted sequentially, with no other jobs using the same tiler heap
in-between.
Cc: mesa-stable
Fixes: d8deb1eb6a ("panfrost: Share tiler_heap across batches/contexts")
Reported-by: Icecream95 <ixn@disroot.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8822>
(cherry picked from commit 66125c429f)
Single-line version of MSVC warning suppression does not extend beyond
the #endif directive. Use push/disable/pop instead.
Also suppress 26452, which is a similar analysis warning.
This could also be fixed with constexpr if, but C++17 would be required.
Fixes: 790516db0b ("gallium/swr: fix gcc warnings")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8093>
(cherry picked from commit 3c7062417b)
Disable compression in iris_flush_resource if the resource lacks a
modifier. When a caller wants to prepare such a resource for sharing
(via eglCreateImage for example), this change enables all reference
holders to access the resource in a common manner - without compression.
This fixes misrendering with 3D-accelerated qemu. A piglit test which
reproduces qemu's behavior, ext_image_dma_buf_import-export-tex, is also
enabled to pass.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2678
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8663>
(cherry picked from commit 40d6b92de9)
Many entries in the dri2_format_table have _DRI_IMAGE_FORMAT_NONE as the
dri_format. Make the result of dri2_get_mapping_by_format a tad more
well-defined by returning NULL when this format is passed into it.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8663>
(cherry picked from commit 0a8cc88202)
In Vulkan, for some variable modes, the generated NIR will have derefs
pointing to resource index intrinsics instead of the variable. This
was letting nir_remove_dead_variables pass remove those variables,
which would lose information relevant for later passes after
spirv2nir.
Add a set to keep track of such variables and prevent them to be
removed when producing the NIR output.
Issue reported by Rhys.
Fixes: c4c9c780b1 ("spirv: Remove more dead variables")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8706>
(cherry picked from commit 10b3eecd36)
We can skip CCS ambiguate if followed by a fast clear within render
pass.
v2: (Jason)
- Check array layer as well since we only fast clear first layer and
first LOD.
- Don't drop fast clear check while doing resolve operation.
Fixes: d5849bc840 "anv: Skip HiZ and CCS ambiguates which preceed fast-clears"
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6988>
(cherry picked from commit 001722b3a3)
According to the BSpec page for MEDIA_VFE_STATE, on Gen12 platforms
"if a fused configuration has fewer threads than the native POR
configuration, the scratch space allocation is based on the number of
threads in the base native POR configuration". However we currently
use the subslice count from devinfo->num_subslices[0], which only
includes the subslices currently enabled by the platform fusing. This
leads to scratch space underallocation and occasional hangs.
The problem is likely to affect most Gen12 GPUs with less than 96 EUs.
GFXBench5 Aztec Ruins is able to reproduce the issue fairly reliably.
Fixes: 9e5ce30da7 "intel: fix the gen 12 compute shader scratch IDs"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8636>
(cherry picked from commit e2c5ef6cd6)
While invalidating the AUX-TT entries, we have to consider the surface
offset as well otherwise, we will end up invalidating another surface's
CCS portion.
For eg. when we have HiZ+CCS and STC_CCS enabled, both will use the CCS
portion allocated at the end of BO. While invalidating the CCS portion
of stencil buffer, we will end up invalidating the CCS portion that
belongs to the depth main surface and vice-versa, if the surface offset
is not considered.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4123
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8677>
(cherry picked from commit dab229ef69)
If PAN_MESA_DEBUG=deqp is set to enable testing, then we advertise shader
images to get GLES3.1, even though we don't have any of the shader image
funcs hooked up. This caused breakage when cso started unbinding shader
images at context destruction.
Just stub out the function for now, you'll still segfault when creating an
image.
Cc: mesa-stable (for the next commit)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8530>
(cherry picked from commit f259fcae83)
We could probably support some strides if we tried hard enough but the
whole point of this opcode is to accelerate things with crazy Align16 or
crazy regions. It's ok if we have to emit an extra MOV to get a packed
source.
Fixes: 8b4a5e641b "intel/fs: Add support for subgroup quad operations"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7329>
(cherry picked from commit 58bcb5401d)
Previously, we were returning 2 whenever the source was a Q type. As
far as I can tell, the only reason why this hasn't blown up before is
that it was only ever used for VGRFs until the SWSB pass landed which
uses it for everything. This wasn't a problem because Q types generally
aren't a thing on TGL. However, they are for a small handful of
instructions.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7329>
(cherry picked from commit 4c8cbe9b13)
The intention of IRIS_DIRTY_{RENDER,COMPUTE}_RESOLVES_AND_FLUSHES
is to avoid considering resolves/flushes on back to back draw calls
where nothing of significance has changed with the resources. When
anything changes that could require a resolve, we must flag those.
Those situations are:
1. Texture/image/framebuffer bindings change
(as the set of images we need to look at is now different)
2. Depth writes are enabled/disabled (the resolve code uses this)
3. The aux state for a currently bound resource changes.
We were missing this last case. In particular, one example where
we missed this was:
1. Bind a texture.
2. Clear that texture (likely blits/copies/teximage would work too)
3. Draw and sample from that texture
Clear-then-Bind would work, as binding would flag resolves as dirty.
But Bind-then-Clear doesn't work, as clear can change the aux state
of the bound texture, but wasn't flagging that anything had changed.
Technically, we could consider whether the resource whose aux state
is changing is bound for compute (and only flag COMPUTE_RESOLVES),
or bound for a 3D stage (and only flag RENDER_RESOLVES), and flag
nothing at all if it isn't bound. But we don't track that well,
and it probably isn't worth bothering. So, flag unconditionally
for now.
This does not appear to impact Piglit's drawoverhead scores.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3994
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4019
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8603>
(cherry picked from commit e2500c02cc)
When NGG is used, the hw can't know the number of geometry shader
primitives. To fix that, the NGG geometry shader accumulates itself
the number of primitives by using an atomic operation directly to GDS.
Then, begin/query copy the start/stop values from GDS to the
query pool buffer using a PS_DONE event. This was actually wrong
because PS_DONE is completely asynchronous to everything and executed
when the preceding draws finish pixel shaders.
Fix this by using a COPY_DATA packet which is synced with CP. This
fixes random failures on Sienna Cichlid with
dEQP-VK.query_pool.statistics_query.*.geometry_shader_primitives.*.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8590>
(cherry picked from commit 085e2ce3d4)
We incorrectly utilize the stencil layouts structures even if we
should stick to the depth_stencil ones if the layout includes stencil.
v2: Don't forget stencil only layout (Nanley)
Simplify callers of new helper functions (Nanley)
v3: Store VK_IMAGE_LAYOUT_UNDEFINED when no stencil is available (Nanley)
Use a switch statement (Nanley)
v4: Consider all layouts but depth only to be potential stencil layouts (Lionel)
v5: Refactor helper in vk_image_layout_depth_only() and discard
VkAttachmentDescriptionStencilLayoutKHR in
VkAttachmentDescription2KHR if format is not depth/stencil.
v5: s/LAYOUT_COLOR_ATTACHMENT_OPTIMAL/LAYOUT_DEPTH_ATTACHMENT_OPTIMAL/ (Nanley)
v6: Fix overly harsh assert()
Fixes: c1c346f166 ("anv: implement VK_KHR_separate_depth_stencil_layouts")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4084
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8475>
(cherry picked from commit 28207669d0)
This limits the exposure of these functions to when the extension is
available. Prevents crashes otherwise, as the rest of the infrastructure
doesn't necessarily expect these functions when the extension is not
available.
Fixes: 40c1f9883e ("mesa,glsl: add support for GL_NV_shader_atomic_int64")
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8533>
(cherry picked from commit a0f4affcf6)
The vulkan loader doesn't load layers for apps that require a newer
version of vulkan, so this layer didn't get loaded for vulkan 1.2 apps.
I would like to just stick 1.09 in there but it might be worth
validating it works at new version of vulkan I suppose and the major
doesn't revise that often
Fixes: 9bc5b2d169 ("vulkan: add initial device selection layer. (v6)")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8508>
(cherry picked from commit ca834d0b2d)
So far we only write a maximum of 4 dwords further into the batch and
it seems just going over the CS prefetch was enough.
Turns out writing more dwords can delay the writes and we start
prefetching stuff that hasn't landed in memory yet.
This fixes the issue by stalling the CS to ensure the writes have
landed before we go over the prefetch.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 796fccce63 ("intel/mi-builder: add framework for self modifying batches")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8525>
(cherry picked from commit d8154c4006)
We sometimes use anv_layout_to_aux_state() to compute the aux state of
an image during the resolve operations at the end of a render
(sub)pass.
If we're dealing with a multisampled image that is created without a
transfer usage, our internal code might trigger a resolve using the
transfer layout (see genX_cmd_buffer.c:cmd_buffer_end_subpass), for
which the image doesn't the usage bit. The current code tries to AND
the 2 usages which won't have any bit in common, thus skipping all
checks below.
v2: Add the transfer usages depending on attachment usage (Lionel)
v3: Limit to samples > 1 (Jason) && DEPTH_STENCIL_ATTACHMENT_BIT (Lionel)
v4: Add transfer usage at image creation (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 54b525caf0 ("anv: Rework anv_layout_to_aux_state")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4037
Reviewed-by: Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8307>
(cherry picked from commit d4b4d69d4d)
Add a check to vaDeriveImage to see if a non-interlaced buffer was
created successfully. Otherwise, return an error, since we won't be able
to derive an image from the interlaced buffer.
Prevents a null pointer dereference from occuring on some nVidia cards,
reported by Alexander Kapshuk.
v2: Check for PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE support (Ilia)
Fixes: fcb558321e ("frontends/va: Derive image from interlaced buffers")
Signed-off-by: Thong Thai <thong.thai@amd.com>
Tested-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8320>
(cherry picked from commit 4b208cc503)
The Android Vulkan loader needs this symbol, so the addition of the
linker script broke Vulkan for Android.
(For non-Android builds: I checked that having a non-existent symbol in
the linker script works ok and doesn't put the symbol in the library)
Fixes: 41bb6459d3 ("radv: restrict exported symbols with static llvm")
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8437>
(cherry picked from commit 4956f6d0bf)
Found a case where we mapped a range too many.
Per the comment the constraint is:
/* [first, last] is exactly the range of ranges that either overlap the
* new parent, or are adjacent to it. This corresponds to the bind ranges
* that may change.
*/
So that means that after the ++last we the ranges[last] should still
be adjacent. So we need to test the post-increment value to see whether
it is adjacent.
Failure case:
ranges:
0: 0 - ffff
1: 10000 - 1ffff
2: 20000 - 2ffff
3: 30000 - 3ffff
new range: 10000 - 1ffff
wrong first, last: 0,3
However range 3 clearly isn't adjacent at all.
Fixes: 715df30a4e "radv/amdgpu: Add winsys implementation of virtual buffers."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7953>
(cherry picked from commit 2b12e6931e)
Compute the number of components of the destination vector from the
bitsize when eg. a 16-bit vec2 vertex fetches is splitted. This is
because the dst will be a v1, so the p_create_vector should be created
from two v2b fro both sizes to match.
This prevents a regression from the next change which will split
typed vertex buffer loads on GFX6 and GFX10+.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8363>
(cherry picked from commit 68c2537062)
No shader-db or fossil-db changes on any Intel platform.
v2: Add a coding line to fix SCons build problems caused by the ±
character.
Fixes: 25bfba3335 ("nir/algebraic: Recognize open-coded copysign(1.0, a)")
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6358>
(cherry picked from commit 9771af5dde)
Conflicts:
src/compiler/nir/nir_opt_algebraic.py
I originally noticed that 3b30814791 ("nir/algebraic: Optimize 1-bit
Booleans") caused this pattern no longer be matched by incorrectly
replacing b@32 with b@1. Making that correct had no effect on
shader-db. When this pattern originally was added, it only affected 4
shaders, so it's not worth the effort to debug further.
This reverts commit f50400cc80.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6358>
(cherry picked from commit 314a40c902)
OpenGL GLSL, OpenGL ARB assembly shaders, and DX9 are pretty loose about
the behavior in the presence of NaNs. Many GPUs that implement these
specifications do not even have a representation of NaN. However,
OpenCL and Vulkan SPIR-V are not so lax. Both actually have some
required behavior in the presence of NaN, and, of the two, OpenCL is the
most strict.
For years we have implemented SPIR-V by using the same comparison
opcodes as we use for OpenGL GLSL and OpenGL assembly shaders. This has
repeatedly caused problems where an optimization that is valid in the
NaN-relaxed world is not valid in Vulkan or OpenCL. To fix this, set
the "exact" flag on comparisons instructions generated from SPIR-V.
This will block optimizations that may have different NaN behavior.
v2: Set the exact flag in the nir_builder, not in the vtn_builder.
v3: Add an assertion in vtn_handle_constant that the exact flag wasn't
set (because it's ignored). Rebase on 80163bbec3 ("nir/vtn: Support
OpOrdered and OpUnordered opcodes"). Mark the NIR generated for those
opcodes as exact as well.
v4: s/unused_exact/exact/ in a couple places, and assert that exact has
the expected value (true in one place, false in the other). Suggested
by Caio.
Closes: #3345
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Tested-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Fixes: 8513b12590 ("nir/opt_if: split ALU from Phi more aggressively")
This commit doesn't really fix anything in 8513b12590. However,
without 8513b12590, a regression is triggered in RADV on No Man's
Sky. I want to ensure that this change is only applied on top of
8513b12590, and Fixes: seems the safest way to do that.
No shader-db changes on any Intel platform. This only affects SPIR-V,
and we have no OpenGL SPIR-V shaders in shader-db.
124 shaders in Shadow of the Tomb Raider (Steam "native") were hurt by 1
spill and 1 fill each.
All Intel platforms had similar results. (Tiger Lake shown)
Instructions in all programs: 155668276 -> 155685764 (+0.0%)
SENDs in all programs: 6474570 -> 6474570 (+0.0%)
Loops in all programs: 35271 -> 35271 (+0.0%)
Cycles in all programs: 3198055373 -> 3198628031 (+0.0%)
Spills in all programs: 231522 -> 231646 (+0.1%)
Fills in all programs: 347571 -> 347695 (+0.0%)
Vega
Totals:
SGPRs: 20955712 -> 20956756 (+0.00%); split: -0.02%, +0.03%
VGPRs: 13476920 -> 13473132 (-0.03%); split: -0.07%, +0.04%
CodeSize: 613371940 -> 613339348 (-0.01%); split: -0.06%, +0.05%
MaxWaves: 3111886 -> 3112481 (+0.02%); split: +0.02%, -0.00%
Instrs: 120723785 -> 120746991 (+0.02%); split: -0.04%, +0.06%
Cycles: 626658992 -> 626862708 (+0.03%); split: -0.05%, +0.08%
VMEM: 216330854 -> 216343196 (+0.01%); split: +0.04%, -0.04%
SMEM: 32079391 -> 32081972 (+0.01%); split: +0.05%, -0.04%
VClause: 2688784 -> 2688789 (+0.00%); split: -0.03%, +0.03%
SClause: 6554669 -> 6556251 (+0.02%); split: -0.01%, +0.03%
Copies: 5356667 -> 5353283 (-0.06%); split: -0.36%, +0.29%
Branches: 954466 -> 954716 (+0.03%); split: -0.01%, +0.04%
PreSGPRs: 9078300 -> 9081626 (+0.04%); split: -0.01%, +0.05%
PreVGPRs: 10972090 -> 10966576 (-0.05%); split: -0.06%, +0.01%
Totals from 48239 (12.08% of 399432) affected shaders:
SGPRs: 2713984 -> 2715028 (+0.04%); split: -0.16%, +0.19%
VGPRs: 1997804 -> 1994016 (-0.19%); split: -0.46%, +0.27%
CodeSize: 172094092 -> 172061500 (-0.02%); split: -0.21%, +0.19%
MaxWaves: 337327 -> 337922 (+0.18%); split: +0.20%, -0.02%
Instrs: 33053657 -> 33076863 (+0.07%); split: -0.15%, +0.22%
Cycles: 254961228 -> 255164944 (+0.08%); split: -0.12%, +0.20%
VMEM: 15165226 -> 15177568 (+0.08%); split: +0.59%, -0.51%
SMEM: 3304938 -> 3307519 (+0.08%); split: +0.49%, -0.41%
VClause: 766225 -> 766230 (+0.00%); split: -0.12%, +0.12%
SClause: 1332645 -> 1334227 (+0.12%); split: -0.04%, +0.16%
Copies: 2040651 -> 2037267 (-0.17%); split: -0.94%, +0.77%
Branches: 743668 -> 743918 (+0.03%); split: -0.01%, +0.05%
PreSGPRs: 1697667 -> 1700993 (+0.20%); split: -0.07%, +0.27%
PreVGPRs: 1718424 -> 1712910 (-0.32%); split: -0.39%, +0.07%
Polaris
Totals:
SGPRs: 21349172 -> 21354376 (+0.02%); split: -0.02%, +0.04%
VGPRs: 13690680 -> 13686920 (-0.03%); split: -0.07%, +0.04%
CodeSize: 613745824 -> 613704988 (-0.01%); split: -0.06%, +0.05%
MaxWaves: 2775012 -> 2775189 (+0.01%); split: +0.01%, -0.00%
Instrs: 120735079 -> 120756209 (+0.02%); split: -0.04%, +0.06%
Cycles: 627906100 -> 628076156 (+0.03%); split: -0.05%, +0.08%
VMEM: 216623065 -> 216641838 (+0.01%); split: +0.04%, -0.04%
SMEM: 32295618 -> 32299338 (+0.01%); split: +0.05%, -0.04%
VClause: 2711025 -> 2711141 (+0.00%); split: -0.03%, +0.04%
SClause: 6545185 -> 6546769 (+0.02%); split: -0.01%, +0.03%
Copies: 5387723 -> 5383249 (-0.08%); split: -0.37%, +0.29%
Branches: 953775 -> 953954 (+0.02%); split: -0.01%, +0.03%
PreSGPRs: 9148814 -> 9153211 (+0.05%); split: -0.01%, +0.06%
PreVGPRs: 11029429 -> 11023915 (-0.05%); split: -0.06%, +0.01%
Totals from 48239 (12.00% of 402052) affected shaders:
SGPRs: 2682056 -> 2687260 (+0.19%); split: -0.16%, +0.35%
VGPRs: 1994436 -> 1990676 (-0.19%); split: -0.46%, +0.27%
CodeSize: 170857060 -> 170816224 (-0.02%); split: -0.21%, +0.19%
MaxWaves: 295429 -> 295606 (+0.06%); split: +0.07%, -0.01%
Instrs: 32808802 -> 32829932 (+0.06%); split: -0.16%, +0.22%
Cycles: 254633252 -> 254803308 (+0.07%); split: -0.13%, +0.20%
VMEM: 14897934 -> 14916707 (+0.13%); split: +0.65%, -0.52%
SMEM: 3289726 -> 3293446 (+0.11%); split: +0.53%, -0.42%
VClause: 775318 -> 775434 (+0.01%); split: -0.11%, +0.13%
SClause: 1304867 -> 1306451 (+0.12%); split: -0.04%, +0.16%
Copies: 2026334 -> 2021860 (-0.22%); split: -0.99%, +0.77%
Branches: 742554 -> 742733 (+0.02%); split: -0.02%, +0.04%
PreSGPRs: 1690887 -> 1695284 (+0.26%); split: -0.07%, +0.33%
PreVGPRs: 1717709 -> 1712195 (-0.32%); split: -0.40%, +0.07%
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6358>
(cherry picked from commit 010e663cc3)
The resulting point-coord origin not only depends on whether
the draw buffer is flipped but also on GL_POINT_SPRITE_COORD_ORIGIN
state. Which makes its transform differ from a transform of wpos.
On freedreno fixes:
gl-3.2-pointsprite-origin
gl-3.2-pointsprite-origin -fbo
Fixes: d934d320 "nir: Add flipping of gl_PointCoord.y in nir_lower_wpos_ytransform."
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8200>
(cherry picked from commit 33fd9e5d8a)
In case the stencil is modified, it is also enabled. That was the
behavior of the original code, which was also the correct behavior,
so reinstate the behavior.
Fixes dEQP-GLES2.functional.fragment_ops.depth_stencil.* on STM32MP1 GC400T.
Fixes: b29fe26d43 ("etnaviv: rework ZSA into a derived state")
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8174>
(cherry picked from commit 33a6c01e12)
nir_addition_might_overflow() expects the parent instruction to be
an alu instr but it might be a phi instr. Fix it by assuming that
the addition might overflow.
This fixes compiler crashes with Horizon Zero Dawn.
No fossils-db changes.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8268>
(cherry picked from commit 0b503d8de9)
If you deleted your old GS and created a new one, then it would
occasionally skip binding the new GS because the token pointers were
equal. Clear the current token pointer in the machine when we're deleting
its token.
Cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8277>
(cherry picked from commit 969f50ddcf)
the previous commit handling this forced geometry shader usage for all cases,
but this is not ideal, so instead there are now fragment shader variants for
both depth==1 and depth!=1, corresponding to the existence of gl_Layer in the
shader
Fixes: 614c77772a ("st/pbo: fix pbo uploads without PIPE_CAP_TGSI_VS_LAYER_VIEWPORT")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8089>
(cherry picked from commit 36097fc7ef)
On some devices, window resizing results in flashes of blue- and
orange-tinted versions of the current frame until resizing is
finished.
This fix ensures that the emubgra tweak used for GLES virgl hosts
has its enabled state flag set properly during resize events.
v2: removed unrelated whitespace change
Fixes: 6f68cacf61 ("virgl: Always enable emulated BGRA and swizzling unless specifically told not to")
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8119>
(cherry picked from commit accc222217)
We may have to make a new ATI_fs variant when the texture target changes.
Fixes a regression on piglit ati_fragment_shader-render-textargets on
llvmpipe after the switch to NIR ATI_fragment_shader.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8118>
(cherry picked from commit f0606cafe8)
We apparently don't have anything else making sure that it's flushed in
between use as a render target and use as a texture source, so bypass-mode
depth texture sampling could get stale data.
Fixes consistent (as far as I could see) failures in FD_MESA_DEBUG=nogmem
on:
dEQP-GLES31.functional.texture.multisample.samples_*.use_texture_depth_2d
dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_draw
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8146>
(cherry picked from commit e4cdbeab81)
SPIR-V modules can have multiple shaders (including of the same
stage), but the global variables are all declared for the whole
module. This can result in variables with same Binding but
incompatible types, so those need to be removed before we use.
Previously, a similar issue but with a narrower scope was fixed by
6775665e5e ("spirv: Eliminate dead input/output variables after
translation.").
This patch depends on the previous patch that prevents variables used
only in pointer initializers to be considered dead.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3686
Fixes: 3a266a18 ("nir/spirv: Add support for declaring variables")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8133>
(cherry picked from commit c4c9c780b1)
Between the creation of a shader (from GLSL or SPIRV frontends) and
nir_lower_variable_initializers is called, variables may refer to
other variables for initialization. Those referred variables need to
be kept alive, so consider that in the pass.
Fixes: 7acc81056f ("compiler/nir: Add support for variable initialization from a pointer")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8133>
(cherry picked from commit acce4ce04e)
If the only user is a trivial bcsel which in a second step
can be turned into a phi, this conversion is also worth it
even if the previous result is not undefined or constant.
Allows for some more loop unrolling or saves a few instructions.
Totals from 62 (0.04% of 139391) affected shaders (NAVI10):
SGPRs: 4976 -> 4992 (+0.32%)
VGPRs: 4408 -> 4472 (+1.45%); split: -0.45%, +1.91%
CodeSize: 453632 -> 464000 (+2.29%); split: -0.32%, +2.60%
MaxWaves: 527 -> 511 (-3.04%); split: +0.38%, -3.42%
Instrs: 84940 -> 86681 (+2.05%); split: -0.36%, +2.41%
Cycles: 11946844 -> 11783708 (-1.37%); split: -1.40%, +0.04%
VMEM: 9403 -> 10357 (+10.15%); split: +11.59%, -1.45%
SMEM: 3003 -> 3025 (+0.73%); split: +1.07%, -0.33%
VClause: 1756 -> 1997 (+13.72%); split: -0.11%, +13.84%
SClause: 2914 -> 2915 (+0.03%); split: -0.10%, +0.14%
Copies: 6426 -> 6768 (+5.32%); split: -4.14%, +9.46%
Branches: 2105 -> 2102 (-0.14%); split: -1.66%, +1.52%
PreSGPRs: 2921 -> 2909 (-0.41%); split: -0.55%, +0.14%
PreVGPRs: 4151 -> 4179 (+0.67%); split: -0.24%, +0.92%
cc: mesa-stable
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8123>
(cherry picked from commit 8513b12590)
Since we're requiring the branch condition to be in WQM, we have to ensure
that the block is in the worklist.
Fixes Trials Fusion hang at 4K and High settings.
fossil-db (Sienna):
Totals from 216 (0.15% of 139391) affected shaders:
SGPRs: 13392 -> 13360 (-0.24%)
CodeSize: 1321184 -> 1318592 (-0.20%)
Instrs: 255310 -> 254662 (-0.25%)
Cycles: 2178360 -> 2174652 (-0.17%)
Affected fossils in fossil-db are dirt4, nier and youngblood.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3863
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8145>
(cherry picked from commit 661922f6ac)
According to the spec:
"pCounterBuffers is an optional array of buffer handles [...]
If pCounterBuffers is NULL, then transform feedback will start
capturing vertex data to byte offset zero in all bound transform
feedback buffers."
"If counterBufferCount is not 0, and pCounterBuffers is not NULL,
pCounterBuffers must be a valid pointer to an array [...]"
So counterBufferCount could be non-zero with pCounterBuffers
being NULL.
Fixes crash in RenderDoc when inspecting draw call with tesselation
or geometry shader present.
Fixes: 98b0d900 "turnip: rework streamout state and add missing counter buffer read/writes"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8140>
(cherry picked from commit b34bc3db67)
According to the spec:
"pTessellationState [...] is ignored if the pipeline does not
include a tessellation control shader stage and tessellation
evaluation shader stage."
Fixes crash in RenderDoc when inspecting draw call with
geometry shader but without tesselation shaders.
Fixes: eefdca2e "turnip: Parse tess state and support PATCH primtype"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8140>
(cherry picked from commit 6aec3c9a23)
I thought this was a bug in CTS but the Vulkan spec says:
"VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT specifies write access
to a color, resolve, or depth/stencil resolve attachment during
a render pass or via certain subpass load and store operations."
So, VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT is used to synchronize
depth/stencil resolve attachments. Yes, it's counterintuitive.
This can't actually be fixed properly for now because RADV performs
the end subpass barrier *before* resolve attachments instead of after.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8138>
(cherry picked from commit 7880faccc5)
In case one operand was renamed and another operand came
from an incomplete phi, it could happen, that the original
name was not restored.
This has no impact on the code, but ensures correct SSA
is maintained during RA.
Cc: mesa-stable
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8109>
(cherry picked from commit b50d3e5760)
EGL_EXT_protected_surface introduces EGL_PROTECTED_CONTENT_EXT,
while EGL_EXT_protected_content is about protected context.
When I implemented EGL_EXT_protected_surface I mixed up the 2
names, so this commit fixes it.
Fixes: bd182777c8 ("egl: implement EGL_EXT_protected_surface support")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8122>
(cherry picked from commit 663e06faa6)
The problem was that the shader constants were based on the framebuffer
sample count and ignored the multisample enable state and the line/polygon
smoothing state, which uses MSAA rasterization that only sets SampleMaskIn
to get the coverage for alpha-blended smoothing (the PS epilog computes
the alpha channel from SampleMaskIn and blending generates the AA results).
- This is a complete rework that adds a new state for NGG cull constants.
- It fixes the same thing for the prim discard compute shader.
- It documents how VS_STATE.SMALL_PRIM_PRECISION is encoded.
It fixes blue corruption in Unigine Heaven with MSAA and Medium details
or better.
Fixes: 7648060dc0 - radeonsi: enable NGG culling by default on gfx10.3 dGPUs
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8134>
The small DCE of the spiller only removes the original instructions
of rematerialized variables in case they are unused. If a variable
has been renamed, it cannot match any original instruction anymore.
Thus, the lookup is then unnecessary and can be omitted.
No fossil-db changes.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8055>
(cherry picked from commit ef4101d6d7)
the code here tries to be too smart and only use a geometry shader if there's
actually multiple layers being uploaded, but the fragment shader also unconditionally
reads gl_Layer as long as the pipe cap for gs is set, which means that
in the case when the gs is dynamically disabled due to uploading a
single-layer surface, the fs has no input to read for gl_Layer and everything breaks
always using a gs isn't ideal, but it's considerably more work to manage multiple
fs variants based on layer usage
Fixes: c99f2fe70e ("st/mesa: implement PBO upload for multiple layers")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8067>
(cherry picked from commit 614c77772a)
With the block's end_ip accidentally being the ip of the next instruction,
contrary to the comment, you would end up doing end-of-block freeing early
and have the value missing when it came time to emit the next instruction.
Just expand the ips to have separate ones for start and end of block --
while it means that nir_instr->index is no longer incremented by 1 per
instruction, it makes sense for use in liveness because a backend is
likely to need to do other things at block boundaries (like emit the if
statement's code), and having an ip to identify that stuff is useful.
Fixes: a206b58157 ("nir: Add a block start/end ip to live instr index metadata.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7658>
(cherry picked from commit d3d28f6c2d)
Using more blend targets than specified by maxFragmentDualSrcAttachments
is invalid per the Vulkan spec.
I'm usually not a fan to workaround game bugs inside the driver but
it's really easy for us to ignore MRT1+ in the driver and that
prevents wrong behaviour.
Cc: 20.2, 20.3
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit bc7f442d8e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8014>
We need to pick 1u vs 1.0f based on the type of the texture, just like for
normal samples. Move the decision up to the create_sampler_view, and use
that value from both sampler paths.
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8012>
(cherry picked from commit 4ba884b814)
Commit 64d6f56ad2 ("panfrost: Allocate syncobjs in panfrost_flush")
aimed at optimizing the fencing logic but it looks it also broke the
fence-based synchronization in subtle ways.
Indeed, now that the fence only waits on a single syncobj, we're not
guaranteed that all jobs queued in panfrost_flush_all_batches() will
be done when the fence is signaled, because jobs at the top level
(those stored in the batches hashmap) have not inter-dependencies.
Commit 9e397956b0 ("panfrost: signal syncobj if nothing is going to
be flushed") made this even more apparent by signaling the fence right
away if nothing was left to be drawn in the current context, thus
ignoring any of the batches left to flushed in the ->batches map.
If we want to keep relying the existing kernel APIs there's clearly no
ideal solution here. We can either go back to the original fencing
mechanism where each fence contained an array of syncobjs to be tested
or serialize jobs that have no explicit dependencies so we know the last
submitted job will also be the last one to return. The orginal approach
has proven to add quite a significant overhead (caused by the amount of
ioctls and the time spent in kernel space to gather dma fences attached
to those syncobjs and test them). So let's go for the simple solution
where we have a single syncobj bound to the context which we update to
point to the last job out_sync every time we submit a top-level job.
This approach implies reworking the way we create fences since we
need to capture the syncobj state at the time the fence is created.
Unfortunately, there's not SYNCOBJ_CLONE ioctl, which forces us to
export/create/import a fence so we have a new object that's not
subject to changes done to the context syncobj.
If we want to further optimize the logic, we should probably explore
some of those options:
1/ Adding array based SYNCOBJ ioctls (SYNCOBJ_{CREATE,DESTROY,CLONE}_ARRAY)
so we can mitigate the cost of ioctls when we need to manipulate
arrays of syncobjs
2/ Support synchronization jobs. That is, jobs that have a NULL job chain
but an array of sync_in and a sync_out to allow creating
synchronization points
3/ Add syncobj aggregators so we only have to wait on one syncobj from
userspace. The syncobj aggregator would wait for all sub syncobjs to
be signaled before signaling the top-level one.
Fixes: 64d6f56ad2 ("panfrost: Allocate syncobjs in panfrost_flush")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7831>
(cherry picked from commit 29f938a0ec)
among all Android gen rules '::' was used only here to declare dependencies;
mesa development and stable branch are worth receiving the fix
Fixes the following building errors with Android 7:
obj/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/gl_spirv.P:184: *** target file
gen/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/vtn_generator_ids.h' has both : and :: entries. Stop.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Fixes: 1070bba19e ("android: fix SPIR-V -> NIR build")
Reported-by: youling257 <youling257@gmail.com>
(cherry picked from commit 185df8ef07)
In the Chrome WebGL Aquarium stress test, 20 instances of Chrome will run
Aquarium simultaneously over 20+ hours. That causes Chrome crash.
During the stress, glBeginQueryIndexed is called frequently.
1.Each query will only use 32 bytes from query_buffer_uploader. After the offset
exceed 4096, it will alloc new buffer for query_buffer_uploader->buffer
and release the old buffer.
2.But iris_begin_query will call u_upload_alloc when the offset changed, and it
will increase the query_buffer_uploader->buffer->reference.count every time
when it called u_upload_alloc.
3.So when u_upload_release_buffer try to release the resource of
query_buffer_uploader->buffer, its reference.count is
already equal to 129. pipe_reference_described will only decrease its reference
count to 128.So it never called old_dst->screen->resource_destroy.
4.The old resouce bo will never be freeed. And chrome will called mmap every time
when it alloc new resource bo.
5. Chrome process map too many vmas in its process. Its map count exceed the
sysctl_max_map_count which is 65530 defined in kernel.
6. When iris_begin_query want to alloc new resource bo, it will meet NULL pointer
because mmap return failed. Finally chrome crashed when it access this NULL resource
bo.
The fix is decrease the reference count in iris_destroy_query.
Patch is verified by chrome webgl Aquarium test case for more than 72 hours.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Yang Shi <yang.a.shi@intel.com>
Reviewed-by: Alex Zuo <alex.zuo@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7890>
(cherry picked from commit 3aaac40b12)
avoids errors seen when building on OpenBSD/amd64
../src/amd/compiler/aco_instruction_selection.cpp:1677:62: error: ambiguous conversion for functional-style cast from 'unsigned long' to 'aco::Operand'
bld.vop3(aco_opcode::v_mul_f64, Definition(dst), Operand(0x3FF0000000000000lu), tmp);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
glibc uses unsigned long for uint64_t on LP64 archs and unsigned long long for
uint64_t on ILP32 archs. On OpenBSD unsigned long long is used for uint64_t
on all archs.
The Operand constructors are uint8_t uint16_t uint32_t uint64_t
use UINT64_C so lu or llu suffix will be used as needed.
Fixes: df645fa369 ("aco: implement VK_KHR_shader_float_controls")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7944>
(cherry picked from commit ebfb9e1817)
PIPE_MAX_CONSTANT_BUFFERS is 32, however many Vulkan implementations
has maxPerStageDescriptorUniformBuffers that exceeds it, for example:
radv 8388606,
anv 64
nvidia 1048580 for RTX 2000 and up.
and, together with the current zink logic, the returned value
will exceed the maximum allowed value for the cap.
This causes cso_destroy_context to pass big values back to zink
(via zink_set_constant_buffer), resulting in access beyond end of
allocated buffer for all UBOs.
Cap the cap to PIPE_MAX_CONSTANT_BUFFERS (32), not INT_MAX.
Add an assert to verify future drivers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7976>
(cherry picked from commit e2b4247e40)
This looks like a typo. Packed vulkan formats should always map to the
inverse order of the corresponding gallium notation. Besides, it makes
no sense that unsigned and signed formats have different ordering.
Fixes: cdfb1d925f ("zink: add last few format maps for ARB_vertex_type_2_10_10_10_rev")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7964>
(cherry picked from commit 8bb4a76add)
There's no good reason why drivers that doesn't grok geometry,
tesselation or compute shaders needs to deal with them.
This fixes a crash on a lot of Piglit tests for Zink.
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7971>
(cherry picked from commit 3abac03d49)
Fixes a use-after-free of the state on the next iteration when it was
probably just destroyed.
Fixes: 6de01faac5 ("freedreno/a6xx: invalidate tex state cache entries on rebind")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
(cherry picked from commit d3c67d7e7e)
Conflicts:
src/gallium/drivers/freedreno/a6xx/fd6_texture.c
This is only required for the DRI-path. For the swrast code-path, we
don't need this.
We also don't need to explicitly test for it in the DRI-path, because we
test for KHR_external_memory_fd, which depends on KHR_external_memory. So
no implementation will expose the former without the latter.
Fixes: f1432fd3e2 ("zink: generate extension infrastructure using a python script")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7882>
(cherry picked from commit 59a6705cce)
If you did:
si_pm4_set_reg(pm4, reg, val0);
si_pm4_cmd_add(pm4, val1);
si_pm4 set_reg(pm4, reg + 4, val1);
it wrote val0 to reg, val1 to reg + 4, and val2 to reg + 8.
This fixes it by clearing last_opcode in si_pm4_cmd_add, so that
si_pm4_set_reg doesn't try to combine set_reg calls across si_pm4_cmd_add.
Fixes: da78d50bc8 - radeonsi: make si_pm4_cmd_begin/end static and simplify all usages
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
(cherry picked from commit 0d4f1dcd15)
In commit 00b28a50b2, Marek extended
a number of optimizations that had been 32-bit specific to work on
other bit-sizes.
Most optimizations preserve the data type across the transformation.
In other words, an optimization which generates e.g. fp64 operations
only does so when the source expression also contains fp64 operations.
These transformations are fine with respect to lowering, because we
will lower away all expressions that would trigger the search portion
of the expression, and so we'd never apply those rules.
However, a few of the rules create new operations that run afoul of
lowering passes. For example,
('bcsel', a, 1.0, 0.0) => ('b2f', a)
where the result is a double would simply be a selection between two
different 64-bit constants. The replacement expression, on the other
hand, involves a nir_op_b2f64 ALU operation. If we're run after
nir_lower_doubles, then it may not be legal to generate such an
expression anymore (at least without running lowering again, which we
don't do today).
Regressions due to this are blocking the 20.3 release, so for now, we
take the easy route and simply disallow those few rules when doing full
softfp64 lowering, which fixes the immediate problem. But it doesn't
solve the long-term problem in an extensible manner.
In the future, we may want to add a `lowered_alu_ops` bitfield to the
NIR shader, and as lowering passes are run, mark them as taboo. Then,
we could have each algebraic transformation track which operations it
creates in the replacement expression. With both of those in place,
nir_replace_instr could compare the transformation's list of ALU ops
against `lowered_alu_ops` and implicitly skip rules that generate
forbidden ALU operations.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3504
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7841>
(cherry picked from commit 531843cf2e)
This workaround fixes a hang while loading a renderdoc trace for me.
Since the workload does 1 mip per cmdbuffer it is quite hard to confirm
what exactly the conditions for the hang are but this is the most
restrictive set I found and it corresponds to a workaround in AMDVLK as
well.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7210>
(cherry picked from commit 4cce4d22a7)
Quoting the spec :
"When a pool is destroyed, all descriptor sets allocated from the
pool are implicitly freed and become invalid. Descriptor sets
allocated from a given pool do not need to be freed before
destroying that descriptor pool."
This implies we might leak nodes allocated in the vma object.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0a6d2593b8 ("anv: Allocate descriptor buffers from the BO cache")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7796>
(cherry picked from commit 5d55ca9c30)
It fixes the following valgrind issue:
==141996== Invalid read of size 4
==141996== at 0x61F8806: gl_nir_link_uniforms (gl_nir_link_uniforms.c:1788)
==141996== by 0x60F17AA: gl_nir_link_glsl (gl_nir_linker.c:672)
==141996== by 0x5C1AEDF: st_link_nir (st_glsl_to_nir.cpp:739)
==141996== by 0x5C15574: st_link_shader (st_glsl_to_ir.cpp:172)
==141996== by 0x5C673B0: _mesa_glsl_link_shader (ir_to_mesa.cpp:3117)
==141996== by 0x5E7B61C: link_program (shaderapi.c:1311)
==141996== by 0x5E7B61C: link_program_error (shaderapi.c:1419)
==141996== by 0x5E7CF8A: _mesa_LinkProgram (shaderapi.c:1911)
==141996== by 0x4923D13: stub_glLinkProgram (piglit-dispatch-gen.c:33956)
==141996== by 0x1142C0: link_and_use_shaders (shader_runner.c:1636)
==141996== by 0x1205A6: init_test (shader_runner.c:5347)
==141996== by 0x121555: piglit_init (shader_runner.c:5725)
==141996== by 0x4991C84: run_test (piglit_fbo_framework.c:50)
It can be reproduced on `iris` using the following piglit test:
instance-matching-shader-storage-blocks-align-qualifier-mismatch.shader_test
Closes: #3818
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 47c35823 ("glsl: fix up location setting for variables pointing to a UBO's base")
Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7376>
(cherry picked from commit a941618a1f)
with a sequence like this:
glClear(STENCIL)
glBeginTransformFeedback()
...
glEndTransformFeedback()
glClear(STENCIL)
The second clear sometimes may produce an unexpected result.
Calling si_flush_gfx_cs() when doing ngg -> legacy transition seems to be a
valid workaround (both for the synthetic reproducer and the real Blender bug).
Using flush flags or events (BOTTOM_OF_PIPE_TS, RESET_TO_LOWEST_VGT) didn't help.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2941
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7750>
(cherry picked from commit 0b3bd7c516)
Vulkan can't scale while resolving using vkCmdResolveImage. For this we
need to use util_blitter.
The reason this wasn't a problem in the past, was that glBlitFramebuffer
always set pipe_blit_info::render_condition_enable, and we always used
that to bail out to util_blitter. When the latter changed, this broke.
Fixes: 19906022e2 ("zink: more accurately track supported blits")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7745>
(cherry picked from commit c0286fc09b)
Caused to return early wrongly on CmdPushConstants with some tests
using several calls to that method. As we are here we are also
replacing the (void *) casting at the memcpy below.
Fixes: e1c8041cde ("v3dv: try harder to skip emission of redundant state")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7718>
(cherry picked from commit ce5c23eb00)
strstr returns a pointer to the needle sub-string within the haystack
string if the latter contains the former, or NULL otherwise. So this
essentially always set info->is_pro_graphics = true, since probably no
marketing name ever contains all of these sub-strings.
Fixes: b635dff256 "ac: fix detection of Pro graphics"
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7675>
(cherry picked from commit 13b2beb415)
Icelake's sampler message header introduces a field in m0.3 bit 0
which controls whether the sampler state pointer should be relative
to bindless sampler state base address or dynamic state base address.
g0.3 bit 0 is part of the per-thread scratch space field. On older
hardware, we were able to copy that along because the sampler ignored
bits 4:0. Now, however, we need to mask them out.
Fixes various textureGatherOffsets piglit tests when forcing the FS
to run with 2048 bytes of per-thread scratch space (which is a
per-thread scratch space encoding of 1, meaning bit 0 will be set).
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6735>
(cherry picked from commit 31290f9806)
In bison's commit 72c9fa4510eb (skeletons: use "end of file" instead of
"$end") in bison-3.6, '$end' was changed to 'end of file' in error
messages. Since our glcpp test cases contain the expected output text,
they rely on the particular messages printed by bison. The test case
084-unbalanced-parentheses fails when Mesa is built with bison-3.6 due
to this change.
To allow the test to pass on all supported versions of bison, we:
1. Change '$end' -> 'end of file' in the .expected file, and
2. Normalize the error generated by the test case with the same
replacement
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3181
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7659>
(cherry picked from commit df29d0a111)
The code did not return error when VK_IMAGE_CREATE_DISJOINT_BIT was
incompatible with the other input params.
If the Vulkan spec forbids a set of input params for vkCreateImage,
but permits them for vkGetPhysicalDeviceImageFormatProperties2,
then vkGetPhysicalDeviceImageFormatProperties2 must reject those input
params with failure.
- v2: Clearer commit message.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 51a19c83b0)
It's supposed to be ralloced -- there's not even a shader variant destroy
function for freeing, just ralloc_free() on the ir3_shader_variant or the
parent ir3_shader when you're done!
Fixes: f97acb4bb4 ("freedreno/ir3: disk-cache support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5810>
(cherry picked from commit 433841d9eb)
Missing a copy of the pipe_sampler_state into the etna_sampler_state object
lead to the texture_use_int_filter() to always see a max_anisotropy of 0, so
the INT filter wasn't disabled when necessary. Also state emission should
never change the state objects, as this might also lead to stale information
being kept around the in the state object.
Fixes: 89a41dae77 (etnaviv: do not use int filter when
anisotropic filtering is used)
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7638>
(cherry picked from commit b479a1f03c)
Screen is shared among contexts, other context might be already using
vtbl while another initializes it again.
==45872== Possible data race during write of size 8 at 0x5DDAE78 by thread #549
==45872== Locks held: 1, at address 0x5D1B6F8
==45872== at 0x6D66D91: gen9_init_state (iris_state.c:7816)
==45872== by 0x6BA0A31: iris_create_context (iris_context.c:342)
==45872== by 0x621F390: st_api_create_context (st_manager.c:917)
==45872== by 0x620E6F9: dri_create_context (dri_context.c:163)
==45872== by 0x6A40DB1: driCreateContextAttribs (dri_util.c:480)
==45872== by 0x540B963: dri2_create_context (egl_dri2.c:1583)
==45872== by 0x53FB84E: eglCreateContext (eglapi.c:821)
==45872==
==45872== This conflicts with a previous read of size 8 by thread #544
==45872== Locks held: 1, at address 0x5F6E0E0
==45872== at 0x6CB779E: blorp_alloc_binding_table (iris_blorp.c:167)
==45872== by 0x6CAEF70: blorp_emit_surface_states (blorp_genX_exec.h:1540)
==45872== by 0x6CB67F9: blorp_exec (blorp_genX_exec.h:2016)
==45872== by 0x6CB7AFE: iris_blorp_exec (iris_blorp.c:307)
==45872== by 0x70F5916: try_blorp_blit (blorp_blit.c:2145)
==45872== by 0x70F5FCA: do_blorp_blit (blorp_blit.c:2273)
==45872== by 0x70F778F: blorp_copy (blorp_blit.c:2803)
==45872== by 0x6BB9EB6: iris_copy_region (iris_blit.c:725)
v2: move as genX(init_screen_state) (Lionel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7544>
(cherry picked from commit 460287adca)
All other functions calling _eglLookupImage hold the display lock.
==16659== Possible data race during write of size 8 at 0x5D1BCF0 by thread #2668
==16659== Locks held: 1, at address 0x5D1B6F8
==16659== at 0x5405DDF: _eglLinkResource (egldisplay.c:454)
==16659== by 0x53F9189: _eglLinkImage (eglimage.h:138)
==16659== by 0x53FE2CA: _eglCreateImageCommon (eglapi.c:1740)
==16659== by 0x53FE39A: eglCreateImageKHR (eglapi.c:1751)
==16659==
==16659== This conflicts with a previous read of size 8 by thread #2664
==16659== Locks held: 1, at address 0x5308D00
==16659== at 0x5405C06: _eglCheckResource (egldisplay.c:387)
==16659== by 0x5408C92: _eglLookupImage (eglimage.h:162)
==16659== by 0x5409E96: dri2_lookup_egl_image (egl_dri2.c:688)
==16659== by 0x6210AAF: dri2_lookup_egl_image (dri_helpers.c:250)
==16659== by 0x6212843: dri_get_egl_image (dri_screen.c:470)
==16659== by 0x625F7CC: st_get_egl_image (st_cb_eglimage.c:152)
==16659== by 0x625FE7D: st_egl_image_target_texture_2d (st_cb_eglimage.c:354)
==16659== by 0x6501C05: egl_image_target_texture (teximage.c:3446)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7544>
(cherry picked from commit 959c2d1edb)
OpenGL 3.0 spec, section 4.2.3 "Clearing the Buffers":
depth and stencil are the values to clear the depth and stencil
buffers to, respectively. Clamping and type conversion for
fixed-point depth buffers are performed in the same fashion as for
ClearDepth.
Enables iris to pass the clearbuffer-depth-stencil piglit test.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7410>
(cherry picked from commit 2e713313a2)
OpenGL 3.0 spec, section 4.2.3 "Clearing the Buffers":
If buffer is DEPTH, drawbuffer must be zero, and value points to the
single depth value to clear the depth buffer to. Clamping and type
conversion for fixed-point depth buffers are performed in the same
fashion as for ClearDepth.
Enables iris to pass the clearbuffer-depth piglit test.
v2. Add spec citation. (Eric Anholt)
v3. Don't clamp floating point formats. (Eric Anholt)
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7410>
(cherry picked from commit 1bf539b3a2)
The recent change to install kernel modules for AMD included a sed job to
disable kernel modules in the defconfig. This somehow broke booting on
a307, except the commit failed to bump the arm64_test tag so it wasn't
noticed until the next uprev. (I didn't notice when landing the next
change to that container to add the deqp runner, because I didn't get a
git conflict on rebasing my tag bump so I didn't bump the tag again to
pull in the kernel changes and catch the fail).
I've spent a while trying to debug what's happened (including what
*should* be a replication of the kernel build on my local db410c) and come
up empty. Just punt and disable the AMD kernel module changes on
baremetal to fix it. Bump every container using lava_build.sh to make
sure we don't screw anything up with the script changes.
Fixes: 60c5729d16 ("ci: Distribute ADMGPU driver to LAVA as a module")
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
(cherry picked from commit bf576b449e)
dEQP-VK.pipeline.blend.dual_source.format.r16g16b16a16_snorm.states.color_1msc_1ms1a_add_alpha_1mdc_1msa_sub-color_dc_1ms1c_rsub_alpha_z_1mdc_sub-color_ca_1ms1c_min_alpha_sas_ca_rsub-color_1ms1c_s1c_add_alpha_z_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8_snorm.states.color_z_sc_add_alpha_1ms1c_sa_min-color_dc_1mca_add_alpha_z_1mca_max-color_1ms1c_sa_max_alpha_1mcc_sc_sub-color_s1c_1mda_add_alpha_s1c_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8b8a8_snorm.states.color_1msc_1ms1a_add_alpha_1mdc_1msa_sub-color_dc_1ms1c_rsub_alpha_z_1mdc_sub-color_ca_1ms1c_min_alpha_sas_ca_rsub-color_1ms1c_s1c_add_alpha_z_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8b8a8_snorm.states.color_z_sc_add_alpha_1ms1c_sa_min-color_dc_1mca_add_alpha_z_1mca_max-color_1ms1c_sa_max_alpha_1mcc_sc_sub-color_s1c_1mda_add_alpha_s1c_1mda_add,Fail
dEQP-VK.pipeline.blend.format.r16g16b16a16_snorm.states.color_ca_1mca_rsub_alpha_1mda_z_sub-color_sc_sc_add_alpha_1mca_sa_max-color_sa_1msa_min_alpha_1msc_sa_sub-color_dc_sc_add_alpha_1mdc_1mca_add,Fail
dEQP-VK.pipeline.blend.format.r8g8b8a8_snorm.states.color_ca_1mca_rsub_alpha_1mda_z_sub-color_sc_sc_add_alpha_1mca_sa_max-color_sa_1msa_min_alpha_1msc_sa_sub-color_dc_sc_add_alpha_1mdc_1mca_add,Fail
All fail due to the 1 - mdc or 1 - mca alpha channel in the last quadrant.
Cc: 20.3 <mesa-stable>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7499>
(cherry picked from commit 01c4bac36e)
If we have cbufs but they are all empty, default
to returning the fb->samples.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.1_4_unused
on lavapipe
v2:
drop unneeded chunk (Roland)
Cc: 20.3 <mesa-stable>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7499>
(cherry picked from commit 4b1d23b243)
This implementation was broken and should have just been the same as the
hash_table_clear() one, which I copied over here. It was setting all
formerly-present entries to deleted, yet also setting deleted_entries to
0. This meant that all new searches or additions after clearing would
have to reprobe the whole table until a rehash happened, and that rehash
would be delayed because we violated the deleted_entries invariant.
No statistically significant performance difference on softpipe
KHR-GL33.texture_swizzle.functional runtime (n=18)
Fixes: 5c075b0855 ("util/set: add a set_clear function")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7244>
(cherry picked from commit 2afdd94f86)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.