Our validation code doesn't need to know which bytes are accessed. It
only needs to know which grfs were accessed by an element. This also
helps to easily handle the Xe2 register size change.
Backport-to: 24.2
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28479>
(cherry picked from commit 58469620d3)
Previously this check would create a mask of the bytes used in the
grf, and then shift the mask. This worked well when there was 32 bytes
in the register because a 64-bit uint64_t could easily detect that
bytes were used in the next regiter. (The next register was the high
32-bits of the `access_mask` variable.)
With Xe2, the register size becomes 64 bytes, meaning this strategy
doesn't work. Instead of a mask, we can just check to see if more than
1 grfs are used during each loop iteration. (Suggested by Ken.) This
will make it easier to extend for Xe2 in a follow on commit.
Verified this with
dEQP-VK.subgroups.arithmetic.compute.subgroupexclusivemul_u64vec4_requiredsubgroupsize
on Xe2, which otherwise would cause the program to fail to validate
because it assumed a grf was 32 bytes.
Backport-to: 24.2
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28479>
(cherry picked from commit f2800deacb)
previously the size was checked at the top of the function, but this
ignored cases where the loader might end up resizing the drawable,
resulting in an attempted 0x0 swapchain creation based on stale
geometry
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30487>
(cherry picked from commit a6d97b0afe)
Transfer ops also use CCHE since they use the same path as
texture access.
This addresses the flakiness seen in
KHR-GL46.shader_storage_buffer_object.advanced-usage-sync-cs
CCHE wasn't being invalidated between the compute op and transfer
op which would sometimes lead to old/invalid data to be copied
in the transfer op.
Fixes: fb1c3f7f5d ("tu: Implement CCHE invalidation")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11458
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30490>
(cherry picked from commit cf9588bae6)
The user is allowed to pass a list of modifiers including
DRM_FORMAT_MOD_INVALID, meaning that the user is OK with implicit
modifiers. Since merging the DRI interfaces, this assert that we are
never returning an implicit modifier is unnecessary and also wrong. It
was originally added to be super-safe, but we now know that our drivers
work very well with modifiers, so don't need it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 0b16d7ebb9 ("dri: Allow INVALID for modifier-less drivers")
Closes: mesa/mesa#11591
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30464>
(cherry picked from commit cd961a7e3f)
this has always called loader_bind_extensions, so it should have been
linking with the loader
cc: mesa-stable
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reported-by: Yurii Kolesnykov <root@yurikoles.com>
Tested-by: Yurii Kolesnykov <root@yurikoles.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30449>
(cherry picked from commit 827812912d)
The iova allocations need to be CPU page aligned. (The GPU itself
always supports 4k mappings regardless of the smallest CPU page size,
but GEM buffer allocations must be an integer number of CPU pages.)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fixes: 63904240f2 ("tu: Re-enable bufferDeviceAddressCaptureReplay")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30431>
(cherry picked from commit 7fe3529715)
Not everyone has a copy class, so don't dereference it if it's not
set.
Pointed out on irc by Armada
Fixes: 65092ab1a5 ("nouveau/nvc0: add support for using common pushbuf dumper")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30421>
(cherry picked from commit 56ea4e4fa6)
The condition of flat ccs and vram_only checker causes different
aux usage at binding stage. The current design is reusing CCS_E
on Xe2, so we want both Xe2 integrated and discreted GPUs behave
the same way.
Xe2 shouldn't need any special setup of CCS in the loop.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
(cherry picked from commit c5ee7e9bdc)
On pre-Xe2 platforms, the compression on these modifiers that
don't support compression are enabled. The compressed will be
resolved when needed. On Xe2+ we haven't support explicit
resolve, so all the paths to resolves are prohibited now. But
the code is still doing it, causing an assertion failure:
Fixes: vkcube
src/intel/vulkan/anv_private.h:5467:
anv_image_get_fast_clear_type_addr: Assertion
`device->info->ver < 20' failed.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
(cherry picked from commit e054068787)
This reverts commit e9f63df2f2 for Mesa
24.2.
According to Lucas, the kernel will be knowingly breaking Mesa's LNL
support in Linux 6.11. The kernel will not commit to not break LNL for
user-mode drivers until force_probe is removed, which might mean
waiting until Linux 6.12.
"There's no support really in kernel 6.10, 6.11 etc to LNL."
* https://lists.freedesktop.org/archives/intel-xe/2024-July/043706.html
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30398>
