* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
This test renders a small triangle that casts a shadow from a point light, onto a larger triangle. The test runner then checks that various pixels in the final output are the correct colour.
There is also an arbitrary AS copy in the render loop just to hit more API coverage when manually capturing, but the test runner doesn't check its output.
Core test work originally done by martyn.jacques@arm.com
* This requires setting vmaBDA to true, which is opt-in as it applies
universally to all memory allocations in the test. We don't know if there are
driver impacts from enabling BDA and it may also mess with our tests.
* Apparently the spec allows drivers to do extremely stupid things with
swapchain images and return them even when it's not valid for you to use them
yet because last frame's work to the image is still ongoing, which leads to a
validation warning about using a semaphore when it might technically still be
in flight.
* To get around this because AcquireNextImage doesn't actually block until an
image is ready inspite of having a timeout and being expected to return a
usable image it doesn't, we use a manual fence to do what AcquireNextImage
should be doing.
* With only a single semaphore we can only have one frame in flight and get
validation layer messages if we run faster than that and re-use the
renderStartSemaphore before the previous frame has completed.
Disabled warnings 4189, 4324 for vk_test.cpp
4189: 'identifier' : local variable is initialized but not referenced
4324: 'struct_name' : structure was padded due to __declspec(align())
because of warnings in vk_mem_alloc.h
* For the most part we implement this as a thin pass-through layer. Where we
care about things (image barriers for layout transitions and queue
submissions) we do two different things:
- For image barriers, we "downcast" to plain VkImageMemoryBarrier. Currently
the only thing that's unique to VkImageMemoryBarrier2KHR is extra access
flags and pipeline stages, which we don't care about. This keeps a lot of
code from having to either handle two paths or handle the new path and then
do lots of conversions back to VkImageMemoryBarrier when running on older
drivers.
- For queue submissions we do the opposite. We promote old VkSubmitInfo to
VkSubmitInfo2KHR and process that in a common function, then if necessary
we decay back to VkSubmitInfo before sending to the driver.
baldurk