Adds a new system to automatically reorder commands, perform layout transitions and insert synchronization barriers based on the commands issued to RenderingDevice.
Credit and thanks to @bruzvg for multiple build fixes, update of 3rd-party items and MinGW support.
Co-authored-by: bruvzg <7645683+bruvzg@users.noreply.github.com>
Introduces support for FSR2 as a new upscaler option available from the project settings. Also introduces an specific render list for surfaces that require motion and the ability to derive motion vectors from depth buffer and camera motion.
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
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.
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
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
- Removed empty paragraphs in XML.
- Consistently use bold style for "Example:", on a new line.
- Fix usage of `[code]` when hyperlinks could be used (`[member]`, `[constant]`).
- Fix invalid usage of backticks for inline code in BBCode.
- Fix some American/British English spelling inconsistencies.
- Other minor fixes spotted along the way, including typo fixes with codespell.
- Don't specify `@GlobalScope` for `enum` and `constant`.
For some reason AFAICT mesa reports a feature as enabled even when its
extension isn't supported. The Vulkan specification says nothing aboutd
this so this is technically more of a workaround, but it works.
End users would get spammed with messages of varying verbosity due to the
mess that thirdparty layers/extensions and drivers seem to leave in their
wake, making the Windows registry a bottomless pit of broken layer JSON.
I'm all for helping end users clean up mess in their registry / system paths
for Vulkan ICDs, layers and extensions, but the way this is done by
VK_EXT_debug_utils is just horrible - and the way for them to fix it (manual
edit of system files) is also not a good thing to recommend.
Closes countless issues where users think Godot is broken because it reports
weird errors.
