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.
When the OpenXR loader library fails to load, provide a detailed error
message explaining:
- On Windows: need openxr_loader.dll in app directory or PATH
- On Linux: install libopenxr-loader package or set LD_LIBRARY_PATH
- Can use SDL_HINT_OPENXR_LIBRARY hint to specify path
Also update D3D12 backend to include the error in its warning log,
and remove redundant SDL_SetError in Vulkan backend that was
overwriting the detailed message.
