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.
Otherwise we pass an invalid offset and length to the backend,
which leads to invalid descriptor set updates in Vulkan.
The D3D11 runtime does not report corrected constant offset
and count parameters to the applicaion in *GetConstantBuffers1.
Reported-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
If the predicate buffer is device-local memory, conditional
rendering commands don't seem to see any updates values even
though there is a barrier. When allocating on host-visible
device memory or system memory, it works as expected.
