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
(cherry picked from commit c98b36ff03)
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]"
(cherry picked from commit 89cab56536)
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.
(cherry picked from commit 06bf8d1924)
It turns out the reason this function was having so many overread issues was because our row copies were wrong - for compressed images we also need to reduce the row count based on the block size, similar to what we already do for pitch calculation - these copies are byte copies, not pixel copies!
(cherry picked from commit f472f93db8)
Events won't be delivered to the regular event watcher list callbacks if a client event filter discards events. Use the special window event watcher list to watch for resizes in the GPU renderers, as events are delivered to this list before a client can potentially discard them.
* GPU: D3D12: Missing WinPixEventRuntime.dll now logs warning at device creation time.
* GPU: D3D12: Debug label functions are now a no-op when WinPixEventRuntime.dll is missing.
* Docs: GPU: Debug function documentation now notes WinPixEventRuntime.dll is required under D3D12.
This prevents validation errors on D3D12 caused by the previous solution
that utilized internal D3D12 functions. This is still the fallback
solution if WinPixEventRuntime.dll is not present in PATH, but a warning
is printed to let you know how to fix these errors.
This block was a sloppy way of trying to avoid prioritizing lavapipe over another device, but truthfully the only way to guarantee avoiding CPU drivers is to add a property to allow apps to require hardware acceleration.