Crash with vkCmdPipelineBarrier2 with a lot of VkDependencyInfo

[Joshie]

The AMDVLK implementation of this function is implemented by mapping to sync1 similar to the Khronos sync2 layer https://github.com/KhronosGroup/Vulkan-ExtensionLayer

This is done by using a fixed virtual stack allocator for the number of barriers.
https://github.com/GPUOpen-Drivers/xgl/blob/b358df5460810b00d0cc779e4d000e4a901d2047/icd/api/vk_cmdbuffer.cpp#L6628

This fixed virtual stack allocator has a fixed size of 256kb:
constexpr size_t MaxVirtualStackSize = 256 * 1024; // 256 kilobyte

On game loading screens with DXVK, there can be several thousands of image transitions which will cause the limit of this virtual stack allocator to be exceeded and crash -- as there is no fallback, it just returns NULL on overflow.

To fix this, I recommend getting rid of the kind of useless virtual stack allocator (as this is a tail call for the client app), and just have a fixed size array of around 8 or 16 VkMemoryBarrier2s etc on the actual stack, and fall back to malloc/free if the number of barriers exceeds that.

Another option, would be to extend the existing virtual stack allocator to have that fallback, but that seems quite annoying with how all that code is structured.

It would also be nice for sync2 to be first-class and barriers to get upgraded rather than downgraded.

Ref: doitsujin/dxvk#3138