There's no reason to calculate this more closely; the Vulkan spec
explicitly allows for it to be conservative. And there's no other Vulkan
driver in Mesa that currently does anything else.
But, we have another reason to limit to this specific value (which also
happens to be the minimum value allowed by the spec); we'll overflow the
32-bits of slice_stride for resources where the product of width, height
and texel-size is over UINT32_MAX. But with this limit in place, we
avoid this.
This limit will go away in v11, beacuse there's an additional five bits
of slice_stride there. But let's leave that for later.
Anyway, let's document why this is the correct limit, insted of having
the FINISHME-comment.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32265>
Panvk currently enables VK_EXT_vertex_attribute_divisor, but Mali HW
does not support a non-zero firstInstance when a divisor is used.
supportsNonZeroFirstInstance is correctly set to false to advertise
this, however this property was only added when the extension was
promoted. Thus we need to remove support for
VK_EXT_vertex_attribute_divisor and enable
VK_KHR_vertex_attribute_divisor instead.
Also fixes an issue with non-zero divisor for v10.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32137>
This reverts commit 46bf687882.
We wont be removing this lowering file and having this workaround in
glsl_to_nir() creates a dependency on the const values that we could
otherwise avoid, so lets just move this back. Dropping the consts
will be useful in a follow up series that aims to drop all the glsl
ir function inlining code by converting builtin functions to nir.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32239>
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>
It doesn't enable back face culling and small line culling. Those can only
be enabled for monolithic shaders. It only enables view culling and small
triangle culling.
Doing this has these minor advantages:
1. We can enable at least some culling immediately instead of when the first
monolithic shader finishes compilation.
2. If back face culling and clip planes are disabled, we no longer compile
monolithic TES and GS shader variants to get only view culling and small
triangle culling.
3. shader-db will show culling code changes for TES and GS.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32257>
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>
Combination of concurrent resolve groups and generic clear support on a750
exposed a problem around color and depth/stencil clears. With all resolves
now non-blocking in nature, we need a guarantee that clears issued through
commands will complete before any future resolves.
To achieve that, in case of generic clears being used, a cache flush is
done in order to generate the CCU_RESOLVE_CLEAN event that will ensure any
future resolve will block until the just-emitted clears are completed.
Fixes following flaky CTS tests on a750:
dEQP-VK.pipeline.monolithic.framebuffer_attachment.2d_array_32x32_48x48_4_ms
dEQP-VK.pipeline.pipeline_library.framebuffer_attachment.2d_array_32x32_48x48_4_ms
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 25b73dff5a ("tu/a7xx: use concurrent resolve groups")
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32242>
Erik Faye-Lund