SDL_QueryGPUFence is documented to return true when the fence is signaled (complete). Since 514b26e it returns METAL_INTERNAL_IsFenceBusy directly, so it returns true when the fence is still busy, breaking usage of SDL_AcquireGPUSwapchainTexture.
These functions already return immediately for NULL objects in normal builds, but it was done through CHECK_PARAM. When building with SDL_DISABLE_INVALID_PARAMS, these checks were compiled out, and NULL resources could reach backend release functions and cause segfault.
Always return on NULL so API behaves consistently regardless of SDL_DISABLE_INVALID_PARAMS.
Before, MetalFence was implemented as simply a busy loop on an atomic
int on metal, meaning the cpu would busy wait on the gpu to finish
taking power from it and decreasing battery life. This was the only kind
of cpu-gpu syncing (apart from requesting a swapchain)
Without this lock, a concurrent call to SDL_ReleaseGPUBuffer, SDL_ReleaseGPUTransferBuffer or SDL_ReleaseGPUTexture can cause one of the arrays to be reallocated while METAL_INTERNAL_PerformPendingDestroys is iterating over it, causing a bad day all around.
On Android, backgrounding and foregrounding an app causes the Vulkan
surface to be destroyed. vkAcquireNextImageKHR returns
VK_ERROR_SURFACE_LOST_KHR, but the acquire while(true) loop only calls
RecreateSwapchain which doesn't recreate the surface, resulting in an
infinite retry loop and a black screen.
Handle VK_ERROR_SURFACE_LOST_KHR by setting both needsSurfaceRecreate
and needsSwapchainRecreate, then returning to let the existing
recreation path handle it on the next call.
Fixes#15322
We are locked to version 1 of the ABI, so don't load what might be a symlink to a newer and incompatible version.
Platforms like OpenBSD that only have .so versions of libraries can add a special case here like Android in the future.
Fixes https://github.com/libsdl-org/SDL/issues/15172
Apparently, because PlaneSlice wasn't initialized, we couldn't use SDL_GPU_TEXTURETYPE_2D_ARRAY and SDL_GPU_TEXTUREUSAGE_COMPUTE_STORAGE_WRITE together, as the error d3d12:
"ID3D12Device::CreateUnorderedAccessView occurred: The PlaneSlice -858993460 is invalid when the resource format is R8G8B8A8_UNORM and the view format is R8G8B8A8_UNORM. Only Plane Slice 0 is valid when creating a view on a non-planar format. [ STATE_CREATION ERROR #344: CREATEUNORDEREDACCESSVIEW_INVALIDPLANESLICE]"
DSV creation was missing a TEXTURE2DARRAY branch for array, cube, and
cube-array depth textures. It fell through to TEXTURE2D, so
FirstArraySlice was never set and all layers' DSVs targeted layer 0.
This caused incorrect rendering when using depth textures with multiple
layers, such as cubemap shadow maps.
Avoids a null dereference of currentRegion->vulkanTexture->container in DefragmentMemory:
} else if (!currentRegion->isBuffer && !currentRegion->vulkanTexture->markedForDestroy) {
...
¤tRegion->vulkanTexture->container->header.info
... (among others)
by not "VULKAN_Submit"ting (and thus adding it to the defrag pool) before setting the container.
Although rare (defrag almost never ran), this crash happened in a real-world application.
