Artem Kharytoniuk

@glebov-andrey not directly related to this issue but FYI, since I remember you had pretty advanced synchronization scheme. The latest VVL code (after https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8519 and https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8546) has major update of...

Thanks, for syncval timelines we now have a draft PR which will be updated with new fixes: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8559

> The errors related to queue family transfers seem to be gone - were they silenced in some way? No, they were not silenced specifically. Maybe it was influenced by...

The test I wrote for this issue also works now. It turns out another fix (https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/7552) makes it work (ALL_COMMANDS semaphore should protect layout transition even if transition's src stage...

Yes, it catches large frame sizes in the old code. 96KB limit in the new code passes analysis. It's more involved than just a compiler option. `/analyze:stacksize` has default value...

I think this can be part of a more general feature that allows to configure sync error messages, for example, to specify formatting options, but also which components you need....

@DethRaid `seq_no` \ `reset_no` won't be reported by default in the next SDK. Can be enabled manually if needed.

@danginsburg The latest code has validation of vkCmdBuildAccelerationStructuresKHR. Currently there is one limitation for vertex buffers, validation of vertex data is skipped if positional data provided to vkCmdBuildAccelerationStructuresKHR is interleaved...

That was also my thinking that optimized applications will tend to use sequential data. In theory we can remove the restriction for vertex data with a small chance of false...

> That's a pretty wild scenario that anyone would do that! I'm 100% agree with this, will consider relaxing restriction after SDK release. We really trying to stay away from...