'X4.exe' is the executable. But there is also a script 'X4' that is used to
launch the game. This script is what steam uses.
This updates driconf to match that.
This also brings the executable in line with other configs for the game.
Fixes: 5532f13566 ("driconf: override vendor id for X4 Foundations on NVK")
Fixes: 8654a7727f ("driconf: set vk_zero_vram driconf for X4 Foundations")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34168>
(cherry picked from commit a87c9bc49e)
This optimization used to optimize the allocated space for descriptors
when immutable samplers are equal. Though, this was basically broken :
- descriptor copies were broken for combiner image sampler (or sampler)
with equal immutable samplers because 96 bytes were copied instead of
64 bytes (cf. the linked ticket). This could be fixed but it's not
worth it.
- the value returned by vkGetDescriptorLayoutSupport() was broken, it
should have been 96 with no immutable samplers (or when they aren't
equal)
This optimization was also not applied for descriptor buffers which is
the default for vkd3d-proton and Zink. DXVK doesn't use db but it
doesn't use immutable samplers, so basically only native vulkan games
would be concerned.
Note that immutable samplers would still be inlined in shaders if no
indirect access which should be 99.9% of the usecase.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11165
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34928>
(cherry picked from commit 69ff204422)
The hardware requires a power of two bpe. To do that, the driver
needs to adjust the pitch/offset/extent based on a texel scale factor
which only applies to 96-bits formats.
This fixes new VKCTS coverage.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34927>
(cherry picked from commit 4b73d7e817)
The width/height fields in the plane descriptors for v10 are missing
their minus(1) modifiers.
This change adds the missing modifiers, which implies also setting
default values to 1 due to how the Two-Plane YUV Overlay interacts with
the plane descriptors.
Fixes: 486c341769 ("panfrost: Add architecture description XML for v10")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
(cherry picked from commit 2542857259)
Right now llvmpipe only successfully supports single-plane formats,
limiting the number of supported YCbCr formats to a relatively small
number.
The implicit support for R8G8_R8B8 style subsampled RGB formats
causes the most common ones, YUYV and its variants, to chain up
to to lp_build_fetch_subsampled_rgba_aos() when importing (u)dmabufs
with EXT_image_dma_buf_import.
This code path currently has at least the following issues:
1. It doesn't support the YVYU/PIPE_FORMAT_R8B8_R8G8_UNORM and
VYUY/PIPE_FORMAT_B8R8_G8R8_UNORM, resulting in asserts/crashes.
2. The supported cases, YUYV and UYVY, end up with sub-optimal results
as they always return BT.601/narrow results, ignoring
EGL_YUV_COLOR_SPACE_HINT_EXT and EGL_SAMPLE_RANGE_HINT_EXT.
Stopping advertising support for those formats, as well as native support
for PIPE_FORMAT_YUYV and PIPE_FORMAT_UYVY, results in all four variants
taking fallback paths which happen to be much better supported.
An additional effect is that YUYV and UYVY are correctly advertised as
external only.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34775>
(cherry picked from commit 4051d4ef59)
intel_decoder_init() initializes intel_batch_decode_ctx so later
we can call decode functions but it depends on data stored in
brw/elk_isa_info but that was being allocated in stack
of intel_decoder_init() then when the decode functions were executed
it was accessing garbage at the brw/elk_isa_info memory.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ec2d20a70d ("intel/tools: Add helpers for decoder_init/disasm")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34776>
(cherry picked from commit 3e5a735d01)
Or current render target cache setting is to key on the binding table
index, meaning the HW associates a number in the range [0, 7] to a
RENDER_SURFACE_STATE description. If you want change the render target
0 between 2 draw calls, you need to insert a PIPE_CONTROL in between
the 2 draw calls with pb-stall + rt-flush in order to flush an writes
to a previous RENDER_SURFACE_STATE that has now becomed disassociated
with the [0, 7] number.
This PIPE_CONTROL taking care of the flush is dealt with in
cmd_buffer_maybe_flush_rt_writes(). This function diffs the current
BTI setup for render targets (first 0 to 7 BTIs) with what the next
fragment shader wants.
The issue here is we might have a render pass with 0 color attachments
and yet in 98cdb9349a we added one pointing to the render target 0,
but in the emit_binding_table() when we finally program the BTI, we
check the render pass color count and program a null surface state
instead of an actual surface state. And this leads to hangs because
the render target cache will end up with inconsistent state data.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 98cdb9349a ("anv: ensure null-rt bit in compiler isn't used when there is ds attachment")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12955
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34603>
(cherry picked from commit 63f633557f)
On a7xx, the max constlen for compute is increased to 512 vec4s or 8KB,
however the size of the LB was not increased beyond 40KB. A quick
calculation shows that 8KB of consts multiplied by 2 banks plus the
API maximum of 32KB shared memory would exceed 40KB. This means that
we can't always use a constlen of 512, and sometimes have to fall back
to 256 when a lot of shared memory is in use.
In the future, we can use similar calculations to figure out how much
"extra" shared memory is available for the backend to spill to, but we
currently don't support spilling to shared memory.
Fixes: 5879eaac18 ("ir3: Increase compute const size on a7xx")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34746>
(cherry picked from commit ea9d694a7b)
This fixes a compilation issue in Marvel Rivals where the legalization
logic and the encoding logic don't line up, which results in an
assertion failure on this instruction:
r17 = hfma2 r17.xx -r18.xx 0x3c003c00
The fix here is a little overly restrictive because it turns out we
actually do have modifiers for all 3 sources. Those modifiers will
be added in later commits.
Fixes: 567cae69c3 ("nak: Add 16-bits float operations")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34750>
(cherry picked from commit 1ff7135691)
fd_pipe_new2 can segfault when trying to set the is_64bit flag on new
pipes. This can happen when the current GPU is not be listed in the
fd_dev_recs table because it's not supported by mesa, but is supported by
the kernel.
Add a helper function to test if the current GPU is in the supported table,
and use it in fd_pipe_new2.
Signed-off-by: Loïc Minier <loic.minier@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33830>
(cherry picked from commit c36cd32345)
Since headless overrides create_mem, it needs to override finish_create
too. Fixes a segfault in nvk that was caused by us mixing
wsi_create_null_image_mem with wsi_finish_create_blit_context, which
would then call CmdCopyImageToBuffer with image->blit.buffer == NULL
Fixes a cts failure on nvk in:
dEQP-VK.image.swapchain_mutable.headless.2d.r8g8b8a8_unorm_b8g8r8a8_unorm_clear_copy_format_list
and several others
Fixes: 579578f10a ("vulkan/wsi/drm: Break create_prime_image in pieces")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34646>
(cherry picked from commit 60452e016e)
Xe2 changed the MOCS field in few instructions, those now have a field
for the MOCS index and other the encryption enable bit but ISL returns
the combination of both aka MEMORY_OBJECT_CONTROL_STATE.
To minimize changes I have added 2 macros to extract the values
from the value returned by isl.
From all the instructions changed Mesa only make use of two, so the
other instruction will be handled in the next patch.
Cc: mesa-stable
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34592>
(cherry picked from commit 161c412a82)
si_destroy_context needs to call context->set_debug_callback(...) to
avoid the debug logs to access the destroyed context.
Adding this change introduced a different problem: when an aux context
is destroyed from si_destroy_screen, parts of the screen have been
freed already: the shader_compiler_queue_*.
c467a87e06 ("radeonsi: Destroy queues before the aux contexts") moved
the util_queue_destroy calls above the context destruction, but with
the 59a3f38ff6 change, it's not needed anymore: si_destroy_context
will finish the screen shader queues before proceeding with releasing,
so use-after-free isn't possible.
Fixes: 59a3f38ff6 ("radeonsi: clear the debug callback on ctx destroy")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12035
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34574>
(cherry picked from commit 2a381bbc3c)
DRM_FORMAT_MOD_QCOM_COMPRESSED forces the image to be UBWC regardless
of what's better for perf, we should respect that.
The regression is seen in GTK4 when it tries to create tiny swapchain
images.
Fixes: fc50fb35b0
("tu,freedreno: Enable linear mipmap tail for UBWC images")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34628>
(cherry picked from commit 36f22cc951)
When doing the flushing, I forgot that because the staging buffer can be
used with different formats with different cpp, we need to make sure
that CCU is properly flushed and invalidated between each copy to the
staging buffer to prevent stale cache entries from creeping in, as the
CCU seems to rely on the cpp staying the same, even on a7xx which
dropped some of the other restrictions like using the same RT
index/layer. For "normal" user-visible copies this is done via
transitioning from UNDEFINED.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34611>
(cherry picked from commit ee10938bee)
We were forgetting to reset the map count to 0 in case of dyn_bufs in
create_copy_table.
This was causing invalid copy entries to be added to the table causing
invalid copies in most situation with holes in the set definition while
still binding set 0 or at worst an assert to be triggered in
cmd_fill_dyn_bufs.
This fixes "dEQP-GLES3.functional.ubo.*" and
dEQP-GLES31.functional.ubo.*" on PanVK+ANGLE.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: e350c334b6 ("panvk: Extend the descriptor lowering pass to support Valhall")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34652>
(cherry picked from commit 8d2e16cc11)
When VMMs do not support VIRTGPU_DRM_CAPSET_VENUS the capset data
remains zeroed. By requiring the stable wire_format_version 1 this can
be detected early without initialising the renderer.
Avoids triggering `assert(capset->supports_blob_id_0);` in debug builds
under such circumstances.
Cc: mesa-stable
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34613>
(cherry picked from commit 3d3ca9b65e)
Floating point SEL.CMOD may flush denorms to zero. We don't have enough
information at this point in compilation to know whether or not it is
safe to remove that.
Integer SEL or SEL without a conditional modifier is just a fancy
MOV. Those are always safe to eliminate.
See also 3f782cdd25.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
(cherry picked from commit e783930b10)
The condition modifier on SEL means something completely different than
it means on MOV. On MOV it means to modify the flags based on the value
written to the destination. On SEL it means to compare the sources using
that mode and pick the result (i.e., as min() or max()) without
modifying the flags.
The resulting MOV should not have a condition modifier for the same
reason it (already) doesn't have a predicate. This bug was found by
inspection, so I added a unit test.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
(cherry picked from commit f4ede9c10a)
Floating point SEL.CMOD may flush denorms to zero. We don't have enough
information at this point in compilation to know whether or not it is
safe to remove that.
Integer SEL or SEL without a conditional modifier is just a fancy
MOV. Those are always safe to eliminate.
See also 3f782cdd25.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
No shader-db changes on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 209903490 -> 209903492 (+0.00%)
Cycle count: 30546025224 -> 30546021980 (-0.00%); split: -0.00%, +0.00%
Max live registers: 65516231 -> 65516235 (+0.00%)
Totals from 2 (0.00% of 706657) affected shaders:
Instrs: 3197 -> 3199 (+0.06%)
Cycle count: 361650 -> 358406 (-0.90%); split: -10.05%, +9.15%
Max live registers: 300 -> 304 (+1.33%)
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
(cherry picked from commit 6a19d8915f)
The condition modifier on SEL means something completely different than
it means on MOV. On MOV it means to modify the flags based on the value
written to the destination. On SEL it means to compare the sources using
that mode and pick the result (i.e., as min() or max()) without
modifying the flags.
The resulting MOV should not have a condition modifier for the same
reason it (already) doesn't have a predicate. This bug was found by
inspection, so I added a unit test.
No shader-db or shader-db changes on any Intel platform.
Fixes: fab92fa1cb ("i965/fs: Optimize SEL with the same sources into a MOV.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34192>
(cherry picked from commit 07dc1d4043)
Fixes cts tests:
dEQP-VK.conditional_rendering.conditional_ignore.blit_image
dEQP-VK.conditional_rendering.conditional_ignore.blit_image_inverted
dEQP-VK.conditional_rendering.conditional_ignore.resolve_image
dEQP-VK.conditional_rendering.conditional_ignore.resolve_image_inverted
which were introduced in vk-gl-cts commit 4aa277c300
Fixes: 32f2317223 ("nvk: Use meta for doing blits with the 3D hardware")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34644>
(cherry picked from commit 2fc4c98aaf)
clang 20 complains:
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 5 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 6 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 7 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
But `i < MIN2(instr->operands.back().size() - 1, 5 - num_vaddr)` means `i` is
at most `5 - num_vaddr - 1`, which means `vaddr[num_vaddr + i]` =>
`vaddr[num_vaddr + 5 - num_vaddr - 1]` => `vaddr[5 - 1]` => `vaddr[4]` which
is within the valid indices.
For some reason, using signed `int` instead allows clang to figure this
out, so let's do that since we don't need the extra range.
While at it, use ARRAY_SIZE(vaddr) instead of hard-coding the same `5`
in several places.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34625>
(cherry picked from commit 2bcb55f3f6)
This is now basically the same as the original VALUMaskWriteHazard, except
it now considers both VALU and SALU writes.
Now that it's a part of VALUMaskWriteHazard, differences from the original
VALU lanemask workaround are:
- it includes SALU reads after the write
- it includes VALU writes and SALU/VALU reads after the write which are
not lanemasks
- it combines s_waitcnt_depctr instructions when it's a read after both a
SALU write and a VALU write
- non-exec VALU SGPR reads reset the SGPRs read by VALU as a lanemask
- exec SGPRs are ignored
resolve_all_gfx11() is also finished.
fossil-db (navi31):
Totals from 21538 (27.13% of 79377) affected shaders:
Instrs: 27628855 -> 27552972 (-0.27%); split: -0.30%, +0.03%
CodeSize: 145968448 -> 145667616 (-0.21%); split: -0.23%, +0.02%
Latency: 209537805 -> 209509519 (-0.01%); split: -0.02%, +0.00%
InvThroughput: 36304270 -> 36301624 (-0.01%); split: -0.01%, +0.00%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12623
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11480
Backport-to: 25.0
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34529>
(cherry picked from commit ce2be5ab8e)
These values are shared with xcb/dri2.h, and can't be changed
without breaking the legacy dri2 compatibility. This change
reverses partially the update done by 3b603d1646.
For instance this issue is triggered on dri2 i915 with
"piglit/bin/glx-copy-sub-buffer -auto" or
"piglit/bin/hiz-depth-read-window-stencil0 -auto".
Fixes: 3b603d1646 ("mesa_interface: remove unused stuff")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34561>
(cherry picked from commit 60a31156b0)
This allows us to create temporary VGRFs that are larger than
MAX_VGRF_SIZE(devinfo), which will be split eventually. They may not
be split on the initial pass, because we may need LOAD_PAYLOAD lowering,
copy propagation, and so on to occur first. So we allow registers to
exceed that size initially.
The "Register allocation relies on split_virtual_grfs()" assertion in
brw_reg_allocate.cpp still asserts that all VGRFs which reach the
register allocator have been properly split.
One case where this is useful is for vectorizing convergent block loads.
We create temporaries to splat the SIMD1 values out to SIMD(N), which
can lead to some very large temporaries. However, copy propagation and
so on ultimately eliminate these and they'll get split down to proper
sizes or elided entirely in the end.
(Note: both this and the prior commits from this merge request are
needed to close the linked issue.)
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12324
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
(cherry picked from commit eb1ec9cf8e)
Post-RA scheduling doesn't use liveness analysis, so we continue using
MAX_VGRF_SIZE(devinfo). But for pre-RA scheduling, we now use
live->max_vgrf_size.
This helps get us to a place where we can emit arbitrarily large VGRFs
early on in compilation, but which will be split and cleaned up prior to
register allocation. It may also allocate smaller arrays in practice
since MAX_VGRF_SIZE(devinfo) assumes the worst case scenario for things
we actually could need to allocate.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
(cherry picked from commit a45583f078)
We're already looking at this data to calculate the per-component
vars_from_vgrf[] and vgrf_from_vars[] mappings, so just record the
largest VGRF size while we're here. This will allow passes to size
arrays based on the actual size needed, rather than hardcoding some
fixed size. In many cases, MAX_VGRF_SIZE(devinfo) is larger than
necessary, because e.g. vec5 sparse sampling results aren't used.
Not hardcoding this means we can also temporarily handle very large
VGRFs which we know will be split eventually, without having to
increase the maximum which is ultimately used for RA classes.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
(cherry picked from commit ea468412f6)
We can't have merged shaders where the first part is compiled using ACO
and the second part is compiled using LLVM.
Add ACO-specific main shader parts to fix that.
This happens when ACO is enabled for gfx12 streamout where GS can be paired
with a previous shader compiled by LLVM.
Fixes: 8ba718fb7d - radeonsi/gfx12: use ACO for streamout because it's faster
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34491>
(cherry picked from commit 7f7d6deb18)
TFU units is doing a readahead of 64 bytes. This is causing invalid read
MMU errors that can be observed at the nightly full Vulkan runs on
Broadcom devices.
04:13:59.969: [ 85.623205] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x4869000, pte invalid
04:14:05.408: [ 91.019321] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x5209000, pte invalid
04:14:05.413: [ 91.031662] v3d 1002000000.v3d: MMU error from client TLB (3) at 0x7521000, pte invalid
Although the log reports the TLB the real culprit is the TFU. A fix
to the kernel was submitted to fix AXI ID on V3D 4.2 and 7.1
So doing an over-allocation of 64-bytes at v3dv_AllocateMemory is
the simplest method to make these MMU errors itp disapear.
Running ./deqp-vk for an hour, we can see that ~%40 of allocations
would need an extra page (4096 bytes) to accomodate this 64 bytes
padding.
Fixes: ca330f7f04 ("v3dv: implement VK_EXT_memory_budget")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34475>
(cherry picked from commit 0bcb82048c)
The setting of the clean_pixel_write_enable flag in pan_prepare_rt
was not consistent with the crc valid calculations in pan_emit_fbd.
This caused the crc_valid flag to not be accurate, causing transaction
elimination to fail.
Fixes: eac8f1d460 ("Revert "panfrost: Disable CRC by default"")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34408>
(cherry picked from commit 69a6db4b2b)
In commit 292ac71a4a ("nir/lower_tex: handle deref casts"), we avoided
using texture_index when a texture instruction contained a variable
deref. There's no good reason why this should be done to some of the
lowering, but not all.
So let's fix up code-paths that were added after this change to do the
same.
The first two patches here crossed paths with the commit that introduced
texture_mask, so it's not strange that the change was missed. The last
one seems to have just copied what was done around it, propagating the
issue.
Fixes: 880b00dc59 ("nir/lower_tex: Add support for lowering YUYV formats")
Fixes: 1358d93650 ("nir/lower_tex: Add support for lowering Y41x formats")
Fixes: 65d6f5aed2 ("nir: add options to lower y_vu, yv_yu, yx_xvxu and xy_vxux")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34365>
(cherry picked from commit 41b136f674)
This is an n-queen pattern, where no two values should be on the same
row or column. But this and the second to last element has the same y
component, and neither has the negative one.
Let's fix this up by setting the first value to the negative value. This
matches the D3D 16x sample pattern.
Fixes: a61fb62966 ("panfrost: Upload sample positions on device init")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
(cherry picked from commit b4ebffa1aa)
With vkCmdPipelineBarrier, it's possible to specify a barrier with
pipeline stages but without any memory barriers. These might not be
practical, but are legal Vulkan code.
Barriers like this are currently ignored in mesa, as we only convert
barriers with passed memory barriers into vkCmdPipelineBarrier2.
This commit adds handling of execution only barriers by converting them
into a memory barrier without access masks.
Fixes: 97f0a4494b ("vulkan: implement legacy entrypoints on top of VK_KHR_synchronization2")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34187>
(cherry picked from commit 20c0d169e4)
Fixes some upcoming CTS tests for texture clears.
* some drivers will attempt to issue clears with zero range
and hit asserts/crashes (spec clarification for negative
values)
* fix error thrown with negative values to match spec
* fix cases for clearing generic compressed formats
* fix negative case of using color format while having
depth/stencil internalformat and vice versa
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34428>
(cherry picked from commit 30d78dc942)
Some upcoming changes in the runtime will make it impossible to rely
on the pipeline or runtime information to know whether a fragment
shader has input attachments.
Instead we gather that information at compile time and store it in our
shader bind_map.
At runtime we check whether the fragment shader has input attachments
and whether those map to the runtime depth/stencil input attachments
to set the 3DSTATE_PS_EXTRA::PixelShaderKillsPixel.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d2f7b6d5a7 ("anv: implement VK_KHR_dynamic_rendering_local_read")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
(cherry picked from commit e321c438dc)
For drivers using the render pass emulation provided by the
runtime, it's important to express the mapping between
depth/stencil/color attachments and input attachments using
VkRenderingInputAttachmentIndexInfoKHR, otherwise those drivers
have to special-case emulated render passes in their
CmdBeginRendering() implementation.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540>
(cherry picked from commit be2532fc00)
Panfrost supports pushing uniforms to hardware uniform registers (RMU/FAU for
Midgard/Bifrost respectively). Since OpenGL uniforms are lowered to UBO #0, it
does this with a pass that pushes UBOs. That's good!
The pass also pushes 'true' OpenGL UBOs, since they look the same in the backend
at this point. This is where the trouble comes in:
- True UBOs are allocated in GPU BOs, not CPU allocated buffers. That means it's
write-combine memory, which we cannot read from efficiently (at least
depending on coherency details that were never plumbed through panfrost.ko and
unlikely to be replumbed now that panthor is the new hot stuff). So, pushing
true UBOs reduces GPU overhead at the cost of tremendous CPU overhead. This is
dubious... When I benchmarked this on MT8192 in early 2023, this pushing
improved FPS in SuperTuxKart but hurt FPS in Dolphin.
- True UBOs can be written on the GPU. In OpenGL, we have batch tracking
infrastructure to sort this mess out in theory. What this means is that
pushing UBOs requires us to flush writers AND STALL at draw-time. If this is
ever hit, our performance is utterly trashed. But it gets worse.
- True UBOs can be written in the same batch that reads them. For example, we
could bind a buffer as a transform feedback buffer, do a draw with XFB, then
rebind as a UBO and do a draw reading. This is where we collapse -- our logic
will flush the writer, which is the same batch we were in the middle of
enqueueing a draw to. When we try to push words, we'll crash with theatrics.
This could be solved by smartening the batch tracking logic but it's not
trivial by any means.
So, pushing true UBOs on the CPU is broken and can hurt performance. Stop doing
it!
Long term, the solution will be to push on the GPU instead. This avoids all of
these issues. This can be done with a compute kernel or with CSF instructions.
The Vulkan driver will likely have to do this for performance, since pushing
UBOs from the CPU is utterly broken in Vulkan for the above reasons.
I have a branch somewhere doing this on v9 but I'm doing this on NIR time to
unblock a core change that was crashing piglit due to this pile of unsoundness.
Let's fix the correctness issues first, then someone can look at recovering
performance later when we're not blocking unrelated work.
Fixes corruption in Piglit test
gles-3.0-transform-feedback-uniform-buffer-object, which writes a UBO with
transform feedback. (I suspect the test still doesn't pass for the same reason
it's broken on other tilers. But that's a better place to be than oodles of
memory corruption.)
According to CI, fixes spec@arb_uniform_buffer_object@rendering{-dsa}-offset.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34193>
(cherry picked from commit 59a3e12039)
ss->info.ubo_mask includes the push+sysval UBO so if there's a user
UBO bound at the same index as the push+sysval UBO, without this
change we end up writing a descriptor for the user UBO at that index.
Fixes: 3b3cd59f ("panfrost: Launch transform feedback shaders")
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34193>
(cherry picked from commit 6948ab727f)
For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 16400 byte(s) in 5 object(s) allocated from:
#0 0xb720689a in __interceptor_calloc (/usr/lib/libasan.so.6+0xb289a)
#1 0xaf10f896 in draw_create_fragment_shader ../src/gallium/auxiliary/draw/draw_fs.c:47
#2 0xaef64619 in i915_create_fs_state ../src/gallium/drivers/i915/i915_state.c:550
#3 0xae16a955 in ureg_create_shader ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2194
#4 0xae17f45f in ureg_create_shader_with_so_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:150
#5 0xae17f45f in ureg_create_shader_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:159
#6 0xae17f45f in util_make_fs_blit_zs ../src/gallium/auxiliary/util/u_simple_shaders.c:365
#7 0xaf13300e in blitter_get_fs_texfetch_depth ../src/gallium/auxiliary/util/u_blitter.c:1157
#8 0xaf13300e in util_blitter_cache_all_shaders ../src/gallium/auxiliary/util/u_blitter.c:1322
#9 0xaef6b738 in i915_create_context ../src/gallium/drivers/i915/i915_context.c:233
#10 0xacb33c49 in st_api_create_context ../src/mesa/state_tracker/st_manager.c:986
#11 0xac845740 in dri_create_context ../src/gallium/frontends/dri/dri_context.c:178
#12 0xac854d97 in driCreateContextAttribs ../src/gallium/frontends/dri/dri_util.c:631
#13 0xb6ce79a3 in dri2_create_context_attribs ../src/glx/dri2_glx.c:240
#14 0xb6c9606f in dri_common_create_context ../src/glx/dri_common.c:665
#15 0xb6ca4f00 in CreateContext ../src/glx/glxcmds.c:322
#16 0xb6ca5c0b in glXCreateNewContext ../src/glx/glxcmds.c:1449
Fixes: 1a69b50b3b ("i915g: Fix point sprites.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
(cherry picked from commit f0cfc1bbdc)
For instance, this issue is triggered with "piglit/bin/glx-multithread-texture -auto -fbo":
Direct leak of 256 byte(s) in 1 object(s) allocated from:
#0 0xb71eda62 in __interceptor_realloc (/usr/lib/libasan.so.6+0xb2a62)
#1 0xadd5a32f in tokens_expand ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:239
#2 0xadd5a32f in get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:262
#3 0xadd62519 in copy_instructions ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2079
#4 0xadd62519 in ureg_finalize ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2129
#5 0xadd64bde in ureg_get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2206
#6 0xade377d0 in nir_to_tgsi_options ../src/gallium/auxiliary/nir/nir_to_tgsi.c:4043
#7 0xade3da63 in nir_to_tgsi ../src/gallium/auxiliary/nir/nir_to_tgsi.c:3831
#8 0xaeb606c9 in i915_create_vs_state ../src/gallium/drivers/i915/i915_state.c:662
#9 0xac781a2c in st_create_common_variant ../src/mesa/state_tracker/st_program.c:720
#10 0xac78e8a4 in st_get_common_variant ../src/mesa/state_tracker/st_program.c:773
#11 0xac78fc10 in st_precompile_shader_variant ../src/mesa/state_tracker/st_program.c:1259
#12 0xac78fc10 in st_finalize_program ../src/mesa/state_tracker/st_program.c:1345
#13 0xac790b1a in st_program_string_notify ../src/mesa/state_tracker/st_program.c:1378
#14 0xace457a9 in _mesa_get_fixed_func_vertex_program ../src/mesa/main/ffvertex_prog.c:1397
#15 0xac5ef8db in update_program ../src/mesa/main/state.c:281
#16 0xac5f0ece in _mesa_update_state_locked ../src/mesa/main/state.c:560
#17 0xac5f1653 in _mesa_update_state ../src/mesa/main/state.c:593
#18 0xacdf9fe2 in _mesa_DrawArrays ../src/mesa/main/draw.c:1403
Fixes: 487a493325 ("i915g: Add support for per-vertex point size.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
(cherry picked from commit 5af5f508b1)
For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 836 byte(s) in 1 object(s) allocated from:
#0 0xb71eb6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaefadc78 in slab_add_new_page ../src/util/slab.c:179
#2 0xaefadc78 in slab_alloc ../src/util/slab.c:221
#3 0xaef7d461 in i915_texture_transfer_map ../src/gallium/drivers/i915/i915_resource_texture.c:789
#4 0xac9e931e in pipe_texture_map ../src/gallium/auxiliary/util/u_inlines.h:555
#5 0xac9e931e in _mesa_map_renderbuffer ../src/mesa/main/renderbuffer.c:494
#6 0xad49c5e4 in readpixels_memcpy ../src/mesa/main/readpix.c:260
#7 0xad49c5e4 in _mesa_readpixels ../src/mesa/main/readpix.c:898
#8 0xad5d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad4a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad4a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad4a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
or "piglit/bin/fcc-read-to-pbo-after-clear -auto":
Direct leak of 772 byte(s) in 1 object(s) allocated from:
#0 0xb726b6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaf0adc88 in slab_add_new_page ../src/util/slab.c:179
#2 0xaf0adc88 in slab_alloc ../src/util/slab.c:221
#3 0xaf07aad7 in i915_buffer_transfer_map ../src/gallium/drivers/i915/i915_resource_buffer.c:75
#4 0xad10de74 in pipe_buffer_map_range ../src/gallium/auxiliary/util/u_inlines.h:398
#5 0xad10de74 in _mesa_bufferobj_map_range ../src/mesa/main/bufferobj.c:499
#6 0xad5677ce in _mesa_map_pbo_dest ../src/mesa/main/pbo.c:308
#7 0xad59be3b in _mesa_readpixels ../src/mesa/main/readpix.c:894
#8 0xad6d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad5a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad5a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad5a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
Fixes: e7a73b75a0 ("gallium: switch drivers to the slab allocator in src/util")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
(cherry picked from commit 92802ea90a)
This is necessary to appropriately uniformize the first component
access of a convergent vector. Without this, this is produced:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
This is the correct code:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
Without 38b58e286f, the code generated was more incorrect, but happened
to work for this test case:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+0.4<0>:F, 0.5f
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 38b58e286f ("brw/nir: Fix source handling of nir_intrinsic_load_barycentric_at_offset")
Closes: #12969
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34427>
(cherry picked from commit cb69d019cf)
Indeed, this resource was assigned twice and was not properly freed.
For instance, this issue is triggered with:
"piglit/bin/glsl-fs-pointcoord -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 0278d1fa32 ("gallium: add unbind_num_trailing_slots to set_vertex_buffers")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27572>
(cherry picked from commit 22c399320b)
We need different Temps for each resume shader, because registers aren't
preserved across resume boundaries.
This was likely fine in practice because arg registers are the same for
each shader, but resulted in invalid IR and asserts.
Fixes crashes in Indiana Jones RT with assertions enabled on GFX8.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34114>
(cherry picked from commit 3d8db3cbbb)
This pulls out the logicop_func variable from the options struct, so we can
modify it in the next commit in a central place. It then refactors out the
format variable from the options struct since we end up duplicating
options->format[rt] a zillion times and passing in both an options struct and a
logicop func override is confusing so this will just make everything neater and
self-contained next commit.
no functional change.
Cc'd to make the next commit cherrypickable.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34426>
(cherry picked from commit 54ccc8ed0b)
This is the backport of eca57f85ee ("radeonsi: fix
gl_ClipDistance and gl_ClipVertex for points").
This change was tested on rv770, palm, barts and cayman. It
fixes 450 khr-gl tests and 64 khr-gles tests on evergreen
and cayman gpus. Here is the list:
spec/glsl-1.20/execution/clipping/vs-clip-vertex-primitives: fail pass
spec/glsl-1.30/execution/clipping/vs-clip-distance-primitives: fail pass
spec/glsl-1.50/execution/compatibility/clipping/gs-clip-vertex-primitives-points: fail pass
khr-gl(3[0-3]|4[0-5])/clip_distance/functional: fail pass
khr-gl(33|4[0-5])/cull_distance/functional_test_item_[0-8]_primitive_mode_points_max_culldist_[0-7]: fail pass
khr-gles3/clip_distance/functional: fail pass
khr-gles3/cull_distance/functional_test_item_[0-8]_primitive_mode_points_max_culldist_[0-7]: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34403>
(cherry picked from commit 58ddf6aaf0)
This is the backport of 9c49550163. This rounding functionality
is available on all the gpus of the r600 family.
This change was tested on rv770, palm and cayman. This change fixes
at least the "turn-on-off" tests on all these gpus and it does not
add any regression. Here are the tests fixed on palm:
spec/ext_framebuffer_multisample/interpolation 6 centroid-edges: fail pass
spec/ext_framebuffer_multisample/interpolation 8 centroid-edges: fail pass
spec/ext_framebuffer_multisample/turn-on-off 2: fail pass
spec/ext_framebuffer_multisample/turn-on-off 4: fail pass
spec/ext_framebuffer_multisample/turn-on-off 6: fail pass
spec/ext_framebuffer_multisample/turn-on-off 8: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34403>
(cherry picked from commit 8fc01db1ac)
When executing CopyBufferToImage or CopyImage with multiple regions of
both depth and stencil aspects targeting an interleaved depth stencil
image, we must split the regions into one copy-command for each aspect
and add a barrier between them to avoid a write-after-write race.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 5067921349 ("panvk: Switch to vk_meta")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34384>
(cherry picked from commit 37595775a0)
This is mostly defensive. If a convergent value ever ended up as a
source of a DDX or DDY, the eu_emit code will ignore the stride. This
will result in bad code being generated.
No shader-db or fossil-db changes on any Intel platform.
v2: DDX and DDY will always be float, but brw_imm_for_type only works
with integer types.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Suggested-by: Ken
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
(cherry picked from commit dee49f4206)
The source of nir_intrinsic_load_barycentric_at_offset is a vector, so
-1 should be passed to get_nir_src. This is also done for texture
sampling intrinsics.
I skimmed the other user of get_nir_src, and I believe they are
correct. This one was just missed as LNL support landed an many, many
rebases of the original MR occurred.
v2: Fix another get_nir_src call. Suggested by Lionel.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [v1]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Closes: #12464
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
(cherry picked from commit 38b58e286f)
Bifrost keeps a cache of information about buffers being
used as indices. Unfortunately, it was not keeping information
about the size of the indices (probably because this rarely
changes). If a program deliberately re-interprets the indices
as a different type (e.g. UNSIGNED_INT instead of UNSIGNED_SHORT)
then we will use incorrect values from the cache. This actually
showed up in a test program we were running.
Fix by saving the index size in the cache key.
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34011>
(cherry picked from commit 739da17f6e)
This issue seems to be specific to textureGather() which could
fail when processing some surfaces. These surfaces are configured
with non-standard one and zero swizzles. The gpu doesn't support
this very specific setup with all the possible hardware formats.
This change selects a compatible configuration when this is
possible.
This change was tested on palm, barts and cayman. This change
fixes the 216 remaining arb_texture_gather tests:
spec/arb_texture_gather/texturegather/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegather/.*-one-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-one-.*: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34293>
(cherry picked from commit f0c0997277)
The vtn_ssa_value for a cmat is not backed by a nir_def, but by a nir_variable, so
can't be used directly when calling a function. In most cases the cmat is used by
reference so code will take the value of deref for it (which is a `nir_def`).
When passing a cooperative matrix to a function by value, let the caller pass the deref
value, and the callee copy to a new local variable from that deref.
Fixes: b98f87612b ("spirv: Implement SPV_KHR_cooperative_matrix")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34364>
(cherry picked from commit 0cad7b0968)
The cid loop in the previous implementation stopped at n_counters for a
given category, even though cid is a global id that does not start
counting from zero at the beginning of each category. As a result, we
missed most of the counters outside of the first category.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 513d1baaea ("pps: Panfrost pps driver")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34202>
(cherry picked from commit 3b66e4a438)
This prevents assertion failures in brw_eu_emit in a later commit in
this MR. Even though they have not been previously observed, these
assertion failures could happen even without that commit.
No shader-db or fossil-db changes on any Intel platform.
Fixes: 04e1783278 ("brw: Call brw_fs_opt_algebraic less often")
v2: Add SHUFFLE. Suggested by Ken. Fixed indentation.
v3: Update BROADCAST exec_size after rebasing on "brw/build: Use SIMD8
temporaries in emit_uniformize".
v4: Explain why munging the exec_size is correct.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31497>
(cherry picked from commit 8b2be206f3)
We need to remember which streamout buffers and streams were enabled,
even if the shader doesn't actually write any outputs to them,
because the API requires that we count vertices created by this shader
towards queries against those streams.
That information can be gathered by nir_gather_xfb_info_with_varyings
from the original NIR I/O variables that we get from the frontend,
but it isn't included in any intrinsics so would be otherwise lost here.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34317>
(cherry picked from commit a29b5857f7)
On i686, where VK_USE_64_BIT_PTR_DEFINES is unset and Vulkan handles are
represented as 64-bit integers instead, the code used the wrong format
specifier, causing a build error.
Fixes: 7fb31361f4 ("Handle external fences in vkGetFenceStatus()")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34124>
(cherry picked from commit 1deb0536a1)
Shared RA might insert new defs to be handled by regular RA (e.g.,
shared spills). However, their interval offsets were not initialized
which caused their intervals to sometimes be mistakenly matched with
those containing offset 0. Fix this by calling index_merge_sets after
shared RA and modifying that function to only index new defs in that
case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33319>
(cherry picked from commit a0db2f9737)
With "classic" renderpasses, the VkFramebuffer's layerCount must be 1 if
multiview is enabled. We accidentally rely on this to not disable GMEM
for multiview, and possibly for other things too. Apparently the dynamic
rendering equivalent, VkRenderingInfo::layerCount, can be anything when
multiview is enabled, and some CTS tests set it to the number of views.
Sanitize it when constructing the internal framebuffer for dynamic
rendering.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34080>
(cherry picked from commit 15660caa90)
These changes happened with no mesa code change, only infrastructure
changes, which is really weird, but to be able to move on, let's simply
document the "new normal".
(Was missed in 69d6923cdb)
Otherwise we schedule this sort of thing wrong,
r0 = iadd3 r0 c[0x0][0x0] rZ
r0 = shf.l.w.i32 r0 rZ 0x2
r0 p0 = iadd3 r0 c[0x1][0x0] rZ
since raw latencies are more important than waw, but we go do a
waw for the first two instructions instead of a raw which is correct.
Fixes: 2d4e445099 ("nak/calc_instr_deps: Rewrite calc_delays() again")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
(cherry picked from commit 7a55a9afcc)
We currently just assume that textureCompressionETC2 and
textureCompressionASTC_LDR are always supported. And while that's true
for all the G52s, G610s abd G310s we've seen out in the wild, it's not
guaranteed to be true. An SoC vendor might disable support for one of
these formats.
So let's check properly, just for good measure.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34206>
(cherry picked from commit e4786cf971)
A pipeline barrier which contains an image layout transition like
COLOR_ATTACHMENT_OPTIMAL -> TRANSFER_DST_OPTIMAL on compute queue
would just hang. Such a barrier is useless in practice but it's legal.
Prevent GPU hangs by skipping FCE or FMASK_DECOMPRESS when it's not
on the graphics queue.
Fixes dEQP-VK.synchronization2.layout_transition.compute_transition*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34231>
(cherry picked from commit 086f529bbe)
When we're using the PRIME path and using vkCmdCopyImageToBuffer to copy
to a linear image, the buffer memory is what's shared with the window
system. For legacy drivers that depend on memory signaling via
wsi_memory_signal_submit_info, we need to tell the driver to signal the
buffer memory, not the image memory or else the window system may wait
on a driver-internal buffer and not wait for the copy to complete.
Cc: mesa-stable
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34218>
(cherry picked from commit cf23ffcbae)
a1b05991 ("radv/rt: Flush L2 after writing internal node offset on GFX12")
did this for radv-internal CP writes - we also need to do this for PLOC
sync data initialization which is done in the common framework.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34178>
(cherry picked from commit c1e1d86bd1)
The mirror needs to be reversed because the rotation is applied
before the mirroring.
VAAPI docs:
Mirroring of an image can be performed either along the
horizontal or vertical axis. It is assumed that the rotation
operation is always performed before the mirroring operation.
Cc: mesa-stable
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34140>
(cherry picked from commit 962c33cbca)
We were never setting has_multiview. It's not actually necessary anyway,
since we can just do the optimization we were trying to do whenever
num_views is 1 instead.
This doesn't affect the actual fragment size, which was already correct,
only gl_FragSizeEXT.
Fixes: 6f2be52487 ("tu, ir3: Handle FDM shader builtins")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33991>
(cherry picked from commit 8864ee7b0f)
It's possible that the source is uniform but the destination is not. In
this case, we need to insert a copy or else we might accidentally
propagate a uniform into some place we don't expect it.
This fixes a bunch of fp64 KHR-Single-GL46.subgroups.arithmetic.* tests.
Fixes: d09d3f5246 ("nak/from_nir: Emit uniform instructions when !divergent")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
(cherry picked from commit 1d1d79bbaa)
In 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages") I
misread the PRMs and thought that the VF would initialize the header.
What actually happens is that the VF does not write valid values in
there and the PRMs explicitly say that the VS shader should overwrite
whatever is in there.
We could avoid writing the header in some cases when no HW is going to
read back the header. For example with rendering disables through
3DSTATE_STREAMOUT::RenderingDisable. But those cases are dynamic and
the compiler is not able to tell. So just always write the header.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12880
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34211>
(cherry picked from commit 4db4bd1d04)
The color format needs to be compatible with depth or stencil. Also
the depth/stencil format was incorrect when it's the source.
Fixes dEQP-VK.api.ds_color_copy.*
and VKD3D_TEST_FILTER=test_copy_texture.
Fixes: d4ff011b12 ("radv: advertise VK_KHR_maintenance8")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34142>
(cherry picked from commit 2c3b9312cc)
When updating delays, we'd update all dst regs based on reg_elems.
However, when wrmask has gaps, this would update delays for regs that
aren't actually written. Fix this by skipping regs for which the
corresponding wrmask bit is zero.
Note that this wasn't just a performance issue but could result in
illegal code because the delay is reset to zero for tex/sfu
instructions. For example, the following (post-legalization) code was
observed in the wild:
(rpt1)add.f r1.w, (r)r2.w, (r)c3.z
sam.base0 (f32)(w)r2.x, r3.y, s#0, t#1
rcp r2.x, r2.x
Here, the add would result in a required delay for r2.x which would then
be cleared by the sam (even though it doesn't write to it), resulting in
insufficient delay before the rcp.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 61b2bd861f ("ir3: Rewrite nop insertion")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34107>
(cherry picked from commit 84dbd34332)
The call looks up a Program and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 786b8b2d34)
The call looks up an ATIShader and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 4c1e4d7b49)
The calls look up a renderbuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 0e61d31e9d)
The calls look up a framebuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit c4ee84f3b6)
The calls look up a texture object and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c9130 ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 95e87f6a6a)
The spec allows to create aliased disjoint image for a specific plane of
a multi-planar image, and the format can be R8. When querying memory
requirement of such image, VkImagePlaneMemoryRequirementsInfo is not
required to be chained although it has the disjoint bit.
This change fixes to look for aspect info from plane memory info only
when that's chained. The implementation can be passive here as the spec
VU has sufficient guarantees for the validity around. See below VU for
details:
- VUID-VkImageMemoryRequirementsInfo2-image-01589
- VUID-VkImageMemoryRequirementsInfo2-image-01590
- VUID-VkImageMemoryRequirementsInfo2-image-02279
- VUID-VkImageMemoryRequirementsInfo2-image-02280
Meanwhile, the existing disjoint check for size info is kept as is for
the special handling of VK_FORMAT_D32_SFLOAT_S8_UINT.
Test: dEQP-VK.ycbcr.plane_view.memory_alias.* pass with venus-on-panvk
Fixes: 412c286331 ("panvk: Enable multiplane images and image views")
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34134>
(cherry picked from commit 5dcb9f918d)
Per Vulkan spec 7.9. Host Write Ordering Guarantees, queue submission
commands automatically perform a domain operation from host to device
for all writes performed before the command executes. That is to say,
host updates to the mappings can occur after the end of the command
recording and must be flushed implicitly at submission boundary.
Before this change, necessary cache flushes could be missed once the
app starts reusing pre-recorded command buffers. e.g. a simple buffer
copy cmd while the app only updates the source buffer mapping in
different submissions. This changes backs out most of the current
version of cache flush reduction while still assigning LATEST_FLUSH_ID
to at least the final batch itself. This aligns with panfrost_batch
submit behavior on the gallium side.
Test: dEQP-VK.synchronization*.timeline_semaphore.* pass w/o flakiness
via venus-on-panvk
Fixes: 28e4d22497 ("panvk/csf: Pass a non-zero flush-id to benefit from cache flush reduction")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34093>
(cherry picked from commit 98a5acf352)
If the last owner thread has just unset the alive status and released
the watchdog, the new owner thread could have acquired to abort
unexpectedly if the ownership transfer occurs right before the next
owner's warn order. So we must set watchdog alive for new owner so that
it can properly check ring alive status in the next warn order.
Cc: mesa-stable
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34135>
(cherry picked from commit 8b2703fe08)
Register spilling can cause us to require thread local storage (tls).
However, we were not adjusting the tls stack size space to account for
the tls needed for the extra xfb shader when transform feedback is
needed. We noticed this when testing register allocation in the
OpenGL CTS (for testing we had forced spilling where none happened
before).
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33935>
(cherry picked from commit 2ee3bef252)
If we pass zink=false to pipe_loader_drm_probe_fd, it could happen that
a Gallium driver that had been already discarded because of not
supporting the graphics CAP will be chosen.
To avoid that, explicitly ask pipe_loader_drm_probe_fd to choose the
zink Gallium driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 854bc2ee05)
Exposing a rendernode from a supported driver is not a sufficient
matching criteria to qualify as the render part of a renderonly
device, as the rendernode might only expose compute or 2D accel
capabilities.
Look for a screen that actually supports gallium graphics operations
to qualify as a renderonly screen.
v2 (Tomeu): Have pipe-loader return a list of FDs for kmsro to choose
based on capabilities.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 7e76c67632)
These changes happened with no mesa code change, only infrastructure
changes, which is really weird, but to be able to move on, let's simply
document the "new normal".
The current `s3cp` implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use `curl`.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
(cherry picked from commit 7178425ccf)
It seems the hardware requires a dummy PS state with a noop FS,
otherwise it might just hang. This used to work just fine on older
gens.
Note that RadeonSI refuses to draw if VS or PS is missing and AMDVLK
seems to also always emit this state. So, this might be a bug that AMD
didn't encounter at all.
This fixes a GPU hang during loading with Ghostwire: Tokyo.
Backport-to: 25.0
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34070>
(cherry picked from commit 1e4cfd9dfa)
This change began by fixing an old regression related to the dceil
functionality. This issue affected palm. Now, this change adjusts
the software fp64 support to make it fully operational.
This change was tested on palm and barts. This change fixes 561
"piglit run all" tests. The khr_gl tests are fixed as well (243 tests).
Here is a summary:
spec/arb_gpu_shader_fp64/execution/built-in-functions/*
spec/arb_gpu_shader_fp64/execution/fs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/gs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/vs-isnan-dvec: fail pass
spec/glsl-4.00/execution/built-in-functions/*
spec/glsl-4.10/execution/conversion/*
khr-gl4[3-5]/compute_shader/fp64-case1: fail pass
khr-gl4[0-5]/gpu_shader_fp64/builtin/*
Fixes: aed6a39c10 ("glsl: Retire dround lowering.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33708>
(cherry picked from commit 186fb5e73a)
The problem occurs with a series of instructions build the subgroup
invocation value :
mov(8) g23<1>UW 0x76543210V
add(8) g23.8<1>UW g23<8,8,1>UW 0x0008UW
add(16) g23.16<1>UW g23<16,16,1>UW 0x0010UW
Our register spilling code operates on physical registers (64B on
Xe2+) and using the brw_inst::is_partial_write() helper only considers
32B registers. So the spiller doesn't see that the add(16) instruction
is doing a partial write and ends up discarding the previous value.
You can reproduce the issue by running a test like :
INTEL_DEBUG=spill_fs ./deqp-vk -n dEQP-VK.compute.pipeline.cooperative_matrix.khr_a.subgroupscope.constant.uint8_uint8.buffer.rowmajor.linear
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: aa494cbacf ("brw: align spilling offsets to physical register sizes")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33642>
(cherry picked from commit c60180ba63)
std::slice::from_raw_parts requires that the slice pointer be non-null,
even when the slice contains zero elements. Failing this invariant is
undefined behavior.
v2: reordered commits to allow cherry-picking bugfixes
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
(cherry picked from commit 5e365f1674)
When a slow/fast/slow clear sequence is executed on a surface, the second
slow clear will not regenerate the clear command if the clear value of the
fast clear is the same as the one used for the second slow clear, as the
current stored surface clear value is the same as the new clear value.
The command generated on the first slow clear however may have used a
different clear value, which is now submitted unchanged to the hardware on
the second slow clear.
Fix this by only generating the clear command if there is no valid one
already. If we already have a valid clear command simply update the fill
value in that command with the new clear value. This has some marginal
overhead, but has been chosen over the alternative of adding more state by
remembering the last slow clear value.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34029>
(cherry picked from commit fb0f9e6352)
Cayman has a non-deterministic behavior issue which is
visible with the test below (arb_shader_image_size).
The tests fail randomly at the "fragment" test category.
Anyway, if the "compute" category is removed, the same
tests are working flawlessly.
The "compute" part of the driver was interfering with the
graphic pipeline. The culprit is the packet PKT3_DEALLOC_STATE
which puts the gpu in an incorrect state to perform some
graphic operations.
This change fixes this problem by issuing a PKT3_CLEAR_STATE
packet just after the PKT3_SURFACE_SYNC packet. As explained
by d51dbe048a PKT3_DEALLOC_STATE is mandatory on cayman to
avoid a gpu hang at the PKT3_SURFACE_SYNC stage.
This correction makes tests like
"spec@glsl-4.30@execution@built-in-functions@cs-.*" to pass
in an utterly deterministic way without random failures.
This change removes around 500 random failures for a
"piglit run all".
For instance, this issue is triggered on cayman with
"piglit/bin/arb_shader_image_size-builtin -auto -fbo".
Fixes: d51dbe048a ("r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33973>
(cherry picked from commit 085cfc98cc)
This optimization seems broken because eg. v_s_log_f32 uses SGPRs
for both the source and destination but applying OMOD seems to require
VGPRs.
This fixes a GPU hang when launching Enshrouded on GFX1201.
No fossils db changes on GFX1201.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34027>
(cherry picked from commit f46830912e)
Otherwise, the size of the EGLSurface and the drawable may get out of
sync if kopper needs to re-create the swapchain at a different size.
This can cause problems with things like eglSetDamageRegionKHR() where
the core EGL code clamps them to the size in the EGLSurface.
With Wayland, it's up to the client to choose a size and resize by
creating a new EGLSurface with a different size. Only on X11 can we
get a resize side-band like this.
Normally, without kopper, this goes the other direction where the X11
EGL code will detect a surface size change in dri2_x11_query_surface()
and it invalidates the drawable if they've changed, forcing
re-allocation. Kopper, however, works more like the DRI2 path where we
just get handed buffers at some size decided by X11 and have to deal
with them. In the DRI2 path, the size is unconditionally updated by
dri2_x11_get_buffers(). This is roughly equivalent, updating the size
right after every call to kopperSwapBuffers().
Fixes: 8ade5588e3 ("zink: add kopper api")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12797
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34015>
(cherry picked from commit ad90dbabe4)
A lot of people (including me) misinterpreted the conformanceVersion
field for so long. The Vulkan spec wasn't very clear either but it's
going to be clarified soon.
VkConformanceVersion is actually unrelated to the official CTS
conformance process in Khronos. It just reports the latest CTS version
that the driver can pass, not more.
For GFX8+, RADV should be passing CTS 1.4.0.0 on all GPUs because we
validated this CTS version recently for Vulkan 1.4.
For GFX6-7, which only suppports Vulkan 1.3, RADV should also be
passing CTS 1.4.0.0, because newer versions of the CTS can be used
to validate a driver against an older version of the spec, so
it's perfectly fine to report a higher CTS version than the Vulkan version.
Newer CTS versions likely can't pass 100% due to a DGC bug that I still
need to fix.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12799
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34018>
(cherry picked from commit e519e0b9e6)
With secondary command buffers, inherited rendering can be used but
it's basically impossible to know if the depth/stencil attachment
enabled HiZ/HiS. But it's required to disable WALK_ALIGN8 to avoid
GPU hangs.
This assumes that HiZ/HiS is enabled for inherited rendering as long
as a depth/stencil attachment is used. It's not the most optimal
approach but it's not supposed to hurt either.
This fixes a GPU hang with
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_cmdbuffers
and friends.
GFX1200 isn't affected because it doesn't support HiZ/HiS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33986>
(cherry picked from commit d1a2ba57f9)
We currently report a deviceName as e.g. "Mali-G610 (Panfrost)", but
panfrost has nothing to di with the physical device, and the suffix
doesn't belong there at all.
So let's remove that suffix from PanVK. This results in output like this
from vulkaninfo:
---8<---
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.1.305 (4198705)
driverVersion = 25.0.99 (104857699)
vendorID = 0x13b5
deviceID = 0xa8670000
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Mali-G610
pipelineCacheUUID = <snip>
---8<---
We already sort of namedrop Panfrost in the driver properties:
---8<---
VkPhysicalDeviceDriverPropertiesKHR:
------------------------------------
driverID = DRIVER_ID_MESA_PANVK
driverName = panvk
driverInfo = Mesa 25.1.0-devel (git-136dd9f985)
conformanceVersion:
major = 1
minor = 4
subminor = 1
patch = 2
---8<---
While this might techically speaking be a regression, PanVK has been
marked as experimental until Mesa 25.0. But to reduce the risk of people
starting to depend on this behavior, let's also backport this change to
the 25.0 release.
The patch looks a bit funny, because we add the " (Panfrost)"-suffix in
common code, and this moves it to the Gallium driver. But effectively,
this means PanVK is the only driver that sees a change of behavior.
Backport-to: 25.0
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33972>
(cherry picked from commit c34c7b1f3b)
Compositors sometime try to import BOs with lower alignments than 128B.
This seems particularly common in the case of cursor images but it can
also happen on other BOs allocated by the old nouveau GL driver. As
long as we avoid rendering to them (which NVK will do), the
texture/image hardware is fine as long as they're at least 32B-aligned.
Panicing in this case isn't very nice to compositors.
Backport-to: 25.0
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33990>
(cherry picked from commit 3c11da8aea)
When importing libdrm_radeon code [1][2] it was somehow missed
that what libdrm has in one r600_pci_ids.h, Mesa has split
into r600_pci_ids.h and radeonsi_pci_ids.h. So, devices
with ids from radeonsi_pci_ids.h were not considered valid for
radeon_surface_manager_new.
This commit changes that, thus fixing radeonsi for these
devices.
[1] commit 1299f5c50a
[2] commit 3aa7497cc0
Fixes: 1299f5c50a
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33940>
(cherry picked from commit 4ad5b8f5bb)
It is expected that inputs and prefetches are always in the first block.
However, ir3_create_empty_preamble would create blocks before the first
one, leaving inputs after the preamble. This causes issues with
(probably among others) spilling/RA where precolored inputs could
illegally reuse the spill base register.
Fixes RA validation failures on a7xx for
dEQP-VK.ray_query.multiple_ray_queries.vertex_shader
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: f3026b3d3e ("ir3: add some preamble helpers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33977>
(cherry picked from commit c58ba21ba8)
For empty BVHs we shouldn't emit any leaf nodes, but there is one
invocation to encode the root node. Guard leaf node encoding so that
invocation doesn't try writing any leaves.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33985>
(cherry picked from commit cdadda2d51)
We get a kernel message "You are adding an unorder point to timeline!"
on many CTS runs. This stems from us SIGNALing the queue syncobj then
WAITing but not reseting it. It is assumed by the time we get to
panvk_queue_submit_init_signals() that the value is 0, however it is 1
due to the previous calls.
Signed-off-by: Ashley Smith <ashley.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 5544d39f ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33943>
(cherry picked from commit 14101ff948)
At least, NAVI10, NAVI21 and NAVI24 are affected by this what looks
like a hardware bug when primitive restart is changed and no context
registers are written between draws. It seems the hardware doesn't
consider primitive restart at all in this situation.
Adding SQ_NON_EVENT(0) as suggested by Marek seems to fix it reliably
without introducing any overhead. It's basically a NOP packet that adds
a small delay.
Fixes new VKCTS coverage dEQP-VK.transform_feedback.primitive_restart.*.
Also fixes this old vkd3d-proton issue.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7258
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33929>
(cherry picked from commit 0bc9d59c2e)
We check for iamge layouts and feedback loops when we bind image
resources but not queue families. If the resource isn't on the graphics
queue, we need to add it to need_barriers so we can transition it back
to our queue.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
(cherry picked from commit 18d206d67c)
Otherwise, we'll transition to QUEUE_FAMILY_FOREIGN and then forget that
we left it on the foreign queue and never transition back the next time
we use the resource. This was kind-of okay with Wayland compositors
because they always re-import the BO so it's always fresh and they pick
up on the queue transfer the first time. X11, on the other hand, does
not re-import BOs so they get stuck in this weird QUEUE_FAMILY_FOREIGN
limbo until something happens to randomly trigger a layout transition
check and then we find it and do the transition. We should mark them as
needing a barrier the moment we transition to QUEUE_FAMILY_FOREIGN.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
(cherry picked from commit 396ece1ad8)
The free list must be re-initialized. Found the bug while running:
dEQP-VK.ray_tracing_pipeline.acceleration_structures.device_compability_khr.gpu_built.top
where it invokes VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT to purge
the cmd pool resources, and the next alloc still gets cache hit with the
"empty" list.
Fixes: e2c4bafccc ("venus: free query batches for VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33908>
(cherry picked from commit 6868212774)
If PXP initialization is not completed and application requested a
protected context the GEM_CONTEXT_CREATE will wait up to 250ms for
PXP to finish initialization but if that do not happens it will
return a error and set errno to EIO.
This patch add the missing retry handling.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30723>
(cherry picked from commit 008ac818ba)
This seems to fix some artifacts, but we're not sure why, so it might not
be a correct or optimal solution.
fossil-db (navi31):
Totals from 28424 (35.81% of 79377) affected shaders:
Instrs: 30112910 -> 30348977 (+0.78%); split: -0.00%, +0.78%
CodeSize: 159542980 -> 160485336 (+0.59%); split: -0.00%, +0.59%
Latency: 221438396 -> 221500856 (+0.03%); split: -0.00%, +0.03%
InvThroughput: 38154231 -> 38159984 (+0.02%); split: -0.00%, +0.02%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33853>
(cherry picked from commit 0ec174afd5)
The old code got the accumulation a bit wrong. For one thing, it always
accumulates with whatever was there instead of resetting to empty each
time. For another, it sets with with y and height with x when it writes
back to the resource. This is also all too complicated because it
converts between pipe_box, u_rect, and VkRect2D on every iteration.
Instead, there are helpers in util/box.h which will do most of this work
for us and they're correct. Let's just use them to get rid of the bugs
and make everything simpler and more obvious at the same time.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12194
Fixes: 3d38c9597f ("zink: hook up KHR_partial_update")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33855>
(cherry picked from commit 11939a70df)
In case of constant lowering with halfswizzle sources, we were selecting
h01 causing an invalid instruction error to be yield later.
This can only be hit by conversion instructions and shouldn't be seen in
the wild (as this should be eliminated before entering the backend).
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 7d07fb9a67 ("pan/va: Handle 8-bit lane when lowering constants")
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33867>
(cherry picked from commit 2f1ce296d0)
Add a specific timeout for the U-Boot action in LAVA job definitions for
rockchip devices. This ensures sufficient time for U-Boot to download
the kernel and set up early network, preventing potential job failures
due to timeout constraints.
This behavior started to happen since LAVA 2025.02 version.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33839>
(cherry picked from commit 1dbebd2619)
Ideally this would be passed in pic params as the values are
in sequence header, but using the surface size also works.
Also add sanity checks for frame size.
Fixes decoding av1-1-b8-22-svc-L2T1 and av1-1-b8-22-svc-L2T2.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33737>
(cherry picked from commit d0414ef7fb)
This change fixes a regression introduced with 8b5d41cacb.
Indeed, lookup_resid was not updated.
This change was tested on palm and cayman. Here are the tests fixed:
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-uint: fail pass
Fixes: 8b5d41cacb ("r600/sfn: Use range_base for atomics and images")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33352>
(cherry picked from commit fd874bdd0c)
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 2ffc05d8d2 ("panvk: Add support for CmdDispatchIndirect")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
(cherry picked from commit fe31e7843d)
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 447075eeee ("panfrost: Add support for the CSF job frontend")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
(cherry picked from commit 6bf9ad2610)
This change fixes the indirect draw 8-bits path which does
a conversion to 16-bits. This change is implemented to process
the parameters the same way as the other indirect draw paths.
This change was tested on palm and cayman. Here are the tests fixed:
deqp-gles31/functional/draw_indirect/draw_elements_indirect/indices/index_byte: fail pass
deqp-gles31/functional/draw_indirect/random/35: fail pass
deqp-gles31/functional/draw_indirect/random/45: fail pass
khr-gl40/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl41/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl42/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl43/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl44/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl45/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
Fixes: d80701df8a ("r600g: Implement GL_ARB_draw_indirect for EG/CM")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32802>
(cherry picked from commit 9aea08e1db)
Calculation was wrongly walking uncompacted instructions, even if we had
some compacted in the middle, generating invalid size. Since we are
here just drop the instruction count, since in practice the caller will
have to walk the instruction stream anyway.
Fixes: 6267585778 ("intel/brw: Also return the size of the assembled shader")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33532>
(cherry picked from commit dd1ca1588d)
After nir_lower_io we need to gather the info about 64 bit usage
to be up-to-date when deciding whether the remaining 64 bit IO ops
be lowered.
Before 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
the info was eventually updated to include the use of 64 bit values
also if only some IO was using this so that SFN was handling the code
correctly. As it seems with above patch this is not always the case
anymore, and we have to take care of it.
Fixes: 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32774>
(cherry picked from commit 6da19eafd5)
this is a nice idea, but there are apps/games that do not respect
hardware capabilities and yolo-bind fixed size buffers
fixes Ballionaire (2667120) launch on non-desktop drivers
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33819>
(cherry picked from commit b04eaa8589)
We would set the `src` flag on the interval of reloaded sources.
However, the interval might be merged with its parent when inserted and
the parent wouldn't have this flag set. This caused the parent interval
to potentially be reused to reload later sources. Fix this by setting
the `src` flag on the top-level interval after insertion.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33810>
(cherry picked from commit 2d540b8074)
Fixes: 692b5fa9f2 ("anv: Add shader to copy acceleration structures")
This commit fixes the future test "sparse_binding_structures" for
"header_bottom_address" for ray tracing pipeline.
Even on 48-bit ray tracing (Xe1/2), the software-defined part
instance_leaf_part1.bvh_ptr has to be in canonical form for copy.comp
to deference a bvh, which means we have to preserve the upper 16bits.
This is especially relevant in cases where the acceleration structure buffer
is located high, such as sparse buffer.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
(cherry picked from commit 87ff7b061f)
Fixes: 2fe57947e3 ("anv: Implement encode shader to fit in ANV BVH")
This commit resolves the failures in the future tests
"sparse_binding_structures" for rayquery. Sparse buffers' heaps are
located high, and since it's in canonical form, the higher 16bits are
all set to 1. However, the existing encoder did not expect any non-zero
values at the higher 16bits. As a result, the instance flags got
corrupted, causing most triangle tests to fail.
Thanks for Paulo providing insights about sparse buffer properties.
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
(cherry picked from commit b9a980ea73)
On vulkan, truncating to S/U16 before converting is not valid, because
out-of-range conversions are specified to be correctly rounded. IEEE 754
requires that out-of-range values round to ±inf with RTNE and ±F16_MAX
with RTZ.
On gl, truncating is valid for U16->F16, because out-of-range int->float
conversions are undefined behavior. For S16->F16, it is not valid
because S16_MAX < F16_MAX, so some in-range values will be truncated as
well.
Instead, just handle S/U16->F16 as S/U16->F32->F16.
Fixes dEQP-VK.spirv_assembly.instruction.compute.convertstof.int32_to_float16_*
when shaderFloat16 is enabled in panvk.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: be74b84e6f ("pan/bi: Fill in some more conversions")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33637>
(cherry picked from commit a33cd3def2)
If we insert
<code>
s_branch 1
s_branch Target
at the end of some block, and later hide an additional chained branch
after the existing one, then we have to update the 's_branch 1' to
also jump over the newly added branch.
Fixes: cab5639a09 ('aco/assembler: chain branches instead of emitting long jumps')
Closes: #12673
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33762>
(cherry picked from commit 6659db285a)
This is part of the hashing key :
==25753== Uninitialised byte(s) found during client check request
==25753== at 0x93D29AE: blob_write_bytes (blob.c:164)
==25753== by 0x93A62C6: vk_pipeline_precomp_shader_serialize (vk_pipeline.c:722)
==25753== by 0x93AC55E: vk_pipeline_cache_add_object (vk_pipeline_cache.c:433)
==25753== by 0x93A691B: vk_pipeline_precompile_shader (vk_pipeline.c:875)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
==25753== Address 0xf1adf82 is 82 bytes inside a block of size 152 alloc'd
==25753== at 0x64FA858: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==25753== by 0x99AAC38: vk_default_alloc (vk_alloc.c:26)
==25753== by 0x93A403B: vk_alloc (vk_alloc.h:48)
==25753== by 0x93A406B: vk_zalloc (vk_alloc.h:56)
==25753== by 0x93A60A0: vk_pipeline_precomp_shader_create (vk_pipeline.c:680)
==25753== by 0x93A689D: vk_pipeline_precompile_shader (vk_pipeline.c:866)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementations")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33792>
(cherry picked from commit 4dba1ad93f)
By actually setting the state packets according to the program data.
Also ensure that we correctly flag that the program may be dirty when
the geometry shader state changes
Fixes piglit tests: `spec@!opengl 3.2@gl-3.2-adj-prims * pv-first`
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33658>
(cherry picked from commit c33ebf09f5)
We never write the traversal shader address out to shader group handles,
so this is not necessary. On the flipside, it can cause conflicts if the
traversal shader is allocated in a range occupied by a replayed shader.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33711>
(cherry picked from commit 14b902c825)
Instead, only indicate that exec should be zero and do
so in the successive helper block. This allows to insert
the parallelcopies from logical phis directly before the
branch in break and continue blocks.
Totals from 56 (0.07% of 79377) affected shaders: (Navi31)
Latency: 2472367 -> 2472422 (+0.00%); split: -0.00%, +0.00%
InvThroughput: 253053 -> 253055 (+0.00%); split: -0.00%, +0.00%
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33527>
(cherry picked from commit 7f7c1d463a)
There is a spec issue about this to clarify this behavior, but the current
wording can be interpreted that the platform always lists all extensions
supported by all drivers.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33667>
(cherry picked from commit 0fd70ee9de)
Turns out we were missing the glapi bits, making it impossible to use get
the function pointers for this extension. Whoops?!
[daniels: Squashed in a618 SkQP fails, presumably caused by these not
being skipped anymore.]
Fixes: 9f5af68995 ("mesa/main: expose `EXT_multi_draw_indirect`")
Reviewed-by: Antonino Maniscalco <antomani103@gmail.com>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33546>
(cherry picked from commit fde6aeb886)
These are persistant objects that you can use to signal and wait over.
We need to import without VK_SEMAPHORE_IMPORT_TEMPORARY_BIT and we can't
throw away the Vulkan semaphore after each submit.
Fixes: 32597e116d ("zink: implement GL semaphores")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
(cherry picked from commit 651864151f)
When the size of the signals[] array was changed to 3, the
signal_values[] array was not updated accordingly. If we have a
signal_semaphore and are presenting at the same time, this can lead to
an array overflow and the driver will read some random stack value as
the signal value. This is causing chromium to lock up when running
WebGL.
Fixes: 7f56fd9655 ("zink: it's kopperin' time")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
(cherry picked from commit 1ffa782227)
Implementing alpha-to-coverage dithering broke the non-dithering case.
(Discovered by accident, not really a big deal since it's almost always
enabled and can only be disabled by using a Nvidia GL extension, and
can't be disabled with Vulkan.)
Fixes: ad4635d6ef
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33586>
(cherry picked from commit 61911b6a4b)
Using memcpy with the max size generates a global-buffer-overflow, as
the performance counter strings are smaller than the max size.
Instead, use a string copy function to get a copy.
This was detected with address sanitizer enabled and running vulkaninfo.
Fixes: 3e8b2fe053 ("broadcom/simulator: Add DRM_IOCTL_V3D_GET_COUNTER to simulator")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33627>
(cherry picked from commit 2d91798561)
We can't use the local variable key to insert in the hashtable, as the
key needs to be persistent for future searches.
This makes a copy of the key in the pipeline, which is kept persistent
in the hashtable.
This fixes a stack-buffer-overflow.
Backport-to: 25.0
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33630>
(cherry picked from commit eb8017ca68)
_mesa_make_current will use st_flush(ctx) to execute pending
commands before switching to the new context.
Since we can't have multiple threads using a pipe_context at
the same time, we must finish glthread to avoid having the
unmarshalling thread executing at the same time.
It's fixing random crashes where a thread would do:
st_destroy_context ->
_mesa_make_current ->
st_glFlush(save_ctx) ->
tc_execute_batch
While there's a glthread unmarshalling thread that's still
adding commands to TC.
Fixes: 08d97aadd1 ("st/mesa: fix texture deletion context mix-up issues (v2)")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33552>
(cherry picked from commit f062c83f3a)
Validation was checking that if an instruction was accessing FAU RAM,
only one 64-bit slot was accessed, and if it was accessing a FAU special
value, only one was accessed, however it was not checking if both RAM
and special were used, which is only allowed in messaging instructions
except ATEST and BLEND.
Fixes Piglit:
spec/ati_fragment_shader/ati_fragment_shader-render-ops/mov c0.r
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Fixes: fd1906afea ("pan/va: Add FAU validation")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33608>
(cherry picked from commit e504825813)
Previously deqp tests with *.multisampled_image_sparse_residency.* would
crash with "Unknown image intrinsic" because
nir_intrinsic_bindless_image_sparse_load was not handled in the lowring
code.
This commits handles MSAA sparse residency lowering as with other cases.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Fixes: 7604697ec6 ("nvk: Implement shaderStorageImageMultisample")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33625>
(cherry picked from commit bce9e851c6)
Add support for GL_OVR_multiview's GL_MAX_VIEWS_OVR which can be
accessed with glGetIntegerv().
MaxViews is accessed via the hash table set up by get_hash_params.py as
a constant (MAX_VIEWS_OVR) using GL_MAX_VIEWS_OVR.
v2: Add this patch (thanks to Mike's guidance)
v3: Drop unnecessary enum size element in OVR_multiview.XML
v4: Switch to CONST(MAX_VIEWS_OVR) instead of gl_constants::MaxViews
(Marek's suggestion)
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit be106bd6c6)
Implement the OVR_multiview framebuffer attachment parameters in
get_framebuffer_attachment_parameter():
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR: This reads the
attachment's NumViews.
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR: This reads the
attachment's Zoffset, but only if NumViews is non-zero.
This allows apitrace (PR 937[1]) to show the correct layers for
multiview framebuffer attachment surfaces, as well as to show this
information in the framebuffer attachments state.
[1]: https://github.com/apitrace/apitrace/pull/937
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit a282a130fb)
The OVR_multiview spec specifies the INVALID_VALUE error to be generated
by FramebufferTextureMultiviewOVR if:
"- <texture> is a two-dimensional array texture and <baseViewIndex> +
<numViews> is larger than the value of MAX_ARRAY_TEXTURE_LAYERS."
Implement this in check_multiview_texture_target(), similar to the test
in check_layer().
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 60509e187f)
The OVR_multiview spec adds the following condition for framebuffer
completeness:
"The number of views is the same for all populated attachments.
{ FRAMEBUFFER_INCOMPLETE_VIEW_TARGETS_OVR }"
So add a condition to _mesa_test_framebuffer_completeness to check that
all attachments have identical NumViews. This avoids an infinite
recursion between zink_clear() and zink_clear_depth_stencil() in the
event of an incomplete FBO.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 7819d322c4)
NumViews needs considering along with the other attachment data when
reusing a multiview framebuffer texture attachment (i.e. shared depth
and stencil texture).
The depth and stencil attachments should match in all respects including
NumViews before reusing the existing one, and NumViews should also be
copied when reusing.
This avoids an infinite recursion between zink_clear() and
zink_clear_depth_stencil() in the case of reuse of a multiview
depth/stencil attachment.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 65f18c4787)
In 2183bc73a6 ("nvk: Use suld for EDB uniform texel buffers"), we
started using suld instead of tld for EDB uniform texel buffers because
we needed it for correctness. However, it's slow as mud. Using
suld.constant seems to fix the performance regression. I don't know if
it's quite tld performance, but it's close.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
(cherry picked from commit eb27cbf25a)
This is way faster than suld.sys, which is what we're using today. So
far I haven't seen it matter for anything but texel buffers but it
likely helps some app somewhere.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
(cherry picked from commit ffdc0d8e98)
This should never happen as the client should always give us aligned
addresses. However, in the off chance that it does, aligning down is
probably safer than aligning up as it won't cause the top end of the
range increase and potentially fault.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit 5762586c6d)
The tricks we play for texel buffers with VK_EXT_descriptor_buffer don't
work with tld with very large buffers. suld, on the other hand, doesn't
seem to have these limitations.
Fixes: 3b94c5c22a ("nvk: Lower descriptors for VK_EXT_descriptor_buffer buffer views")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit 2183bc73a6)
We can theoretically hit this if CmdProcessGeneratedCommandsEXT is
called with a state command buffer that doesn't have compute shader set
if execute commands bind a shader. We do, however, need to still call
nvk_cmd_upload_qmd() because it also uploads push constants and we need
those regardless of whether or not there's a shader bound.
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit ca06a57702)
Since Xe2, the registers are bigger and even the instruction
structures got updated to have 6 bits.
The way I detected this issue was when I tried to use
src/intel/executor to add the following instruction:
add(8) g6.8<1>UD g4<8,8,1>UD 0x00000008UD { align1 WE_all 1Q I@1 };
Executor would read this and end up emitting an add with dst being
g6<1>UD instead of what we wanted. It turns out that inside
brw_gram.y, at dstoperand and dstoperandex we do:
$$.subnr = $$.subnr * brw_type_size_bytes($4);
which would overflow subnr back to 0.
The overflow doesn't seem to be a problem with code we emit directly
(unlike the code we parse, like above) due to the fact that we seem to
treat Xe2 registers as smaller all the way until we call phys_nr() and
phys_subnr() during code generation. The phys_subnr() function can
generate a value that would overflow reg.subnr, but this value is
never written back to reg.subnr, it's just returned as an unsigned
int.
Fixes: e9f63df2f2 ("intel/dev: Enable LNL PCI IDs without INTEL_FORCE_PROBE")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33539>
(cherry picked from commit 927d7b322b)
For decode this is also done in decode_video.
This breaks if app doesn't call vkCmdEncodeVideoKHR before end, eg:
vkCmdBeginVideoCodingKHR
vkCmdControlVideoCodingKHR
vkCmdEndVideoCodingKHR
Cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33582>
(cherry picked from commit ebd8893710)
Apparently fast path cannot handle mismatched mutability and we
should use CP_BLIT which has SP_PS_2D_SRC_INFO.MUTABLEEN to signal
src mutability. Previously it was partially handled by
tu_attachment_store_mismatched_swap.
Fixes: a104a7ca1a
("tu: Handle non-identity GMEM swaps when resolving")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33514>
(cherry picked from commit 97f851e7c5)
This is part of VK_EXT_mutable_descriptor_type but we never did anything
with it. Since we use local memory for descriptor sets, copying from
them means reading VRAM through a WC map and it's pretty expensive.
Using malloc() for HOST_ONLY should be a nice perf boost for things
which give us the hint.
This massively improves the performance Dragon Age: The Veilguard,
taking it from 7 FPS to 25 FPS on an RTX 4060.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12622
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33571>
(cherry picked from commit 607686f6bf)
More are found missed from prior maint5 support. This change has
properly initialized the maint5 props as well as fixing its new
VkPipelineCreateFlags2CreateInfo integrations.
Verified with dEQP-VK.*maintenance5*
Fixes: be6fece6e1 ("venus: enable VK_KHR_maintenance5")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33566>
(cherry picked from commit 8741be3365)
This is not conformant and it can cause hard to debug issues or hide
existing bugs. Getting rid of this limit will allow lavapipe to use the
common bvh building framework since the ploc build shader has a loop
that waits to start the next phase.
cc: mesa-stable
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31426>
(cherry picked from commit ac0f643d4b)
iceil can return bogus (negative) values in case there's an overflow
(or a NaN). This would then take forever to run due to a couple billion
loop iterations.
Use unsigned minimum instead which will clamp iterations to max aniso
(not sure if that makes more sense than clamping negative values to 0,
probably doesn't really matter).
Fixes: 350a0fe632 ("llvmpipe: Use a simpler and faster AF implementation")
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33537>
(cherry picked from commit 24076eb3f9)
Previously DGC alignment requirements declared by
getGeneratedCommandsMemoryRequirementsExt were not also reported by
getDeviceBufferMemoryRequirements for preprocess buffers.
This fixes 1554 dEQP-VK failures related to device-generated commands
that previously failed with "DGC alignment requirement larger than
preprocess buffer alignment requirement".
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33555>
(cherry picked from commit cc30e35306)
This will be needed in order to check off passing the VK CTS properly.
Please note, this does *not* mean that we are formally conformant, only
that we have passed the VK CTS at least once. Those are not the same
thing.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33254>
(cherry picked from commit 2653a3988f)
bi_opt_mod_prop_backward tries to propagate values backwards, but
stops checking for uses when it reaches the SSA definition. For
ordinary blocks that's fine, but for loops the definition can come
after a PHI that uses the value. This causes incorrect code to be
generated in shaderdb test `shaders/skia/2134.shader_test`. Fix this
by special casing PHI instructions, in a manner similar to done in
asahi/compiler/agx_optimizer.c.
This bug has been present a long time, so we want it back-ported to
stable.
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33483>
(cherry picked from commit 18a14c4522)
It turns out that the change from CENTER_Y to CENTER_X for
422 YUV didn't actually happen until generation 14 of the
hardware, not generation 10 as some documents claimed. This
fixes the failing piglit tests ext_image_dma_buf_import-sample_yuv
associated with 422 formats (which apparently we aren't running on CI).
Fixes: 23aa784c
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33516>
(cherry picked from commit c7fed8b053)
init_queue() calls cleanup_queue() if anything fails in the middle, which
means finish_render_desc_ringbuf() will be automatically called if
init_render_desc_ringbuf() failed. Get rid of the the error path and
return directly instead. The one exception we have is the dev_addr
allocation, which needs to be explicitly freed if an error occurs between
util_vma_heap_alloc() and pan_kmod_vm_bind().
Reported-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33471>
(cherry picked from commit 5f3c6a0f27)
This code is old, copied from the old nouveau GL driver. As of Pascal,
we have have 32k images so we need 32k scissors as well. Use the
max_image_dimension() helper instead of hard-coding it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33478>
(cherry picked from commit 6f64962f27)
Indeed, has_atomics is not yet initialized at the time of the
call of r600_init_shader_caps(). This change fixes this issue.
For instance, this issue is triggered with
"piglit/bin/clearbuffer-depth-cs-probe -auto -fbo":
clearbuffer-depth-cs-probe: ../src/gallium/drivers/r600/evergreen_state.c:5039: evergreen_emit_atomic_buffer_setup: Assertion `resource' failed.
Aborted
Fixes: 7cd606f01b ("r600: add r600_init_screen_caps")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33438>
(cherry picked from commit bb44052ee9)
Add current time when generating the stream handle initial value.
When running inside PID namespace there can be multiple processes
in the system that will share the same PID and with current code
this could result in the same stream handle being used at the same
time from different processes.
This can easily happen with Flatpak when running two instances of the
same application - both processes will have the same PID and we
will use the same stream handles.
For older UVDs kernel will reject the CS if we use duplicated handles.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12575
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33374>
(cherry picked from commit fdf747af3a)
The offset is measured in bytes. Some of the code here acted as though
it were measured in src.type units. Also modify the assertion to check
that all extracted bits come from data in the immediate value.
Fixes: 580e1c592d ("intel/brw: Introduce a new SSA-based copy propagation pass")
Fixes: da395e6985 ("intel/brw: Fix extract_imm for subregion reads of 64-bit immediates")
Yes, I missed this error *twice* in code review.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33049>
(cherry picked from commit ac4b93571c)
Command buffer private object destroy callbacks receive a 64-integer so their
signature should respect that to avoid alignment issues when passing pointers.
This is the same we were already doing for color pipelines, but now for D/S
pipelines too.
Fixes crash on 32-bit build with:
dEQP-VK.synchronization2.op.single_queue.fence.write_clear_attachments_read_copy_image_to_buffer.image_128x128_d16_unorm
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33463>
(cherry picked from commit daa48cbaef)
Since the binding value can be any 32-bit number, we cannot assume that
it is <= 27 bits. We need 64-bit keys to accommodate a 32-bit binding.
This will also provide more bits to store the subdesc id, which will be
needed for multiplane texture and sampler descriptors.
Fixes: 7bea6f86 ("panvk: Overhaul the Bifrost descriptor set implementation")
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32563>
(cherry picked from commit 9c4b530c49)
On armhf integer divide by 0 can raise SIGFPE, whereas on aarch64
it just returns 0. This has become an issue because the recently
added panfrost_init_screen_caps always calls pan_gpu_time_to_ns to
calculate caps->timer_resolution, whereas before we only called it
when PIPE_CAP_TIMER_RESOLUTION was queried, and only OpenCL
does that (and not always).
Fixes: 205669e3a9 ("panfrost: add panfrost_init_screen_caps")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33435>
(cherry picked from commit e550a3cab0)
Prevent following warning if not running as a normal user:
Failed to create /home for shader cache (Permission denied)---disabling
disk_cache_delete_old_cache() is going to create first the cache directory
using disk_cache_generate_cache_dir(). From mkdir_if_needed(), the stat()
of "/home" is failing with "Permission denied" under some circumstances
when using Firefox.
Fixes: #12168
Fixes: c3bc6991d2 ("util/disk_cache: Delete the old multifile cache if using the default.")
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32886>
(cherry picked from commit 622f7407d7)
The release branch contains only what was on the staging branch first,
so testing it again is a waste of resources.
To do this, we split the rule into specifically "default branch" and
"staging branch", and "release branch" gets dropped by virtue of no
longer being caught by any rule.
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33411>
(cherry picked from commit 7152f343d6)
It's too late to run all the tests by then, the release has been made
based on the staging pipelines results
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33409>
(cherry picked from commit 31f0a9be3f)
It's unclear to me whether this is dead code that should be removed or
dead code that should be used, so I just marked it as unused to remove
a few thousand warnings when compiling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33384>
(cherry picked from commit 93a720f81a)
The fix in e7ac1094f6 to emit preamble defs in the correct block would
move the cursor of the builder that is later used to insert descriptor
prefetches, emitting them at the wrong place. Fix this by resetting the
cursor before emitting the prefetches.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: e7ac1094f6 ("ir3: rematerialize preamble defs in block dominated by sources")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33399>
(cherry picked from commit 8404e7428b)
This switches to disk_cache instead of our own mechanism which only
stored meta shaders when the logical was destroyed.
Meta shaders are still stored separately from the application shaders
because they are common to all applications on a given GPU/Mesa version.
The default cache is 32MiB which should be large enough.
This fixes massive stuttering in FF7 Rebirth but all apps are
technically affected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33405>
These have been switching between failing and passing recently. Not
really sure what's going on here, but we don't want the CI to flip
randomly between failing and passing, so let's mark them as flakes.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33381>
(cherry picked from commit 4d86a1c928)
Vulkan defines the line rasterization to *always* use perpendicular
rather than aligned line ends (unless otherwise specified by
VK_EXT_line_rasterization). So let's remove the code that conditionally
sets the bit, we always want the default value (0) here.
It might seem confusing because we kinda named this field wrong. It's
really about perpendicular vs aligned line ends. That's a cleanup we
might want to deal with later, but deleting the assignment is sufficient
to fix this issue. This is also what we do for v10.
This was probably just copied from the Gallium-driver, where this logic
is more or less correct.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33373>
(cherry picked from commit 1d64095410)
The check in check_multiview_texture_target() whether numViews <= 0 (as
required by the OVR_multiview spec) is never triggered since it is only
called by frame_buffer_texture() when numviews > 1, as numviews of 0 is
passed in by non multiview FramebufferTexture functions. Such cases are
incorrectly treated as non-multiview attachments.
Tweak frame_buffer_texture() to take an extra bool argument "multiview"
to distinguish between a multiview call with numviews=0, and a
non-multiview call.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
(cherry picked from commit 7f493b45ae)
Fix the FBO attachment completeness test to ensure that multiview
attachments have all views referring to layers in range of the
underlying texture.
The OVR_multiview spec states:
Add the following to the list of conditions required for framebuffer
attachment completeness in section 9.4.1 (Framebuffer Attachment
Completeness):
"If <image> is a two-dimensional array and the attachment
is multiview, all the selected layers, [<baseViewIndex>,
<baseViewIndex> + <numViews>), are less than the layer count of the
texture."
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
(cherry picked from commit 39491da1b6)
if there is no heap with device-local and host-visible, then
rebar cannot exist. the previous detection did not account for
the rebar heap using the device-local fallback, which of course
would have the same size as the device-local heap and pass the threshold
check
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33359>
(cherry picked from commit 3064bfc312)
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.
