The check in alloc_bo_from_cache() was skiping any try to get a bo
from cache but after use a protected bo was still being put in some
cache bucket and could be used for cases that don't require a
protected bo.
Using a protected bo in cases that don't require it can have
performance implications.
So here returning NULL when trying to get a cache bucket for a
protected bo, this will cause bo->real.reusable to be set to false
avoiding the bo to be reused.
Fixes: 9402ac8023 ("iris: handle protected BO creation")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21824>
(cherry picked from commit 266d961fdc)
For converting half-float to float, we currently emit BRW_OPCODE_F16TO32
with a UW source, to match legacy Gfx7 behavior. In the generator, this
becomes a MOV with a HF source on Gfx8+. Unfortunately, this UW source
confuses the scoreboarding pass into thinking it's an integer source,
leading to incorrect SWSB annotations on Alchemist.
We should ultimately fix the IR to stop being so...legacy...here, but
this is the simplest fix for stable branches.
Fixes misrendering in Elden Ring and likely Sekiro: Shadows Die Twice.
Cc: mesa-stable
Tested-by: Chuansheng Liu <chuansheng.liu@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
References: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8018
References: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8375
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21783>
(cherry picked from commit 3864049184)
The previous solution breaks potential loop header phis.
Move the dummy-break to the bottom of the loop.
Fixes: dEQP-VK.reconvergence.subgroup_uniform_control_flow_ballot.*
Fixes: a9c4a31d8d ('aco: handle NIR loops without breaks')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21736>
(cherry picked from commit cd1e5b1858)
the recording rp_info may be a pointer to a member of the array being
reallocated, so test for this and re-set it to avoid invalid memory
access
found with this caselist:
KHR-GL46.texture_gather.offset-gather-unorm-2darray
KHR-GL46.texture_view.view_sampling
cc: mesa-stable
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21729>
(cherry picked from commit 6ee5337d94)
Swizzle of 8-bit stencil format is defined as _x__ but the hw expects
BC_SWIZZLE_XYZW.
Fixes dEQP-VK.pipeline.monolithic.sampler.border_swizzle.*s8_uint*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21482>
(cherry picked from commit 7b2086d741)
Seems to fix a hang in the following titles :
- Age of Empire 4
- Monster Hunter Rise
where the HW is hung on a PIPE_CONTROL after a GPGPU_WALKER but no
MEDIA_INTERFACE_DESCRIPTOR_LOAD was emitted since the switch from 3D
to GPGPU.
This would happen in the following case :
vkCmdBindPipeline(COMPUTE, cs_pipeline);
vkCmdDispatch(...);
vkCmdBindPipeline(GRAPHICS, gfx_pipeline);
vkCmdDraw(...);
vkCmdDispatch(...);
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17247>
(cherry picked from commit 11bc2bde83)
Modifying pitch for all LINEAR surface isn't correct;
the original change that modified surf_pitch was only
intended for YUV textures.
This fixes vkGetImageSubresourceLayout rowPitch return value
for VK_FORMAT_BC3_UNORM_BLOCK + VK_IMAGE_TILING_LINEAR.
Fixes: fcc499d5 (ac/surface: adjust gfx9.pitch[*] based on surf->blk_w)
v2: add check for UYVY format (Pierre-Eric)
v3: move blk_w division to above if check (Pierre-Eric)
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21595>
(cherry picked from commit 347a5b79f9)
Both GLSL & SPIRV have undefined values for shift > bitsize. But SM5
says :
"This instruction performs a component-wise shift of each 32-bit
value in src0 left by an unsigned integer bit count provided by
the LSB 5 bits (0-31 range) in src1, inserting 0."
Better to not hard code the wrong behavior in NIR.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e227bb9fd5 ("nir/builder: add ishl_imm helper")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@colllabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21720>
(cherry picked from commit a278eeb719)
this otherwise may have been a surface that was never drawn to or
already had its layout corrected, in which case a deferred barrier
is not only unnecessary, it might be broken
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21739>
(cherry picked from commit e0dfe058c4)
This may happen if the Nouveau device fails to initialize before
the pushbuf is set up; the abort logic will call this either way.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21611>
(cherry picked from commit 9de997bde6)
reason:
some h264 streams have some strange pictures, from
vaapi input these pictures don't have a reference frame,
however, they are not intra only pictures, in MB layer
these pictures are looking for some references, if they
cannot find it. It could cause PF.
when reference pictures exist, it will need to set used_for
reference_flags, therefore if that is set, however the
number of reference frames is zero, which is odd, it
should be avoided.
solution:
In the above case, to scan the ref list so that it will
make at least one reference available to avoid crash, since
this is not accurate enough, it could cause some artifacts.
And in that case, it will need to be checked individually
for another solution.
closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1462
closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8401
Cc: mesa-stable
Tested-by: llyyr <llyyr.public@gmail.com>
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/21732>
(cherry picked from commit 0f3370eede)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e2dc32d755 ("anv: move functions around to plan for generated draws")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit aa18d52728)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e2dc32d755 ("anv: move functions around to plan for generated draws")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit e68615aeaa)
vulkancts test dEQP-VK.wsi.direct_drm.surface.create_simulate_oom is failing
because in wsi_display_alloc_connector() function memory allocation for
connector is not checked for return NULL. create_simulate_oom test simulates
out of memory, hence memory allocation fails for connector and later when
tried to dereference connector program will segfault.
This patch fixes the dEQP-VK.wsi.direct_drm.surface.create_simulate_oom test
segfault issue by checking if connector is NULL afer memory allocation.
Cc: mesa-stable
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21701>
(cherry picked from commit af953616a1)
With softpin we should not always expect a BO in addresses.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit f5dc88910f)
We only use the fragment shader push constants.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c950fe97a0 ("anv: implement generated (indexed) indirect draws")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit ae398284c9)
Earlier versions of the generation shaders were using the binding
table. We since switch to A64 messages. So the flush can be removed.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c950fe97a0 ("anv: implement generated (indexed) indirect draws")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit e698040061)
The issue here is that for draw indirect count variants, we want to
jump after the last generated draw call to the next location where
commands are. But if we have more than 67M draws (8k * 8k chunks), we
only know the location once we've generated each of the 8k * 8k
chunks.
This change adds a CPU side pointer in the push constant struct so
that we can create a single linked list of chunks to edit and go
through to write the correct jump address after all the generated
space has been allocated.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c950fe97a0 ("anv: implement generated (indexed) indirect draws")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit 63fa6d9f49)
cmd_buffer_update_dirty_vbs_for_gfx8_vb_flush takes a value RANDOM/SEQUENTIAL. Not a boolean.
Fortunately this worked okay because true == RANDOM
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit 4246a519f3)
The WA is meant to be here to apply some state that is not propagated
properly inside the HW. But if you have a loop like :
for ( ... ) {
emit(3DPRIMITIVE, some param);
}
You're not really changing any state, just push more draws into the
pipeline.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f2645229c2 ("anv: implement Wa_14016118574")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21660>
(cherry picked from commit 6ee7a2ecfa)
We don't want the WA to kick-in if it's not point/line topology.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f2645229c2 ("anv: implement Wa_14016118574")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21660>
(cherry picked from commit d82e8e01c8)
Using texelFetch to read samples from an 8xMSAA fast cleared image on
Haswell can read transparent black pixels around triangles from where
there should be none. This issue isn't present when using sample
shading, resolving the image using vkCmdResolveImage or in a copy the
image. The easiest way to fix this is by just disabling non-zero fast
clears for 8xMSAA images.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7587
Cc: mesa-stable
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21444>
(cherry picked from commit e509afacf3)
