Since we now use the common vulkan runtime to handle pipeline state and
this sets a limit for this at MESA_VK_MAX_VERTEX_BINDING_STRIDE we should
do the same, or else we can run into an assert-fail in the runtime code.
Fixes:
dEQP-VK.pipeline.monolithic.bind_buffers_2.maintenance5.triangle_list.buffers5.stride_offset_rnd321.whole_size
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29454>
We were exposing them as zero, as based on just the name, we assumed
that it was about the descriptors using the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit.
But from spec, that limit takes into account descriptors created *with
or without*, so for example:
"maxPerStageDescriptorUpdateAfterBindUniformBuffers is similar to
maxPerStageDescriptorUniformBuffers but counts descriptors from
descriptor sets created with or without the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit
set."
As we don't support the feature, those limits are the same of the
existing without the DescriptorUpdateAfterBind.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
We were multiplying it by 6, that is the number of possible shader
stages, but from spec it points that we need to multiply by the number
of supported shader stages.
From Vulkan 1.3 spec, chapter 33, "Limits", note 8 on Table 33
"Required Limits":
"The minimum maxDescriptorSet* limit is n times the corresponding
specification minimum maxPerStageDescriptor* limit, where n is the
number of shader stages supported by the VkPhysicalDevice. If all
shader stages are supported, n = 6 (vertex, tessellation control,
tessellation evaluation, geometry, fragment, compute)."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
This is added with VK_KHR_maintenance5 to allow 64-bit
for pipeline creation flags.
The flags are backwards compatible so we don't need to
change the flag enum values by the new ones.
This patch also addresses a small issue where compute pipelines
where not initializing the flags field in the pipeline object.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29449>
This used to depend on both _mesa_get_shader_image_format() and
_mesa_uncompressed_format_to_type_and_comps() doing a specific mapping
to behave like the spec requires. But only a small subset of what the
latter function does is needed, and that function is used for other
purposes where the needs are dictated by other means.
It's going to be easier to maintain this code if we use different
implementations for these two things.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29386>
In order to build grl, we need to get the device_info struct from the
PCI ID, but for pre-production platforms we don't want to enable them
unless INTEL_FORCE_PROBE is set.
Setting it when running intel_clc allows us to get the device_info
struct when the pre-production hardware is not ready to be enabled by
default.
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/29273>
The queueFlags of the associated queue may have more flags than just the
type of queue it is, based on what that queue supports, like sparse or
protected content. Check that the queue is a blitter engine instead.
Fixes a bunch of dEQP-VK.api.copy_and_blit.core.*_transfer on MTL with
ANV_SPARSE=0
Fixes: 17b8b2cffd ("anv: Add support for a transfer queue on Alchemist")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29336>
The old mipmap generation code has a few problems:
1. It open-codes the format conversion, which is error prone, and it's
hard to know if we're missing some formats. Manual inspection shows
that we're indeed missing some less commonly used formats.
2. When downsampling between two miplevels with the same width (e.g a
width of one), the code would read from outside the image.
3. It averages sRGB textures in gamma space. Whilte that's legal in GL
(the filtering algorithm is undefined), it doesn't produce very good
results. And it's not the same thing as util_gen_mipmap() does.
4. Similarly, it uses a box-filter for the stencil values. And while
that's actually what the spec recomments (regardless of format), it's
absolutely *not* what most applications would want. Using nearest
sampling would make more sense.
5. It has requirements about the type and format returned by
_mesa_uncompressed_format_to_type_and_comps() which other call-sites
in mesa doesn't have. This is the real reason I want to get rid of
it, because it ends up complicating the GLES read formats / types.
So, let's rewrite all of this, fixing all of the above. The result is
quite a bit shorter, and if this ends up being less performant, it's
unlikely that this matters, because we almost always use the GPU
accelerated code-path provided by util_gen_mipmap() anyway.
The new code works by a few identities: It uses the pack / unpack
helpers to convert the texture to a few reasonable intermediate formats,
so we keep the amount of open-coded averaging to a minimum. To do this
without heap-allocations, we introduce a concept of a "span", which has
a max fixed size, that can trivially be allocated on the stack.
We also add some more requirements to keep things sane; the higher level
do_row functions only allow the dest image to be half of the source
width or one (whichever is larger). This matches the high-level needs of
mipmap generation. The lower level do_span() function is a bit more
flexible, because that turns out to be helpful when implementing
do_span_3D(), where we want to avoid collapsing the inner dimension
twice.
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29380>
