vkQueueSubmit2 reports an error with enabled synchronization validation AND queue submit synchronization validation (alpha). #6177
Comments
|
@nikitablack Could you provide a dump from the first frame (that causes the issue) for the following command?
The first two commands are still needed, even if they are provided above, because ids might change on each run. I can reproduce the first error message ( The second message can be reported when |
|
@artem-lunarg I do provide a semaphore in present. Here's the dump: |
|
Thank you! |
|
@artem-lunarg -- looks like to separate errors:
|
|
@nikitablack -- any way to get a simple gfxr file or repro case? |
|
We have a repro case here: https://github.com/artem-lunarg/Vulkan-ValidationLayers/tree/submit-after-acquire-sync-error |
|
The repro case is only for the first error, can't reproduce the second one. |
|
@jzulauf-lunarg here's the gfxr: |
|
@nikitablack that's an update on the current progress. One issue is on the VVL side, another one is on the app side. a) PRESENT_AFTER_WRITE The second error message might be a missing part of our implementation (as noted by @jzulauf-lunarg). The part of the spec you mentioned above (and duplicated below for visibility) gives clear indication that visibility operation before
b) WRITE_AFTER_READ The first error message should be fixed on the application side. Availability operation of the image barrier should be properly synchronized with the acquire signal.
Good explanation can be found in this blog post https://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/ in the section "Execution dependency chain with semaphore". Also the specification provides the same recommendation (but in our case we don't need dst scope): SUMMARY |
|
For documentation purposes, here's a separate explanation of why we need to specify
By including |
|
@artem-lunarg thank you for the explanation. I've read themaister's blog post a dozen of times through my Vulkan developer career and continue to refer to it quite often but some topics are still hard to understand. You mentioned:
What does it meant barrier commands do not execute this stage? How does the semaphore in Anyway, I added the corresponding stages to the barrier before the submit, but the error is still there. Here's the relevant API dump: As you can see, the barrier's |
Yes, that's non trivial. Thanks to working on this item I clarified some concepts related to
Mostly to emphasize that execution of barrier commands (e.g. vkCmdPipelineBarrier2) is not defined in terms of stages, they do not execute any stage. Draw commands/dispatches/copy execute some stages (even if it's a single stage). The existing version of the specification (1.3.261) contains wording that can suggest that barrier command execution is also defined as running some stage, but that's not the case. The next version of the specification will fix this (section 7.1.2. Pipeline Stages of the specification with all extensions). The above clarification to the specification is important. Synchronization scopes are often described in terms of stages (e.g. whether stages are blocked or allowed to continue execution). If the command execution is not described in terms of stages then it won't be included in the synchronization scope.
The barrier is defined earlier only in the source code. When we consider actual execution of the commands at runtime, then the logical order is: at first we have have wait operation specified by So the situation is that |
Hm... Let me clarify something before we continue further. This ticket reports two errors Here's my repro case artem-lunarg@33f99d6 that fixes If I remove |
|
Sorry, in the meantime I added another barrier and the validation error was about it. After I added the suggested stage flag in the |
|
@nikitablack I discussed the second issue (PRESENT_AFTER_WRITE) with our synchronization expert, and it turns out, it also can be fixed on the app side. I'm sorry I did not notice this sooner, since the reason is very similar to the first error with WRITE_AFTER_READ. The first error (WRITE_AFTER_READ) was that a barrier command did not synchronize with submit's The second error (PRESENT_AFTER_WRITE) is because the barrier command does not synchronize with submit's Adding COLOR_ATTACHMENT_OUTPUT to the second scope of the barrier creates the necessary execution dependency to finish the layout transition before the presentation starts. Here's an example where I fixed the same issue in the test: That's only execution dependency, memory dependencies are resolved as you quoted above - the spec guarantees that image writes are automatically become visible to the presentation engine. |
|
Closing this issue as not a VVL bug. Thanks @nikitablack for reporting this, it helped to understand this part of synchronization better. Feel free to re-open if we missed something. |
|
@artem-lunarg that fixes for me too. But it conflicts with the specification. I'll quote it here again for brevity:
The keywords here are:
|
|
That's a good point! Please let me clarify this with the specification authors. I'm afraid that part was written when only |
|
Request to clarify this part of the specification (internal link): https://gitlab.khronos.org/vulkan/vulkan/-/issues/3608 |
Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177
Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177
Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177
* Towards fixing everything. Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177 * Update cross-platform-check.yml Using Vulkan SDK 1.3.216.0 instead of 1.3.204.1. The latter is no longer available for download as it appears. * Attempted to fix sync issues in compute_image_processing.cpp with auto barriers (only able to fix them with explicit heavy barrier) * Fake news: auto barriers work * Fixed synchronization in dynamic_rendering example application * Enabling synchronization validation in multi_invokee_rendering example * Still problems in the multiple_queues example * Added custom tangent space calculation (based on new (and shitty) ASSIMP code. * Reverted bitangent calculation to ASSIMP's good old code in model.cpp * Linked to latest Auto-Vk after hot fix to development branch. * Added avk::projection parameter to camera::set_projection_matrix in order to not loose the information about the projection kind * Linked to Auto-Vk after documentation for read has been added. * Updated to The Assimp 5.4.2 Bugfix Release * Added the CMake-generated config.h file * ASSIMP .lib and .dll updates => Debug == Release actually * Trying to fix workflows/cross-platform-check.yml * assimp-vc143-mt.lib in assimp.cmake * No idea what I'm doing... * Updated auto_vk submodule * vk::detail::createResultValueType for breaking change in latest Vulkan SDK
* Towards fixing everything. Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177 * Update cross-platform-check.yml Using Vulkan SDK 1.3.216.0 instead of 1.3.204.1. The latter is no longer available for download as it appears. * Attempted to fix sync issues in compute_image_processing.cpp with auto barriers (only able to fix them with explicit heavy barrier) * Fake news: auto barriers work * Fixed synchronization in dynamic_rendering example application * Enabling synchronization validation in multi_invokee_rendering example * Still problems in the multiple_queues example * Fixed multiple_queues example * One more synchronization hint fixes a hazard from image layout transition in orca_loader example * Fixed synchronization in vertex_buffers example * Fixed synchronizationin ray tracing examples * Not going to fix synchronization in framebuffer example and present_from_compute example, sorry bruh!
* Towards fixing everything. Most importantly these issues: KhronosGroup/Vulkan-ValidationLayers#6177 * Update cross-platform-check.yml Using Vulkan SDK 1.3.216.0 instead of 1.3.204.1. The latter is no longer available for download as it appears. * Attempted to fix sync issues in compute_image_processing.cpp with auto barriers (only able to fix them with explicit heavy barrier) * Fake news: auto barriers work * Fixed synchronization in dynamic_rendering example application * Enabling synchronization validation in multi_invokee_rendering example * Still problems in the multiple_queues example * Added custom tangent space calculation (based on new (and shitty) ASSIMP code. * Reverted bitangent calculation to ASSIMP's good old code in model.cpp
1) Proper synchronization for swapchain images. See this for explanation: KhronosGroup/Vulkan-ValidationLayers#6177 2) More debug naming: for swapchain images and all image views.
Environment:
Describe the Issue
A very simple application: in the very first frame, a swapchain image is acquired with
vkAcquireNextImageKHR, no rendering is done, the image is transitioned to the presentation stage via an image barrier, submit. Here's the api dump of the relevant parts:The validation layers with enabled synchronization and queue submit synchronization produce the error:
The following
vkQueuePresentKHRcommand produces the error:Expected behavior
According to the Specification:
and
the destination source and stage masks are correct.
Since this is the first frame, the swapchain was created as usual and an image was never used, the source stage and access masks of 0 are also correct.
The expected behavior is to not have any validation errors.
The text was updated successfully, but these errors were encountered: