Quoting the documentation :
"The returned range is a half-open interval where all of the
addresses within the subimage are < end_tile_B."
This is obviously not true with images smaller than a logical tile.
Currently the code return 1.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24276>
(cherry picked from commit bcc820950d)
When the VkBuffer is of size 2^32 (which matches maxBufferSize), we
have vm_bind->size set to 2^32, which is fine because it fits in an
uint64_t. What is not fine is the 'i' variable being size_t, because
on 32bit systems it will loop forever since it will always be smaller
than 2^32.
Credits to Iván for not only reporting it, but also coming up with the
solution at the same time as I did, then testing it.
Cc: mesa-stable
Reported-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31698>
(cherry picked from commit da396a49a0)
When creating and caching the bo_export object for a given zink_bo, the
screen file descriptor was used. Since no buffer object's file descriptor
would match that, bo_export objects were continuously added to the exports
list and no bo_export was effectively picked from the cache. Using the
buffer object's file descriptor avoids that.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: b0fe621459 ("zink: add back kms handling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31715>
(cherry picked from commit b44480e86a)
The geometry BO should be released in csf_cleanup_context().
Fixes: 447075eeee ("panfrost: Add support for the CSF job frontend")
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/31705>
(cherry picked from commit 3d066e5ef1)
When flushing the render target cache for future operations, we need a
stall at pixel scoreboard. We likely didn't see any issue until now
because a change in render target added the pb-stall.
When using a 2 compute shaders with the following pattern :
vkCmdDispatch()
vkCmdPipelineBarrier() ImageBarrier with (src|dst)AccessMask=0 & identical layout
vkCmdDispatch()
we should ensure that the first dispatch is completed before executing
the second one, otherwise they can race to on resource accesses. This
fixes failures in some new CTS tests.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31676>
(cherry picked from commit ea2bbe3271)
This change enforces stricter swizzle behavior for the virtual scalar x
register, addressing a regression encountered in piglit's
spec@glsl-1.10@execution@derivatives@glsl-derivs-abs-sign test.
The regression occurred after switching to derivative intrinsics.
CC: mesa-stable
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31034>
(cherry picked from commit 5a15b36a64)
We're missing a check for 'result' in the middle of a loop and we have
an unnecessary check for 'result' after the loop.
Fixes: 7da5b1caef ("anv: move trtt submissions over to the anv_async_submit")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30953>
(cherry picked from commit aea9ac47d2)
When we create sparse resources the first thing we do is a NULL bind
on them, as the Vulkan spec mandates certain behavior even for unbound
sparse resources. We do this with the minimal effort possible: if we
can get away with marking an L2 pointer as NULL in the L3 table, we
just do it and return, instead of going all the way to creating L1
tables and marking all the final entries as NULL.
The strategy we were using had a bug that could lead to previously
created NULL entries not being marked as NULL anymore. Let's give an
example:
(before proceeding, keep in mind that a NULL entry in the L3 and L2
tables has bit 1 set, it does *not* have the value 0)
- Create a 64mb buffer that uses an entire L1 table (needs to be
properly aligned), which triggers a NULL bind.
- Our algorithm will just set the L3 entry (pointing to the L2
table) as NULL.
- Create a 64kb buffer that uses the same L2 table (but a different
L1 table).
- The NULL bind triggered won't do anything as the L2 table is
already NULL.
- Bind the first buffer to actual memory. This will end up creating
the L2 table and the L1 table. The only entry we will set in the L2
table will be the one pointing to the L1 table. All the other
values will be 0 (so they won't have neither the NULL or Invalid
bits set: access to them will lead to page faults).
- Try to use the second buffer, which is still unbound. It was
relying on the fact that its L2 table pointer was NULL, but now
it's not anymore, so the page walker will fetch the L1 entries in
the L2 table and they will all be zero instead of having the NULL
bit set.
The fix is pretty simple: whenever we create a new L2 table, set every
entry to NULL (except the one we're about to set to non-NULL). This
preserves behavior for every other NULL resource relying on the L3
entry being set to NULL.
We don't need to do this for the L1 table because its entries are
different and instead of having bits to signal NULL entries we have
a special TR-TT register that we can set that gets compared to check
if an entry is NULL, and we conveniently program it to 0: see
ANV_TRTT_L1_NULL_TILE_VAL.
I am not aware of any real workloads that are triggering this
behavior, I found this issue while investigating something else,
running a custom sparse program in our pre-silicon environment, and it
told us about the page faults.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30953>
(cherry picked from commit 4c366ef67b)
Xe2 increased the register size from 256-bits to 512-bits. So we can
store 32 16-bit values in a register, rather than 16 values. Prior to
this patch, we hadn't updated the pass, so the second half of each of
our registers was unused.
Backport-to: 24.2
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31499>
(cherry picked from commit 4cb67cb07a)
We were manually allocating 1 REG_SIZE for the barrier payload, which is
only half a register on Xe2. This should eventually get allocated to a
whole register anyway, but it's awkward in the meantime. Also, we were
zero-initializing the header using group(8, 0) which only initialized
half the register. The rest of the fields are Reserved MBZ, so they're
likely unused and unread anyway - but it's better to zero-initialize
them so we don't get random undefined, miserable-to-debug behavior.
Backport-to: 24.2
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31499>
(cherry picked from commit dea61b7399)
Texel buffer could be arbitrary large, so the assumption being made in
the following comment is wrong:
"Zero-extension (u16) and sign-extension (i16) have
the same behavior here - txf returns 0 if bit 15 is set
because it's out of bounds and the higher bits don't matter."
Sign extension should matter for GLSL_SAMPLER_DIM_BUF.
This fixes the case of doing texelFetch with u16 offset:
uniform itextureBuffer s1;
uint16_t offset = some_ssbo.offset;
value = texelFetch(s1, offset).x;
If the offset is higher than s16 optimization incorrectly
left it as 16b.
In spirv the above glsl is translated into:
%22 = OpLoad %ushort %21
%23 = OpUConvert %uint %22
%24 = OpBitcast %int %23
%26 = OpImageFetch %v4int %16 %24
Cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31664>
(cherry picked from commit 7b09fc98fb)
We also add an nvk_format_supports_atomics() helper. This helper lives
in NVK for now because it's not just about the format and hardware but
also about whether or not we have compiler support in NAK.
Fixes: 1d10de539c ("nvk: Implement VK_EXT_shader_image_atomic_int64")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31633>
(cherry picked from commit c2684968de)
Correct copy-paste typo of depth_cpp instead of depth and use nullptr
instead of NULL, as GTest suggest in documentation:
When comparing a pointer to NULL, use EXPECT_EQ(ptr, nullptr) instead of EXPECT_EQ(ptr, NULL).
Fixes: ef9362acb8 ("gallium/osmesa: Return cleanly for OSMesaGetDepthBuffer() with no depth.")
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31606>
(cherry picked from commit 321012b95d)
Otherwise, they aren't applied if shaders are pre-compiled using
builders because the executable name would be fossilize-replay.
Using pApplicationName is the correct way to do because it's replayed
by Fossilize correctly.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31621>
(cherry picked from commit 56813236f4)
The declaration and definition used by tests otherwise differs from
addrlib.
Found by LTO -Werror=lto-type-mismatch.
Fixes: 1d69c0419b ("amd/addrlib: prevent defining regparm differently")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31613>
(cherry picked from commit d14d3c5bdd)
The Vulkan spec says:
"If the buffer was created with a non-zero value of
VkBufferOpaqueCaptureAddressCreateInfo::opaqueCaptureAddress or
VkBufferDeviceAddressCreateInfoEXT::deviceAddress, the return
value will be the same address that was returned at capture time."
My interpretation is that you can get the buffer device address before
binding if you passed a non-zero address during buffer creation. The
returned BDA would be similar if a memory object is bound to the
buffer later.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31145>
(cherry picked from commit 03b4477c8f)
There is no HW support, but in some cases the shaders mostly work even
if we ignore it, and so far we have just done so. However since the
driver didn't know to what output position in the PVS we should
redirect it, it ended in the first slot. Importantly, if the
CLIP_VERTEX output would be written after position (which actually
belongs in the first slot) it would overwrite it and things blow up.
So just remove it early, and also improve the warning a bit, including
the part that we could use draw module to actually emulate the feature.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11856
Fixes: 5dcef1e7b8
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31547>
(cherry picked from commit cc14d40239)
Spec allows calling VkBufferGetDeviceAddressInfo without binding to memory:
VUID-VkBufferDeviceAddressInfo-buffer-02600
If buffer is non-sparse and was not created with the VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag, then it must be bound completely and contiguously to a single VkDeviceMemory object
Which we can only do by making it sparse unconditionally, which feels very wrong to me for a capture & replay extension as that significantly impacts execution.
Current theory is that this was only intended for the EXT and not the core functionality. As such, let's disable capture using the EXT.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31140>
(cherry picked from commit c8c354d9c3)
When all 16 references are used, this would read pic->ref[16].
Same for HEVC, but HEVC only uses 15 reference frames so it would
never happen there yet is still reported by coverity.
Fixes coverity issues 1497283 and 1465569 Out-of-bounds read
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31558>
(cherry picked from commit 20d5020ad7)
Starting with Linux v6.11+, performance counter information is no
longer duplicated in both the kernel and userspace. Instead, an IOCTL
retrieves this information, allowing userspace to maintain a local
array for reuse, thus avoiding redundant kernel queries.
However, support for older kernels without these new IOCTLs remains.
To distinguish between versions, we check `devinfo->max_perfcnt` -
which is non-zero on Linux v6.11+ and zero on older kernels.
Currently, applications using performance queries on platforms with
older kernels encounter a SEGFAULT, as we don't validate
`devinfo->max_perfcnt` before accessing the userspace array for
performance counter information.
This commit makes sure that, if `devinfo->max_perfcnt` is zero,
`screen->perfcnt_names` will be NULL. This way, we can check if
`screen->perfcnt_names` is different than NULL before attempting to use
the userspace array.
Fixes: 017dde0d1c ("v3d: Use DRM_IOCTL_V3D_GET_COUNTER to get perfcnt information")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31552>
(cherry picked from commit 47a78614ea)
Check if the block size is bigger then 64. We want to block
e.g. one of the following formats:
- R32G32B32A32_FLOAT
- R32G32B32A32_SINT
- R32G32B32A32_ZINT
Unbreaks e.g. dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb16i
Fixes: e481c1269c ("etnaviv: disable 64bpp render/sampler formats")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27111>
(cherry picked from commit 04521c14b0)
Preprocess now must use the same conditional rendering state as the
execute, so the DGC prepare shader must reset the number of sequences
to generate an empty cmdbuf for compute.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31563>
(cherry picked from commit 336f80137d)
These should be included according to table in Bspec 43904.
Patch removes PIPE_CONTROL_STATE_CACHE_INVALIDATE based on HSDES.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29764>
(cherry picked from commit 78b614b333)
These should be included according to table in Bspec 43904.
Patch removes PIPE_CONTROL_STATE_CACHE_INVALIDATE based on HSDES.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29764>
(cherry picked from commit 3e29ea69ce)
The shader uniforms used for emulating TXS depend on the current
sampler view state and thus need to be re-emitted when this
states changes.
Fixes: 88f399b651 ("etnaviv: nir: support intrinsic used for txs lowering")
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/31495>
(cherry picked from commit c12697abe0)
