PR #80296 introduced a regression because it checks if the
VK_EXT_pipeline_creation_cache_control extension has been enabled before
using it, but turns out the process is a bit more convoluted than that
(a Vulkan driver may support the extension but then say the feature is
not supported)
Sometimes when resizing the window we may get the following validation
error:
ERROR: VALIDATION - Message Id Number: -370888023 | Message Id Name:
VUID-vkAcquireNextImageKHR-semaphore-01286
Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01286 ]
Object 0: handle = 0xdcc8fd0000000012, type = VK_OBJECT_TYPE_SEMAPHORE;
| MessageID = 0xe9e4b2a9 | vkAcquireNextImageKHR: Semaphore must not be
currently signaled or in a wait state. The Vulkan spec states: If
semaphore is not VK_NULL_HANDLE it must be unsignaled
(https://vulkan.lunarg.com/doc/view/1.2.198.1/linux/1.2-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01286)
In VulkanContext::prepare_buffers the problem was that
vkAcquireNextImageKHR returned VK_SUBOPTIMAL_KHR but it already signaled
the semaphore (because it is possible to continue normally with a
VK_SUBOPTIMAL_KHR result).
Then we recreate the swapchain and reuse the
w->image_acquired_semaphores[frame_index] which is in an inconsistent
state.
Fixed by recreating the semamphores along the swapchain.
Fix#80570
Direct buffer copies are required to perform certain operations more efficiently, as the only current alternative is to download the buffer to the CPU and upload it again. As the first use case, the new function is used when enabling motion vectors on multimeshes.
1. Validation layers on Windows were complaining w/
VUID-VkSwapchainCreateInfoKHR-surface-01270 that we were not calling
vkGetPhysicalDeviceSurfaceSupportKHR before vkCreateSwapchainKHR.
2. Godot was only calling vkGetPhysicalDeviceSurfaceSupportKHR at
startup, but it should be doing this for every window w/ a new surface
it wants to create, not just the first one.
- In practice this will likely not make a difference. If
vkGetPhysicalDeviceSurfaceSupportKHR returns false after initialization,
there's nothing we can do about it and it is likely because something
else went terribly wrong, which is why the error message is worded like
that.
- This is mostly to shut up validation layers. Though technically,
the layers are right.
3. Do not call vkGetPhysicalDeviceSurfaceSupportKHR on queues we don't
even plan on ever using. We don't know how drivers will react to that
(e.g. they may preemptetively allocate resources to support presentation
on exotic queues, instead of just saying no). Just behave like every
other Vulkan app out there.
The first time a shader is compiled Godot performs the following:
```cpp
for (uint32_t i = 0; i < SHADER_STAGE_MAX; i++) {
if
(spirv_data.push_constant_stages_mask.has_flag((ShaderStage)(1 << i))) {
binary_data.push_constant_vk_stages_mask |=
shader_stage_masks[i];
}
}
```
However binary_data.push_constant_vk_stages_mask is never initialized to
0 and thus contains garbage data or'ed with the good data.
This value is used by push constants (and many other things) thus it can
be a big deal.
Fortunately because the relevant flags are always guaranteed to be set
(but not guaranteed to be unset), the damage is restricted to:
1. Performance (unnecessary flushing & over-excessive barriers)
2. Overwriting push descriptors already set (this would be serious,
doesn't seem to be an issue)
3. Driver implementations going crazy when they see bits set they don't
expect (unknown if this is an issue)
This uninitialized value is later saved into the binary cache.
Valgrind is able to detect this bug on the first run, but not on the
subsequent ones because they data comes from a file.
cache_file_version has been bumped to force rebuild of all cached
shaders. Because the ones generated so far are compromised.
This allows us to specify a subset of variants to compile at load time and conditionally other variants later.
This works seamlessly with shader caching.
Needed to ensure that users only pay the cost for variants they use
In the flow where VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME does not exist
VkAttachmentReference are created inside a loop and their backing buffer is referenced in the subpass object.
the VkAttachmentReference vectors are freed once the loop exists, causing the subpass to point to freed data.
Add all the VkAttachmentReference to a vector in the scope of the entire function, to ensure they are not freed until vkCreateRenderPass is called
