It was not taken into account that without Offset decoration
the output is not written into XFB.
Aside from eliminating more outputs this change prevents gl_PerVertex
builtins generated by glslang from being kept alive in case when XFB
is enabled. Keeping such outputs alive may upset a driver.
VUID-StandaloneSpirv-Offset-04716:
"Only variables or block members in the output interface decorated
with Offset can be captured for transform feedback, and those
variables or block members must also be decorated with XfbBuffer
and XfbStride, or inherit XfbBuffer and XfbStride decorations from
a block containing them"
Additional info about glslang behavior could be found at:
https://github.com/KhronosGroup/glslang/issues/1526
Fixes: e95531e101
("radv: fix gathering XFB info if there is dead outputs")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24318>
(cherry picked from commit 81407797b9)
The generalized check for the z-slice happens in 'check_region_bounds',
but this function requires the image pointer that is acquired in
`prepare_target_err`, therefore replace the assertion with a proper test.
v2: Also check for negative value (Brian Paul)
CC: mesa-stable
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25507>
(cherry picked from commit 16662f8d3a)
The current regex misses the = sign and therefore fails to match
DST:align=16.
Fixes: 9e56f69edf ("isaspec: encode: handle special fieldname properties")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25451>
(cherry picked from commit ef602e77f6)
the intent of the VkExternalMemoryProperties API is that all compatible
handle types are returned, not just the type being queried. these two
types are compatible, so return both when both are supported
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25474>
(cherry picked from commit a524f6b5d4)
The VA needs to be adjusted, otherwise the hw always writes at offset 0.
This fixes dEQP-VK.query_pool.statistics_query.*_cq.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25406>
(cherry picked from commit a9945216ba)
NGG is enabled by default on RDNA1-2 but the driver might fallback to
legacy GS for some reasons, like XFB. On these generations, the number
of generated primitives by GS needs to be emulated from the NGG shader
because the hw doesn't increment the related pipelinestat counter.
In order to support NGG and legacy GS with that query (remember that
we can't know pipelines when starting/ending queries), we used to
reserve 2x 64-bit counters to store the GDS results, and the results
were accumulated.
Now that legacy GS also uses GDS counters, we can simplify this path
and overwrite the pipelinestat counter directly instead of having two
separate counters.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
(cherry picked from commit 50709863ac)
This is actually wrong. For example, if there is a DCC decompress
draw followed by a draw without any color attachments,
CB_COLOR_CONTROL.MODE is still CB_DCC_DECOMPRESS but it should be
CB_DISABLED. For some reasons, this hangs on RDNA3 (VM faults are also
reported through dmesg).
This fixes GPU hangs with Resident Evil 6, Star Wars The Old Republic
and probably more games on RDNA3.
Strictly speaking, I don't think this dynamic state optimization is
worth a try, even for other states, and I think it would be safer to
remove it completely.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9335
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8327
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9878
Fixes: c08082e861 ("radv: ignore all CB dynamic states when there is no color attachments")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25402>
(cherry picked from commit af2a96bb37)
Some WSI objects don't extend `vk_object_base` therefore they need
special handling.
Fixes: 3c87618d35 ("vulkan: Handle vkGet/SetPrivateDataEXT on Android swapchains")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24752>
(cherry picked from commit 76d150674b)
VkSurface is handled by WSI and it doesn't extend `vk_object_base` so it
needs special handling.
Fixes: 3c87618d35 ("vulkan: Handle vkGet/SetPrivateDataEXT on Android swapchains")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24752>
(cherry picked from commit 5fe289d741)
Non-android platforms use mesa WSI, however some WSI object still don't
extend `vk_object_base` so they still need special handling.
Fixes: 3c87618d35 ("vulkan: Handle vkGet/SetPrivateDataEXT on Android swapchains")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24752>
(cherry picked from commit 710d478066)
I hit a problem running a set of lvp caselists with
dEQP-VK.transform_feedback.simple.draw_indirect_endqueryindexed_streamid_0_16,Crash
This was crashing due to
assert(setup->viewport_index_slot < 0);
in try_update_scene_state
This was because a previous draw had set viewport index slot to 2,
but a clear then draw sequence never resets it, so the clear gets
a scene, and when the subsequent flush happens for that scene,
the viewport_index_slot is never updated. It only gets updated on
draws.
This just resets it as lp_setup_update_state will always pick up
the correct one for the next draw.
Cc: mesa-stable
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25387>
(cherry picked from commit 8791aab20f)
The kernel exposes CHIP_ID, which consists of:
[63:48] const 0 / reserved
[47:32] speedbin (default 0xffff)
[31:0 ] actual gpu chip ID
Fix the 690 chip id to make it probe correctly.
Keep the existing entry for the downstream KGSL driver.
This is essentially the same as Commit 6067aba9e6 ("freedreno: Include
speedbin fallback in 740 chipid to fix probing"), except for the older
core.
Fixes: 210c6c11cc ("freedreno+tu: Add a690 support")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25408>
(cherry picked from commit b4d111ab6c)
On non-Windows OSes, align_realloc is the os_realloc_aligned() from
src/util/os_memory_aligned.h, which doesn't use realloc internally.
Instead, it uses os_malloc_aligned() and memcpy's over the old data,
which is why it needs an "old size" (unlike normal realloc).
In _mesa_reserve_parameter_storage, the call to align_realloc above
passes (oldValNum * sizeof(gl_constant_value)) as the old size, which
is all the actual data. The actual allocation size of the array may
be larger (in fact, we allocate 16 extra components), which is tracked
in SizeValues. After realloc, we memset to zero starting at the old
allocation size, to the new allocation size.
This would work if it were a real realloc. However, because we actually
malloc + memcpy and only copy the previous /data/, not the allocated
size, and then memset from the old /allocated size/, our new copy will
have the spaces between the old data and the old allocation size neither
copied nor memset, leaving them as uninitialized garbage memory.
These values then get written to the shader cache, meaning that if you
compile the same shader multiple times, you may get different shader
cache entries. This is bad for reproducible, deterministic compiles.
While at it, we also memset to zero in _mesa_add_parameter, as this
looks like another place where memset-to-zero is missing.
To reproduce this error, one can run shader-db:
$ MESA_SHADER_CACHE_DIR=a ./run -b shaders/godot3.4/49-28.shader_test
$ MESA_SHADER_CACHE_DIR=b ./run -b shaders/godot3.4/49-28.shader_test
and see an occasional difference in the end of the ParameterValues
array, where there's a padding gap between the last two elements that
was never zero-initialized.
Thanks to Mark Janes for discovering this and tracking it down together!
Cc: mesa-stable
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25316>
(cherry picked from commit 1c1aa579ff)
Move setting the default values from getEncParamPresetH264/5 as this
function is called on each frame which would result in overwriting
values set by application.
This fixes setting HRD parameters and max_qp/min_qp when
PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is not supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
(cherry picked from commit dd2ef9a0e4)
The encoder is created in handleVAEncSequenceParameterBufferType and it
also sets some default parameters, so we need to make sure to handle
this buffer first because application may have already set those
parameters from earlier buffers.
This fixes setting HRD parameters with gstreamer vah264enc/vah265enc
when PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
(cherry picked from commit c970a9b663)
The index at which the dynamic descriptor offsets were being
stored was incorrect, leading to some offsets not being stored and
thus `0` being applied as the offset to the descriptors instead.
dEQP test fixed:
dEQP-VK.binding_model.shader_access.{primary,secondary}_cmd_buf
.uniform_buffer_dynamic
.{vertex,fragment,compute,vertex_fragment}
.multiple_discontiguous_descriptor_sets
.*_descriptor.offset_view_{,non}zero_dynamic_nonzero
Fixes: aa791961a8 ("pvr: Add support for dynamic buffers descriptors")
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25320>
(cherry picked from commit feafb8a256)
wayland surfaces are likely to become unlinked in WSI implementations upon
retiring a swapchain, requiring the pending present to complete
in order to avoid invalid access
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25288>
(cherry picked from commit aaabb5b0f2)
tex->cmask_base_address_reg and tex->cb_color_info are used in
si_emit_framebuffer_state so we have to re-emit the state when
they're modified.
It's not done in si_alloc_separate_cmask because it cannot
update framebuffer.dirty_cbufs.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9830
Cc: mesa-stable
Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25317>
(cherry picked from commit 60a7c9688c)
This fixes several tests when the initially uploaded buffer
from CPU was being ignored because vc4_texture_subdata was not
marking the resource as written/initialized.
The usage flags management available at vc4_resource_transfer_map
is generalized into vc4_map_usage_prep and reused at
vc4_resource_transfer_map. This makes vc4 implementation more similar
to v3d.
This fixes 7 text in the following subgroups:
-dEQP-GLES2.functional.fbo.render.texsubimage.*
-dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.*
-spec@arb_clear_texture@arb_clear_texture-*
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25297>
(cherry picked from commit cb96dab5c8)
