v1.4.1

This release partially fixed shadow flickering introduced in v1.4

There was 2 race conditions introduced in StagedBuffer

Staging buffer race condition:

1. After we issue a vk.CmdCopyBuffer to flush all staging data, copy command is executed asynchronously. Meanwhile, update thread will continue to write data to staging buffer so there are chances of race condition
2. In worst case, CPU will write to the same slot where vk.CmdCopyBuffer is copying and GPU will read incomplete data
3. Luckily that trash data will likely be corrected the next frame as we will run a new vk.CmdCopyBuffer on the same incomplete slot we were copying earlier
4. By the nature of the design, there are chances of race condition. We are relying on eventual correction to have good frames.

Solution: The observed visual artifact caused by this race condition is minimal. Plus, the proper work to double buffer the staging buffer is implementation-heavy and memory-heavy. We accept this shortcomming for now.

Device buffer race condition:

1. Device buffer are used across shadow and geometry pass. vk.CmdCopyBuffer flush all staging data, copy command is executed asynchronously. We did issue a memory barrier to prevent shader from reading the buffer while we were copying, but that barrier lives in a different command buffer than shadow pass and geometry pass. So the barrier we added was not helping
2. That's what we observed in v1.4. Seems like the buffer was written while shader is reading them resulting in flickered shadows
3. The race condition affected every pass but we just observed flickering on shadows. One reason for that maybe we render shadow early in the pipeline, before we start geometry pass, the copy was over so no race condition observed.

Solution: We placed a barrier on shadow rendering pass, using shadow rendering command buffer. So that transformation will always be ready before shadow rendering start