This situation is happening, for instance, when the hardware is
using the type FMT_8_8_8_8 (4 bytes) while the software was
requesting a 3 bytes type. The width should be adjusted to the
expected hardware size; otherwise, the last vertex is lost.
Note: The rv770 didn't behave like this. This is definitely
a hardware change between these gpus.
This change was tested on palm and cayman. Here are the tests fixed:
spec/!opengl 2.0/gl-2.0-vertexattribpointer-size-3: fail pass
deqp-gles2/functional/draw/random/62: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_byte3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_256: fail pass
deqp-gles3/functional/draw/random/117: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/byte/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads256: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32184>
(cherry picked from commit 81889f4d5c)
This change fixes the evergreen nonconformity issue on non-mipmap
textures when the minification and the magnification are not in
the same state.
This modification disables 5278436d67 when the minification and
the magnification are different. This fixes the nonconformity
without new regressions. Anyway, I was unable to reproduce
the issue described by 5278436d67 on palm and cayman.
This change was tested on cayman and palm. It fixes 84 deqp-gles2
tests and 128 deqp-gles3 tests:
deqp-gles2/functional/texture/filtering/2d/linear_nearest_*
deqp-gles2/functional/texture/filtering/2d/nearest_linear_*
deqp-gles2/functional/texture/filtering/cube/linear_nearest_*
deqp-gles2/functional/texture/filtering/cube/nearest_linear_*
deqp-gles2/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles2/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/cube/filtering/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/3d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/3d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/cube/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/cube/combinations/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/3d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/3d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/cube/filtering/nearest_linear_*
Fixes: 5278436d67 ("r600: force LOD range to be only one value when mip.min filter is NONE")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32185>
(cherry picked from commit 4d24995adb)
These fields are only valid in certain formats, so set them accordingly.
Note the check if !is_send is used because FORMAT_BASIC is reused for
SEND/SENDS in some platforms. If we start to see more cases like that,
we can create a new FORMAT for it.
The cond_modifier is trickier because on top of that, it is not valid
for 64-bit immediates in some platforms. Found when EU validation
complained about moving 64-bit immediates with higher bits.
Fixes: e4440df2d8 ("intel/brw: Add pred/cmod/sat to brw_hw_decoded_inst")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32287>
(cherry picked from commit 1d704af515)
When we create a new swapchain to replace the one currently presenting on
a surface, we need to reset all these timing variables. Otherwise we can
lose track of corrections that were made for the old swapchain when we
delete undelivered presentation feedback results.
Also, we use these variables when queuing a presentation, but we also use
them in the dispatch code that can be called by WaitForPresent from another
thread. We need to protect these variables against concurrent usage.
This is all much easier to do when they're stored as part of the swapchain
instead of the surface, so just move them there and adjust the locking.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
(cherry picked from commit 2e49448a43)
When we start using timestamps, the current code will generate an event
stream like:
feedback
set barrier
wait barrier
commit
feedback
set timestamp
set barrier
commit
wait barrier
commit
The second content update can cause the feedback request from the first to
send a discarded event if the timestamp is in the past.
Be less clever and just put waits in both our content updates.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
(cherry picked from commit b9c8afae33)
When occluded, the current math always rounds down to 0 cycles and leads
to improperly throttled frame delivery.
Improve the comment, and use a formula that leads to generating future
times even when occluded.
Also remove some dead code, as we can never get here with a period of 0.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
(cherry picked from commit ed2bb692f7)
We assume everywhere that RGB is not planar, so sampling
and color space conversions will not work correctly with RGBP.
Drivers can still support RGBP, but processing entrypoint with
shaders doesn't support it.
Fixes: bdb7f36aa8 ("frontends/va: add support for RGBP rt_format")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
(cherry picked from commit 6c83f3c3bb)
Currently if you try to probe the virtio ICD on a non-virtio system
it will fail in CreateInstance which causes the loader to spit on the
screen.
However instance creation shouldn't fail, the driver should just
not enumerate any devices in this case. It's a bit tricky to ensure
this, but return instance and then handle instance destruction
and fail device enumeration.
Cc: mesa-stable
Reviewed-by: Ryan Neph
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32266>
(cherry picked from commit 25b8f4f714)
Instead of using unreliable polling to wait for foz db updater to parse
and load from the dynamic list, also use inotify to wait for foz db
updater close the list file after its done updating.
Fixes: 4dfd306454 ("disk_cache: Disable the "List" test for RO disk cache.")
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32237>
(cherry picked from commit cbb3bb5c7b)
For a TU_PIPELINE_GRAPHICS_LIB we were taking a ref to the descriptor
set layout but never releasing on VK_PIPELINE_COMPILE_REQUIRED.
Since VK_PIPELINE_COMPILE_REQUIRED is technically an error, the user
doesn't call vkDestroyPipeline() for it so the descriptor sets
referenced were never getting freed.
Addresses:
```
Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7fa5a93ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa44bac84 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fa32ea5d8 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fa32ea60c in vk_zalloc ../src/vulkan/util/vk_alloc.h:56
#4 0x7fa32ea750 in vk_descriptor_set_layout_zalloc
../src/vulkan/runtime/vk_descriptor_set_layout.c:49
#5 0x7fa306fc98 in tu_CreateDescriptorSetLayout(VkDevice_T*,
VkDescriptorSetLayoutCreateInfo const*, VkAllocationCallbacks
const*, VkDescriptorSetLayout_T**)
../src/freedreno/vulkan/tu_descriptor_set.cc:161
```
and
```
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f9b4b3ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f9925e900 in ralloc_size ../src/util/ralloc.c:118
#2 0x7f9925e8d4 in ralloc_context ../src/util/ralloc.c:105
#3 0x7f98b4b214 in tu_pipeline_builder_build<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:3898
#4 0x7f98b46bd8 in tu_graphics_pipeline_create<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:4203
#5 0x7f98b22588 in VkResult
tu_CreateGraphicsPipelines<(chip)7>(VkDevice_T*,
VkPipelineCache_T*, unsigned int, VkGraphicsPipelineCreateInfo const*,
VkAllocationCallbacks const*, VkPipeline_T**)
../src/freedreno/vulkan/tu_pipeline.cc:4234
```
seen in:
dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.graphics.4_variants.no_spec_constants.no_pipeline_cache.all_zeros_id.no_exec_properties.vert_tesc_tese_frag
Cc: mesa-stable
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32188>
(cherry picked from commit 21baf2f6c1)
Also ensure that 'needs_scratch_reg' is always true if SCC might be overwritten.
Few changes, because some p_split_vector get SCC as scratch reg assigned,
and thus, can inhibit some postRA optimizations.
Totals from 3 (0.00% of 79395) affected shaders: (Navi31)
Instrs: 10501 -> 10500 (-0.01%); split: -0.02%, +0.01%
CodeSize: 51580 -> 51520 (-0.12%); split: -0.12%, +0.01%
Latency: 84166 -> 84174 (+0.01%)
InvThroughput: 13109 -> 13111 (+0.02%)
SALU: 859 -> 860 (+0.12%)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32217>
(cherry picked from commit a04e096339)
We updated maxImageDimension2D etc to report the actual max size, but we
forgot to update GetPhysicalDeviceImageFormatProperties in the same way.
Let's do that to make things consistent.
This fixes the following CTS test-case:
dEQP-VK.wsi.wayland.swapchain.create.image_extent
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
(cherry picked from commit 9c1de5c6b3)
On modern Mali GPUs, we can have 16 bits for the X and Y sizes, already
overflowing 32-bit barrier even with a single layer of byte-sized
formats.
So let's make sure we have enough bits to avoid overflows here.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
(cherry picked from commit 00b25ec769)
If we have NIR such as:
32x4 %48 = @load_vulkan_descriptor (%47) (desc_type=SSBO)
32x4 %76 = deref_cast (tint_symbol_11 *)%48 (ssbo tint_symbol_11) (ptr_stride=0, align_mul=4, align_offset=0)
32x4 %77 = deref_struct &%76->tint_symbol_10 (ssbo int) // &((tint_symbol_11 *)%48)->tint_symbol_10
A single nir_rematerialize_deref_in_use_blocks() will rematerialize the
deref_struct and then it's deref_cast. However,
nir_foreach_instr_reverse_safe is not safe if the next iteration's
instruction is removed. This can result in the instruction loop exiting
and the load_vulkan_descriptor never having an LCSSA phi.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 439e8c42cc ("nir/lcssa: Fix rematerializing derefs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11770
(cherry picked from commit 65a54b4ec4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
If applications doesn't send any attributes to describe the format,
we would always use driver preferred format (NV12). This is wrong
for any RT format other than the driver preferred (YUV420).
Driver doesn't have a choice here, we must use the matching format.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
(cherry picked from commit c8a893becd)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
The code wants the number of components used by the variable in the
current attribute slot, not the total number of components.
For e.g. a 4x3 matrix, glsl_get_components() returns 12, leading to the
following error reported by AddressSanitizer:
```
Test case 'dEQP-VK.tessellation.shader_input_output.cross_invocation_per_patch_mat4x3'..
../src/compiler/nir/nir_lower_io_to_vector.c:265:16: runtime error: index 4 out of bounds for type 'nir_variable *[4]'
```
Fixes: 5ef2b8f1f2 ("nir: Add a pass for lowering IO back to vector when possible")
(cherry picked from commit ba5c65f10b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
The game aliases two images. It binds a memory object to two different
images, the first one being an image with 4 mips and the second with
only one mip but the bind offset is incorrect. It's like it queried
the first image size with different usage flags, so that DCC was
disabled.
Force disabling DCC for mips fixes the incorrect rendering and doesn't
hurt performance.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10200
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 2f13723c0a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
In two functions implementing resource discard rebind_resource is called
on resource before its track record is reset. This prevents update of
dirty_resource or dirty_shader_resource because of conditions in
needs_dirty_resource. With rsc->track reset and dirty_resource bits
missing further calls to transfer_map will not try to reallocate
resource storage when needed.
A way to reproduce the issue in both functions is by executing at least
3 draws modifying bound texture or VBO each time. This patch fixes those
cases and some related piglit tests on a5xx and should fix it on other
GPUs. Also it fixes rendering in Firefox and vsraytrace (except vertical
line at right edge).
Fixes: 0a62a874fc ("freedreno: Re-work dirty-resource tracking")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10374
Reviewed-by: Rob Clark <robclark@freedesktop.org>
(cherry picked from commit 6d14cad330)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
Many debug flags influence shader codegen but are currently not included
in the hash key. This causes surprising effects as cache lookups may
return shaders compiled with different debug flags than currently in
effect. This patch fixes this by including all debug flags in the
shader hash key.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: c323848b0b ("ir3, tu: Plumb through support for per-shader robustness")
(cherry picked from commit d8c90806e4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
This fixes a corner case of the LNL sub-dword integer restrictions
that wasn't being detected by has_subdword_integer_region_restriction(),
specifically:
> if(Src.Type==Byte && Dst.Type==Byte && Dst.Stride==1 && W!=2) {
> // ...
> if(Src.Stride == 2) && (Src.UniformStride) && (Dst.SubReg%32 == Src.SubReg/2 ) { Allowed }
> // ...
> }
All the other restrictions that require agreement between the SubReg
number of source and destination only affect sources with a stride
greater than a dword, which is why
has_subdword_integer_region_restriction() was returning false except
when "byte_stride(srcs[i]) >= 4" evaluated to true, but as implied by
the pseudocode above, in the particular case of a packed byte
destination, the restriction applies for source strides as narrow as
2B.
The form of the equation that relates the subreg numbers is consistent
with the existing calculations in brw_fs_lower_regioning (see
required_src_byte_offset()), we just need to enable lowering for this
corner case, and change lower_dst_region() to call lower_instruction()
recursively, since some of the cases where we break this restriction
are copy instructions introduced by brw_fs_lower_regioning() itself
trying to lower other instructions with byte destinations.
This fixes some Vulkan CTS test-cases that were hitting these
restrictions with byte data types.
Fixes: 217d412360 ("intel/fs/gfx20+: Implement sub-dword integer regioning restrictions.")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32261>
