Validate synchronization correctness

[zeux]

This was probably discussed before, but I want to make sure there's at least a GH issue for this.
Layers currently don't validate correctness of synchronization. I can freely go launch two back-to-back transfers where the second transfer reads data from the first one without any barriers, and this will "work" - validation layers won't complain.

This is a very very very big issue. Vulkan barriers are hard to reason about - if anything, this is THE area that needs validation. We've had sync bugs in code we wrote. We've seen sync bugs in SDK samples from IHVs. We've had sync bugs in the driver but with no validation layers it took a long time to convince ourselves that the driver is at fault.

I'm sure this is non-trivial to track. There are subtle issues with bindless of course, and it will probably take time to add the necessary infra to the layers - but it has to be done. Right now we're running blind, and games that ship on Vulkan are in permanent forward compatibility hazard since newer drivers or hardware may start using existing barriers in ways that weren't tested before, and if the app has broken sync code, we'll end up in a bad spot.

There's a separate issue where some bindless patterns can only be reliably validated on GPU (DX12 has a GPU validation layer for this) - I'm not asking for this here, this should probably be tracked separately.

So the request here would be to reconsider priority on sync tracking - IMO it is the absolute highest one, I can't imagine any other validation work that is more valuable for the community - and somehow get it in :) FWIW if this is necessary we'd be fine with having this as a separate layer that you have to enable explicitly while it takes time to stabilize.

[tobine]

This is understood to be the top validation hole with multiple longstanding issues. Note that I have old branch tobin_secondary_cb_synch_tracking that is PR #2066 that is a partial solution to synch validation. Work was ceased on that branch b/c the perf hit for overall validation was too great. I went ahead and just re-based that branch off of latest master in case anyone wants to do anything with it.
The strategy employed there is to monitor read/write memory accesses along with barriers and flag a warning anytime there a RaW or WaR access to same memory without appropriate barrier. We can only issue flags b/c some of the memory access tracking, I think primarily around what Draws access, is imprecise so we have to conservatively mark entire regions as R or W when, in reality, smaller sections are probably all that's touched.
There were some memory access cases that weren't yet captured on the branch, which means some warnings may be missed. I believe all barrier and event cases are accounted for, but there were some bugs in access mask handling, and may be holes in semaphore cases.
So, there's still significant work that would have to be done on the branch to make it complete and if it were to be included in primary validation code it needs to be disabled by default for performance reasons. There's probably a more high-performance solution that could be implemented, but I wanted to re-highlight my old branch so people are aware of it and an ambitious developer could pick it up or use it as inspiration for an alternate solution.