This unblocks launching on Linux laptops that default to the integrated
GPU which can not handle Vulkan in many instances.
Ideally a manual device selection, or an option for the optimal selection
strategy should be provided via CLI or config, but for the time being
this will unblock the Linux devs.
Partially addresses #42348 and #43714
-Added more finegrained control in RenderingDevice API
-Optimized barriers (use less ones for thee same)
-General optimizations
-Shadows render all together unbarriered
-GI can render together with shadows.
-SDFGI can render together with depth-preoass.
-General fixes
-Added GPU detection
-Removed sync to draw, now everything syncs to draw by default.
-Fixed many validation layer errors.
-Added support for VkImageViewUsageCreateInfo to fix validation layer warnings.
-Texture, buffer, raster and compute functions now all allow spcifying which barriers will be used.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
They're now disabled by default, and can be enabled with the command line
argument `--vk-layers`.
When enabled, the errors about them being missing are now warnings, as
users were confused and thought this meant Vulkan is broken for them.
Fix crash in `~VulkanContext` when validation layers are disabled (exposed by
this PR since before they could not be disabled without source modification).
Also moved VulkanContext member initializations to header.
Fixes#37102.
I couldn't find a tool that enforces it, so I went the manual route:
```
find -name "thirdparty" -prune \
-o -name "*.cpp" -o -name "*.h" -o -name "*.m" -o -name "*.mm" \
-o -name "*.glsl" > files
perl -0777 -pi -e 's/\n}\n([^#])/\n}\n\n\1/g' $(cat files)
misc/scripts/fix_style.sh -c
```
This adds a newline after all `}` on the first column, unless they
are followed by `#` (typically `#endif`). This leads to having lots
of places with two lines between function/class definitions, but
clang-format then fixes it as we enforce max one line of separation.
This doesn't fix potential occurrences of function definitions which
are indented (e.g. for a helper class defined in a .cpp), but it's
better than nothing. Also can't be made to run easily on CI/hooks so
we'll have to be careful with new code.
Part of #33027.
Which means that reduz' beloved style which we all became used to
will now be changed automatically to remove the first empty line.
This makes us lean closer to 1TBS (the one true brace style) instead
of hybridating it with some Allman-inspired spacing.
There's still the case of braces around single-statement blocks that
needs to be addressed (but clang-format can't help with that, but
clang-tidy may if we agree about it).
Part of #33027.
-Added LocalVector (needed it)
-Added stb_rect_pack (It's pretty cool, we could probably use it for other stuff too)
-Fixes and changes all around the place
-Added library for 128 bits fixed point (required for Delaunay3D)
Part of #33027, also discussed in #29848.
Enforcing the use of brackets even on single line statements would be
preferred, but `clang-format` doesn't have this functionality yet.
Some Vulkan types are defined as "non dispatchable handles" and use a
different typedef on 32-bit and 64-bit systems (struct pointer on
64-bit, `uint64_t` otherwise).
0e78ffd1dc/include/vulkan/vulkan_core.h (L59-L65)
Contrarily to `NULL`, `nullptr` can't be converted to `uint64_t` so
build was now failing on 32-bit after converting the codebase from
using `NULL` to `nullptr`.
Fixes#37620.
Otherwise any verbose/info/warning debug message from Vulkan would
raise an error, confusing users about the severity of the message.
Cf. #36185, #36790.
