has_work controls whether a flush can be deferred, i.e., when unset
a flush may be deferred
since a promoted cmd must still be flushed to take effect, ensure this
is always set when promoted cmds are pending
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 0f510040dc)
when needs_present_readback is set, reordering is disabled without hitting
the path that would normally disable promotion for the resource, so this
needs to be changed manually to avoid layout desync on the swapchain
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 3c010319bb)
in a scenario where an ordered read op occurs for an image,
successive read-only barriers SHOULD be able to be promoted
...but they can't, because there isn't yet a mechanism for handling layout
transitions between the unordered cmdbuf and the ordered cmdbuf,
meaning that promoting e.g., a SHADER_READ_ONLY barrier after a TRANSFER_SRC
barrier will leave the image with the wrong layout for the transfer op:
TRANSFER_SRC(unordered) -> COPY(ordered) -> SHADER_READ_ONLY(unordered)
becomes
TRANSFER_SRC(unordered) -> SHADER_READ_ONLY(unordered) -> COPY(ordered)
ideally I'll get around to figuring this out at some point
affects:
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.r32i_r32i.texture2d_array_to_renderbuffer
Fixes: bf0af0f8ed ("zink: move all barrier-related functions to c++")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 9c8b6754b0)
in the case where a draw is triggered after a flush, zink_update_descriptor_refs
will be called to set batch tracking for descriptors. this function also
handles refs for fb attachments, and everything is usually fine there
the problem with this approach is that tracking is no longer set on view
objects at renderpass begin, which makes them susceptible to early deletion
if a rp isn't started from a draw call
instead, apply batch tracking to fb attachment resources on renderpass
begin if the BATCH_CHANGED flag is set (need to rename this at some point)
in order to guarantee that the resource (object) lifetime will match the
cmdbuf runtime [since imageviews are now only freed upon batch completion]
fixes#9059
Fixes: f6bbd7875a ("zink: remove batch tracking/usage from view types"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23132>
(cherry picked from commit 62961b172f)
Yuzu is running into a segfault because it writes the push descriptor
twice with 2 different layouts, but without a draw/dispatch in
between.
First vkCmdPushDescriptorSetKHR() writes descriptor 0 & 1 with a
uniform buffer. We toggle the 2 first bits of
anv_descriptor_set::generate_surface_states.
Second vkCmdPushDescriptorSetKHR() writes descriptor 0 with uniform
buffer and descriptor 1 with an image view. The first bit of
anv_descriptor_set::generate_surface_states stays, but the second bit
was already set before and it should now be off.
When we finally flush the push descriptor, we try to generate a
surface state for descriptor 1, but there is no valid buffer view for
it, we access an invalid pointer and segfault.
This fix resets the anv_descriptor_set::generate_surface_states when
the descriptor layout changes.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b49b18f0b7 ("anv: reduce BT emissions & surface state writes with push descriptors")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23156>
(cherry picked from commit cab7ba00e2)
-1 is a legit vertex offset upon vkCmdDrawIndexed and other cmds. This
change fixes to track last_vertex_offset with an additional valid bit.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23157>
(cherry picked from commit 4c8be22c66)
This shouldn't have been enabled at all. Depth-stencil formats were
accidentally disabled but not depth-only or stencil-only formats.
This doesn't seem allowed by DX12 and both AMD/NVIDIA don't enable it.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23122>
(cherry picked from commit dda7400c0b)
Super sampling on a 4K screen could hit this. 16k seems pretty big
but this image is only created on RDNA2 and on-demand if VRS attachments
are used without depth-stencil attachments, which should be rare
enough to care.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23105>
(cherry picked from commit 3adc9b6722)
We only support 32-bit versions of ufind_msb, find_lsb, and bit_count,
so we need to lower them via nir_lower_int64.
Previously, we were failing to do so on platforms older than Icelake
and let those operations fall through to nir_lower_bit_size, which
used a callback to determine it should lower them for bit_size != 32.
However, that pass only emulates small bit-size operations by promoting
them to supported, larger bit-sizes (i.e. 16-bit using 32-bit). It
doesn't support emulating larger operations (i.e. 64-bit using 32-bit).
So nir_lower_bit_size would just u2u32 the 64-bit source, causing us to
flat ignore half of the bits.
Commit 78a195f252 (intel/compiler: Postpone most int64 lowering to
brw_postprocess_nir) provoked this bug on Icelake and later as well,
by moving the nir_lower_int64 handling for ufind_msb until late in
compilation, allowing it to reach nir_lower_bit_size which broke it.
To fix this, we always set int64 lowering for these opcodes, and also
correct the nir_lower_bit_size callback to ignore 64-bit operations.
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23123>
(cherry picked from commit a2d384a5c0)
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT is also set in all memory types of
integrated GPUs.
This flag means that memory will be allocated in the most efficient
place for the GPU to access, which is true in integrated GPUs.
However, this was causing ANV_BO_ALLOC_WRITE_COMBINE to be set in
integrated GPUs in the block right below when allocating in the non-cached memory type.
But the comment only talks about lmem, so to still keep the write
combine behavior for iGPUs it was used VkMemoryPropertyFlags in mmap_calc_flags().
Additionally, this was causing anv_bo.has_implicit_ccs to always be
set, which could change the expected behavior of
anv_BindImageMemory2() in MTL.
Fixes: fbd32a04da ("anv: add a third memory type for LLC configuration") added a new heap
Fixes: 582bf4d9f7 ("anv: flag BO for write combine when CPU visible and potentially in lmem")
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/22483>
(cherry picked from commit a6c5746b37)
On RDNA1&2, the driver needs to support both NGG and legacy for
primitives generated query because we can't know that before starting
queries.
To get the query pool results, we check the availability bit wrote by
the SAMPLE_STREAMOUTSTATS packet but the GDS copy was emitted after,
which means the availability bit might be TRUE before the GDS copy is
actually done.
Fix this by emitting the GDS copy before to ensure the availability is
TRUE for both results.
This fixes recent updates in
dEQP-VK.transform_feedback.primitives_generated_query.* because the
tests no longer wait for the fence.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23080>
(cherry picked from commit 9ba41ed70a)
Commit c65bde7b1e introduced a regression where under certain
circumstances `front` may be NULL, thus leading to a crash. It's not
currently known what exactly causes `front` to become NULL, nor we can
revert the offending commit, because there had been too many unrelated
changes that now depend on this commit.
So until someone comes up with a proper fix, let's add a workaround so
instead of crashing we just return from the function early.
This commit was tested with the bug `8982` and helps with the crash
with no other noticeable problems.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8982
Fixes: c65bde7b1e ("frontend/dri: inline __DRIdrawable in dri_drawable, make __DRIdrawable opaque")
Cc: mesa-stable
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23093>
(cherry picked from commit 275cf62e20)
Most of the compressed writes are tracked by the driver, for
instances :
- blorp writes
- render target writes
But we don't have any tracking for storage images (which have gained
compression support on DG2+). So inspect the layout transition and
when we see a layout/access that can do writes outside of our driver
tracking, update the image state tracking.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8946
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22988>
(cherry picked from commit 1a89b1a301)
Not doing so all the reads/writes go to the scratch page on i915.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f9fa09ec92 ("anv/image: Add ANV_IMAGE_MEMORY_BINDING_PRIVATE")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22957>
(cherry picked from commit 7f7b2fc53a)
0x5698 is now reserved for future use
From Matt Roper in linux
3a38be31ec82 ("drm/i915/dg2: Drop one PCI ID")
Fixes: 65c9a810ee ("intel/pci_ids: Add dg2 0x5698 pci-id")
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22985>
(cherry picked from commit af0f7b3475)
Then we can guarantee the settings correct, otherwise the 'screen->info.have_EXT_extended_dynamic_state3 = false' and 'screen->info.have_EXT_vertex_input_dynamic_state = false'
will be enable, but actually we should disable it when 'have_EXT_extended_dynamic_state2 = false'.
Fixes: d5cf6f7d2f ("zink: disable dynamic state exts if the previous ones aren't present")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23046>
(cherry picked from commit 47f0801949)
This change is inspired from iris_destroy_context().
For instance, this issue is triggered with
"piglit/bin/glsl-1.50-gs-max-output -scan 1 20 -auto -fbo":
Direct leak of 320 byte(s) in 2 object(s) allocated from:
#0 0x7f34fc769987 in calloc (/usr/lib64/libasan.so.6+0xb1987)
#1 0x7f34f4fa168a in bo_calloc ../src/gallium/drivers/crocus/crocus_bufmgr.c:288
#2 0x7f34f4fa168a in alloc_fresh_bo ../src/gallium/drivers/crocus/crocus_bufmgr.c:350
#3 0x7f34f4fa168a in bo_alloc_internal ../src/gallium/drivers/crocus/crocus_bufmgr.c:419
#4 0x7f34f4fe50a9 in crocus_get_scratch_space ../src/gallium/drivers/crocus/crocus_program.c:2678
#5 0x7f34f55e8954 in crocus_upload_dirty_render_state ../src/gallium/drivers/crocus/crocus_state.c:6871
#6 0x7f34f55e8954 in crocus_upload_render_state ../src/gallium/drivers/crocus/crocus_state.c:7812
#7 0x7f34f5d9f680 in crocus_simple_draw_vbo ../src/gallium/drivers/crocus/crocus_draw.c:332
#8 0x7f34f5d9f680 in crocus_draw_vbo ../src/gallium/drivers/crocus/crocus_draw.c:438
#9 0x7f34f1d2eeba in tc_call_draw_single ../src/gallium/auxiliary/util/u_threaded_context.c:3735
#10 0x7f34f1d12e03 in batch_execute ../src/gallium/auxiliary/util/u_threaded_context.c:394
#11 0x7f34f1d12e03 in tc_batch_execute ../src/gallium/auxiliary/util/u_threaded_context.c:445
#12 0x7f34f1d22c9a in _tc_sync ../src/gallium/auxiliary/util/u_threaded_context.c:680
#13 0x7f34f1d238f8 in tc_texture_map ../src/gallium/auxiliary/util/u_threaded_context.c:2754
#14 0x7f34f120b9d9 in pipe_texture_map_3d ../src/gallium/auxiliary/util/u_inlines.h:579
#15 0x7f34f120b9d9 in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:530
#16 0x7f34f10d7355 in read_pixels ../src/mesa/main/readpix.c:1178
#17 0x7f34f10d7355 in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1195
#18 0x7f34f10d7e10 in _mesa_ReadPixels ../src/mesa/main/readpix.c:1210
Fixes: f3630548f1 ("f3630548f1da crocus: initial gallium driver for Intel gfx 4-7")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23019>
(cherry picked from commit 6ee0bba3ae)
while swapchains themselves are protected against early deletion
during presentation, there is nothing protecting them from
deletion while they are rendering if a swapchain updates
while rendering but before presentation
to address this, add batch usage to swapchains which can be
checked during pruning to ensure a rendering swapchain isn't
pruned
Fixes: dc8c9d2056 ("zink: prune old swapchains on present")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22962>
(cherry picked from commit 47d9eaa0f1)
some resources may not be destroyed immediately and may instead be
queued for deletion onto the current batch state, so ensure that the
current state is the last one to be destroyed so that all deferred resources
are also destroyed
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23033>
(cherry picked from commit 58532057c5)
The helper was creating input locations for some builtin bariables.
This caused validation errors in zink because those builtins can't be
used as input.
Fixes: e2220ee55e ("zink: filled quad emulation gs generation function")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22871>
(cherry picked from commit 71107b6dc8)
The helper was creating input locations for some builtin bariables.
This caused validation errors in zink because those builtins can't be
used as input.
Fixes: d0342e28b3 ("nir: Add helper to create passthrough GS shader")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22871>
(cherry picked from commit 83692bfe30)
Previously, we could safely read/write unused lanes of VMEM/DS
destination VGPRs without waiting for the load to finish. That doesn't
seem to be the case on GFX11.
fossil-db (gfx1100):
Totals from 6698 (4.94% of 135636) affected shaders:
Instrs: 11184274 -> 11199420 (+0.14%); split: -0.00%, +0.14%
CodeSize: 57578344 -> 57638928 (+0.11%); split: -0.00%, +0.11%
Latency: 198348808 -> 198382472 (+0.02%); split: -0.00%, +0.02%
InvThroughput: 24376324 -> 24378439 (+0.01%); split: -0.00%, +0.01%
VClause: 192420 -> 192559 (+0.07%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8722
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8239
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22965>
(cherry picked from commit 88f6d7f4bd)
If either dest or src is an invalid or null pointer, the behavior is
undefined, even if count is zero.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22979>
(cherry picked from commit 5b31039033)
With the shader cache enabled, intel_clc attempts to write to ~/.cache.
Many distributions' build systems limit file-system access, and will
kill the process thus causing the build to fail.
Fixes: 639665053f ("anv/grl: Build OpenCL kernels")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22968>
(cherry picked from commit 435a607909)
