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.
In the vast majority of cases, this will be a false positive error
thrown by Vulkan-Loader when a Linux system has Vulkan ICDs for both
32-bit and 64-bit. The error is of the form:
```
ERROR: [Loader Message] Code 0 : /usr/lib/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
```
The loader dlopen's the 32-bit ICDs first, raises this error, and then
happily goes on to try and use the 64-bit ICDs.
Upstream report: https://github.com/KhronosGroup/Vulkan-Loader/issues/262Fixes#36185.
-Added VulkanContext
-Added an X11 implementation
-Added a rendering device abstraction
-added a Vulkan rendering device abstraction
-Engine does not work, only shows Godot logo (run it from bin/)
