Fixes the following building error:
../src/vulkan/runtime/vk_meta_clear.c:213:42: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct vk_meta_clear_push_data push = { };
^
1 error generated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This is unlikely but can happen if you have the following sequence:
1. vkCmdSetScissors()
2. No pipeline bind
3. vkCmdClearImage() which causes a meta save
4. Meta restore with vk_cmd_set_dynamic_graphics_state()
In that case, we don't have scissor counts but need to restore the
scissors set with `vkCmdSetScissors()` before the meta save. We can
safely copy all of them, it's just more memory traffic than maybe we'd
like. Fortunately, this can only happen at the start of a command
buffer and only with a fairly silly sequence of commands.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Most hardware supports some sort of rectangle primitive. This adds a
new VK_PRIMITIVE_TOPOLOGY_RECT_LIST_MESA which will be used by the vast
majority of (if not all) meta commands. Drivers can key off of of this
to build pipelines differently and implement their own cmd_draw_rects
and cmd_draw_volume hooks or they can map it to TRIANGLE_LIST and use
the provided helpers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
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
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24318>
Unlike some other core structs, I didn't bother to copy the entire
VkSamplerCreateInfo into the sampler. There isn't typcially a lot of
pre-processing we can or need to do here and we may as well keep the
struct small for now. It does, however, handle most things involving
chain-in structs.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24335>
This follows the pipeline libraries method of including SPIR-V and lets
you provide the NIR shader without wrapping it in a VkShaderModule.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24335>
Add helper functions vk_memory_to_image_copy_layout() and
vk_image_to_memory_copy_layout(), which will be useful in
VK_EXT_host_image_copy implementations.
vk_memory_to_image_copy_layout() is similar to
vk_image_buffer_copy_layout(), except the second parameter is
VkMemoryToImageCopyEXT instead of VkBufferImageCopy2.
vk_image_to_memory_copy_layout() is similar to
vk_image_buffer_copy_layout(), except the second parameter is
VkImageToMemoryCopyEXT instead of VkBufferImageCopy2.
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24290>
Vulkan drivers that use nir_lower_blend need to translate Vulkan enums to the
common (non-Vulkan) versions used in nir_lower_blend. We don't need to duplicate
that boilerplate in every VK driver that uses nir_lower_blend, move panvk's
versions to common code so we can use them in agxv. I suspect powervr wants this
too.
It might be useful to also share the logic to translate vk_color_blend_state
to nir_lower_blend_options wholesale, but panvk wouldn't use it and agxv is
downstream so it wouldn't have any in-tree users. So I'll keep that part
vendored (for now). For now, let's share the easy win of the enum translation.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Italo Nicola <italonicola@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24076>
It's unlikely that anyone will call vkCmdSetVertexInputEXT() twice with
the exact same arguments, so this wasn't really doing anything, and it
hurt performance in the common case as shown via "vkoverhead -test 21"
on turnip.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
We need to use the driver's renderpass to get the flags if the driver
provides it.
Fixes: f3876db1ee ("vulkan: Plumb rendering flags through vk_graphics_pipeline_state")
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
Even if this isn't dynamic state per-se because it always comes from the
pipeline, it's useful to be able to track it for the various dynamic
states that it affects, which may be either precompiled or not on
turnip.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
Previously, drivers have either not supported some dynamic state (like
vertex input or sample locations) at all or it's been always dynamic. In
order to be able to set dynamic state sometimes and other times leave it
up to driver-specific state packets, we need a few helpers.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
On turnip we support dynamic vertex input, but static vertex input is
precompiled and so we will copy from a source without VI to a
destination with VI and it's valid in this case to do nothing. On the
other hand, it should never be valid if VI state is set but the pointer
isn't there, which the code previously silently skipped over. There's a
similar issue with sample locations.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
This is a mirror of vi::bindings_valid, but we can track it and set it
properly even when vertex input state is precompiled, because it is also
needed on turnip for knowing the size of the vertex buffer and vertex
stride state packets even when vertex input state is precompiled.
Previously drivers that could pre-bake vertex input state were expected
to handle this themselves, but this would've been complicated for turnip
because we can handle both pre-baked and dynamic vertex input state. Now
we have the one field which is correctly set in all circumstances and we
never have to setup space for vertex input state in the pipeline.
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
On turnip, there are two cases for feedback loops:
- For feedback loops that involve input attachments, everything works as
normal in GMEM mode but have to do a workaround in sysmem.
- For feedback loops that may involve any texture, GMEM mode is
impossible and we have to disable it.
Currently we track this through a special flag on the pipeline, but this
won't be practical in the future. Add a flag to the common renderpass
state struct to patch this info through when using our own renderpass.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
It only has a subset of the renderpass state, whereas with turnip we
need to use pretty much all of it at one point or another. Just allow
the driver to pass in the entire vk_render_pass_state if it's using its
own renderpass implementation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
Shaders are the largest thing we hash now, so they benefit from a faster
hash.
Change the field name from `sha1` to `hash` to avoid tying the definition
to a particular algorithm. This doubles down as a precaution against
callers still assuming a 20-byte hash (in which case the compilation will
error out).
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22571>
For historical reasons, nir and vtn were compiled together,
and a bunch of vtn specific targets were defined in
src/compiler/meson.build.
Now that we can, make src/compiler/spirv produce an internal
library that depends on NIR, and is used by the drivers/tools.
Also move the vtn specific targets into that directory's
meson.build.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23668>
