The Haiku platform port was never finalized, and moved to a separate repo in
Godot 3.2 days: https://github.com/godotengine/godot-platform-haiku
Sadly it didn't garner more interest there and is bitrotting. It was never
ported to Godot 4 so the bits of Haiku support left in Mono aren't useful.
The UWP platform port was never ported to the Godot 4.0+ API,
and it's now accumulating bitrot as it doesn't compile, and thus
we no longer propagate platform changes in it.
So we finally remove to acknowledge this state. There's still some
interest in reviving the UWP port eventually, especially as support
for Direct3D 12 will soon be merged, but when that happens it will
be easiest to redo it from scratch.
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.
This is needed to allow 2D to fully make use of 3D effects (e.g. glow), and can be used to substantially improve quality of 2D rendering at the cost of performance
Additionally, the 2D rendering pipeline is done in linear space (we skip linear_to_srgb conversion in 3D tonemapping) so the entire Viewport can be kept linear.
This is necessary for proper HDR screen support in the future.
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.
