programs start with one reference per contained shader. the only other
places they can be referenced are:
* batch refs
* merged separable programs during compile
this unref did not match any of those cases and caused early deletion
caselist:
dEQP-GLES31.functional.atomic_counter.inc.8_counters_5_calls_10_threads
dEQP-GLES31.functional.texture.filtering.cube_array.combinations.linear_mipmap_linear_linear_mirror_repeat
dEQP-GLES31.functional.texture.specification.texsubimage3d_pbo.rgb32i_cube_array
dEQP-GLES31.functional.texture.specification.texsubimage3d_pbo.rgb8_image_height_cube_array
dEQP-GLES31.functional.texture.specification.texsubimage3d_depth.depth24_stencil8_cube_array
dEQP-GLES31.functional.sample_shading.min_sample_shading.multisample_texture_samples_2_color
dEQP-GLES31.functional.vertex_attribute_binding.usage.mixed_usage.mixed_attribs_instanced_binding
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36294>
(cherry picked from commit 6570184201)
For example, divergence analysis can call nir_print_instr with an
instruction that doesn't have a block set. When that happens,
print_state::shader will be NULL.
I stumbled on this while testing !36147.
v2: Use nir_instr::has_debug_info instead. Suggested by Konstantin.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Fixes: ce0f30b230 ("nir: Add variable debug info to instructions")
Fixes: 3aeab4ce40 ("nir/print: Do not print debug information when gathering it")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36267>
(cherry picked from commit 477c0cbbf9)
This prevents memory being allocated with a size
of 0 as the sampler count will be 0.
Fixes: #13539
Co-authored-by: Stéphane Cerveau <scerveau@igalia.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36165>
(cherry picked from commit b781ae57a5)
A few device features (most importantly bufferDeviceAddress) are behind
a check for has_vm_always_valid. When replaying fossilize captures using
SPIR-V capabilities like PhysicalStorageBuffer addresses (which itself
depends on bufferDeviceAddress) on a null device, these features will be
hidden and replay will fail. Claim vm_always_valid support in the null
winsys - it's not like we'll ever create any BOs anyway.
Fixes: df1224c8 ("radv: rework VM_ALWAYS_VALID handling")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36221>
(cherry picked from commit 87ebe6b31a)
[eric: renamed to has_local_buffers as 25.1 doesn't have ffdf13bd48 ("ac/info: rename has_local_buffers into has_vm_always_valid")]
The pipe_context might never be reused or the new queue won't ever reuse
all shader image slots leading to stale objects being referenced by the
driver.
Fixes: 50dbcb1d00 ("rusticl: stop clearing shader images after every dispatch")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36243>
(cherry picked from commit dad43d6c4a)
Tested with:
commit 3a252ff9d8b6dc22b20463bfcb31a4e8992b0e8f
Merge: 9800bf6fae3b 11895f375939
Author: Simona Vetter <simona.vetter@ffwll.ch>
Date: Fri Jul 11 11:25:34 2025 +0200
Note that the kernel treats WCL similar to PTL, so 94de1dfd4729
("drm/xe/ptl: Drop force_probe requirement") also removed the
force_probe for WCL.
Backport-to: 25.1
Ref: 3c0f211bc8fc ("drm/xe: Add Wildcat Lake device IDs to PTL list")
Ref: 94de1dfd4729 ("drm/xe/ptl: Drop force_probe requirement")
Ref: drm/drm-next 3a252ff9d8b6dc22b20463bfcb31a4e8992b0e8f
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36148>
(cherry picked from commit bca1acbb42)
It's helping buggy applications that may use the returned
value without checking for an error first.
For instance, viewperf20/maya uses a sequence like this:
glGenBuffers(n = 1, buffers = &3458)
...
glGetNamedBufferParameteriv(3458, GL_BUFFER_SIZE, &p)
Since 3458 isn't associated to an object yet, _mesa_lookup_bufferobj_err
will return NULL, leaving 'p' with its original value.
It seems to randomly trigger an exit from the benchmark,
presumably because the content in 'p' is random (for instance
-1879044180).
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36190>
(cherry picked from commit d21c8e1bed)
We were missing parenthesis on pan_cast_and_pack macros causing various
issues.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 410e5a36ec ("pan/genxml: Rework gen_pack.py to support OpenCL")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36261>
(cherry picked from commit 455b93601a)
We were missing a couple bits from hash and a bunch of stuff from the
comparison. This puts most of nir_tex_instr into a single pack_tex
helper that's used by both and grabs everything we were missing.
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36234>
(cherry picked from commit 557ac588e4)
In VCN5, the AV1 context buffer has changed to a bigger
one than VCN4. It fixed an AV1 decoding issue on VCN5.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36208>
(cherry picked from commit 32a2012975)
Per spec VUID-VkMemoryAllocateInfo-pNext-01874:
If the parameters do not define an import operation, and the pNext chain
includes a VkExportMemoryAllocateInfo structure with
VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID
included in its handleTypes member, and the pNext chain includes a
VkMemoryDedicatedAllocateInfo structure with image not equal to
VK_NULL_HANDLE, then allocationSize must be 0
- before: total 116, skip 66, pass 36, fail 14
- after: total 116, skip 66, pass 50, fail 0
Fixes: cebb2bf266 ("lavapipe: Add AHB extension")
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36204>
(cherry picked from commit 209e402720)
The implementation only takes the ownership after a successful import.
On import failure, the caller is going to handle the fd. Meanwhile,
amend a missing error code on an error path.
Fixes: 895d3399f7 ("lavapipe: add support for KHR_external_memory_fd")
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36204>
(cherry picked from commit 160cd3a317)
lvp hasn't used common device memory obj, and it allocates and imports
ahb on its own. Thus it has to implement the AHB export api itself.
- before: total 116, skip 66, pass 24, fail 26
- after: total 116, skip 66, pass 36, fail 14
Fixes: cebb2bf266 ("lavapipe: Add AHB extension")
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36204>
(cherry picked from commit f1af533b2c)
Currently tile swizzle can only be non zero for single plane
formats, for multi plane formats we always set PIPE_BIND_SHARED.
Luma only (Y400) JPG decode and encode with RGB input surface (EFC)
are the only two cases where we can get surface with tile swizzle
and ignoring it would result in corrupted output.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13346
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35647>
(cherry picked from commit b665bd21cb)
While the API spec does describe which flags _may_ be passed in, the
overall CL working group agreement is, that implementations should expect
random flags to be passed in as other implementations _may_ use them to
further restrict or allow image formats.
Also fix validation for importing GL objects while at it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36216>
(cherry picked from commit d8793e3874)
Otherwise we can have a case where binning VS uses more consts than
full VS (when safe variant is used for full VS), that will result in
a rendering issue because SP_VS_CONST_CONFIG.CONSTLEN is shared between
full and binning VS in PROGRAM_CONFIG state and gets the value from the
full VS.
There are two alternative solutions that can allow binning VS to always
use maximum constlen:
- Move constlen emission to per-XS config. This interferes
PROGRAM_CONFIG state which uploads consts and does SP_UPDATE_CNTL.
Consts would need to be uploaded after constlen is defined, while
SP_UPDATE_CNTL must be done before per-XS state is emitted.
Also having SP_UPDATE_CNTL in a draw state that is always DIRTY
isn't great.
Something didn't work out on A6XX, so this idea was dropped.
- Emit constlen again in VS_BINNING draw state. This seem to work
but also likely an undefined behaviour since constlen is changed
after some consts are uploaded.
Cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36203>
(cherry picked from commit 6003a89b89)
Advertising SAMPLED_IMAGE_DEPTH_COMPARISON is a no-op for images that
don't have SAMPLED_IMAGE_BIT, but it's confusing and results in us
advertising a lot of formats that with only the
SAMPLE_IMAGE_DEPTH_COMPARISON feature that aren't usable for anything.
For R32_UINT and R32_SINT, the change is just a cleanup, because we
always support these for storage images.
Whe we implement VK_EXT_host_image_copy, advertising unusable formats
triggers failures in dEQP-VK.api.image_clearing.*, so it's convenient to
have features==0 for all unusable formats.
Fixes: 70b8056df1 ("panvk: Enable KHR_format_feature_flags2 and use them")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35910>
(cherry picked from commit 4f8d0e81c4)
All current callers check for MAP_FAILED, not NULL, and we are returning
MAP_FAILED already on the other error paths.
Fixes: d5f4f918f3 ("panfrost: clean up mmap-diagnostics")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36122>
(cherry picked from commit 77f7147cea)
Fixes: c257bf5142 ("panvk: Conditionally register an host address when tracking user memory")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36122>
(cherry picked from commit 7dcac3d55b)
Trying to use Zink with the DRM winsys is problematic at best. In
theory all the pieces should be there but there are bugs around
synchronization, etc. This copies the current behavior of X11 which
also refuses to initialize DRM on Zink.
This is particularly important for Nouveau users which are getting Zink
via the loader returning "zink" for get_driver_for_fd(). On Wayland
today, we go ahead and load zink and attempt to use the DRM EGL paths,
which are broken. On X11, it fails to load the driver and then the EGL
device initialization code re-tries with zink which succeeds. Because
the second try is using Zink from the start, it's equivalent to if the
user had set MESA_LOADER_DRIVER_OVERRIDE=zink and they get the kopper
path, which is more reliable.
This absolutely not what we want because it means we don't load the
driver the loader requested and are dependent on fallback paths to get a
driver loaded at all. However, the real solution in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36014
is too complex to backport.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13498
Acked-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36119>
