This reverts commit 6c8042033e.
Batman: Arkham City doesn't set the CPU access flags correctly
for some images it maps for reading, and breaks on Nvidia as a
result.
Ensure that specialization constant data passed into the driver is
zero-initialized.
Having the pData field in VkSpecializationInfo be zero-initialized helps
to create more deterministic input to the driver, which is particularly
useful when debugging shader issues.
We're only ever going to need those when actually compiling a new
pipeline, so on average we're just wasting large amounts of memory
by keeping them around.
Trades several hundred MB of memory for a small increase in compile
times. Creating shader modules is typically very cheap.
If the surface is lost in a way that can't be recovered by recreating
the surface from the window, the previous change would wind up looping
forever. Just retry 5 times before giving up.
According to the Vulkan spec:
> Several WSI functions return `VK_ERROR_SURFACE_LOST_KHR` if the
> surface becomes no longer available. After such an error, the surface
> (and any child swapchain, if one exists) **should** be destroyed, as
> there is no way to restore them to a not-lost state.
So if we get this error, we need to recreate the surface in addition to
the swapchain.
Hardware doesn't support this type of fine-grained synchronization
anyway, so we really don't need the driver to iterate over anything
up to hundreds of structs - except for layout transitions.
Instead of ending the render pass and inserting two barriers, we
perform the update and barrier in a dedicated command buffer.
Improves performance in Sekiro by 5-10% depending on resolution and scene.
Many games use CreatePredicate to create occlusion queries without
actually using predication, and we don't want to pay any runtime
cost for this when predicates aren't actually being used.
Since we cannot set the viewport size to zero, we should set an
empty scissor rect so that rasterization is still effectively
disabled for the given viewport index.
Fixes#813, #957.
Some games, like Final Fantasy XIV, call `SetFullscreenState()` again
after the window is resized. When the resize itself was triggered by a
`SetFullscreenState()` call, this will cause us to re-enter the mutex.
