Some operations can operate on only one of the two aspects
of a depth-stencil image. This fixes two possible issues:
- Image memory barriers must be applied to all image aspects
- VK_IMAGE_LAYOUT_UNDEFINED is no longer used as a source layout
if the operation requiring the transition only uses one aspect
We're going to flush more often in CPU-limited scenarios, but these
new values are reasonable especially in games which submit large
amounts of GPU work at once, and should help reduce rendering latency.
Improves GPU utilization and frame rates in Hellblade by up to 10%.
Preserves the per-instance and per-adapter extension sets across
multiple Vulkan instances. Works around initialization order issues
with Unity-based VR apps.
Makes it easier to identify the command stream thread and the
queue processing thread easier when using a wine build that
supports SetThreadDescription.
The DXGI format info only stores the aspect mask for views created
with that format, but we're dealing with a raw resource here so we
have to query the aspect mask from the Vulkan format in question.
Fixes validation errors with typeless resolve if the formats of
the two involved images are identical.
There are several scenarios when flushing can have
a significant negative impact on performance:
1. When the query result is already available
2. When the game scatters GetData calls when rendering
Frostpunk hits both issues at the same time, which led to
over 120 queue submissions per frame. This patch reduces
that to 3 submissions per frame when the game is GPU-bound.
There currently doesn't seem to be a game which actually renders
to images with linear tiling, but we should handle this anyway.
Only the GENERAL layout is allowed if the tiling is not OPTIMAL.
We don't need to force layout transitions and emit double pipeline
barriers in case the GENERAL layout is being used for both images.
This is somewhat common for images used by compute shaders, and
this optimization ensures that only required barriers are emitted.
Instead of inserting a barrier after every single buffer copy, update
or clear operation, we batch them up and execute the barrier when the
first dirty buffer is used by a command. This significantly reduces
the number of pipeline barriers in some games, e.g. Final Fantasy XV.
Spilling the render pass should make shader storage buffer/image writes
visible due to how external subpass dependencies are defined. For UAV
rendering, we need to do this when changing the UAVs, even if the render
targets themselves do not change.
When an applicationn calls this method with the width or height
set to 0, we are allowed to pick any resolution, so we'll try to
find one close to the *current* display mode which usually returns
the current display mode itself.
Philip Rebohle
N00byKing
ZeroFault