- CreateEventEx() is guarded by _WIN32_WINNT >= 0x0600:
In SDL_gpu_d3d12.c, include core/windows/SDL_windows.h
that defines _WIN32_WINNT properly to account for that
- DXGIInfoQueue stuff is not available in all toolchains
such as mingw-w64 version 8.0.3
- SDL_gpu_d3d11.c: _WIN32 is always defined by MinGW, as
is the case for all windows-targeting compilers, so it
doesn't guarantee absence of DXGIInfoQueue stuff:
rely on __IDXGIInfoQueue_INTERFACE_DEFINED__, as it is
done elsewhere.
Fixes: https://github.com/libsdl-org/SDL/issues/10705 .
The default value of MAX_FRAMES_IN_FLIGHT (3) may be less than the
minImageCount returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR() on
some setups. For example, the Intel IVB Vulkan driver on Wayland returns
a minImageCount of 4, resulting in the following validation warning:
VUID-VkSwapchainCreateInfoKHR-presentMode-02839(ERROR / SPEC): msgNum: -76493605 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-presentMode-02839 ] | MessageID = 0xfb70ccdb | vkCreateSwapchainKHR(): pCreateInfo->minImageCount 3, which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR() (i.e. minImageCount = 4, maxImageCount = 0). The Vulkan spec states: If presentMode is not VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR nor VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR, then minImageCount must be greater than or equal to the value returned in the minImageCount member of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-presentMode-02839)
Objects: 0
Use the minimum image count in that case, as it's as close as we'll get
to our preferred value. Note also that, unlike maxImageCount,
minImageCount is never 0 (the spec states it is always at least 1), so
we don't need a similar check to see if it applies.
Signed-off-by: David Gow <david@ingeniumdigital.com>
The `colorAttachmentDescriptions` field of `SDL_GPUGraphicsPipelineAttachmentInfo` should be marked `const`,
similarly to the `vertexBindings` and `vertexAttributes` fields of `SDL_GPUVertexInputState`.
Using the @() syntax to construct an NSString assumes the parenthesized
pointer is null-terminated, but the Metal shader source included in
render/sdlgpu/shaders/metal.h is not null-terminated.
Quoting the clang documentation on Objective-C literals:
When the type of the parenthesized expression is (char *) or (const
char *), the result of the boxed expression is a pointer to an
NSString object containing equivalent character data, which is
assumed to be ‘\0’-terminated and UTF-8 encoded.
Because the @() syntax assumes null-termination, it may read garbage
data after the shader source (up to the next null byte), which can then
cause the Metal shader compiler to fail. To prevent this, instead of
using the @() boxing syntax, we explicitly construct an NSString using
the string length passed by the caller.
These functions had special cases for a few BC formats, but all
block-compressed formats should need the same logic. Furthermore they
weren't handling the sRGB variants of those formats.
