-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syncval: using vertex/index buffers a frame later than they were written to causes bogus error. #8655
Comments
@nicebyte I reproduced the behavior using the first capture with SDK 1.3.290. Thanks for providing them! Then I tested with the latest validation code and it behaves differently. You can check it or wait for the soon to be released new SDK. Good news: in the latest code syncval does not report the errors. Potentially bad news: The 1.3.290 SDK does not report errors with Standard preset (core validation), but the latest code does. The errors are related to command buffer is reset/begin when it is still in use. It is not a surprise because we recently reworked implementation of in-use resource tracking and now it covers some use cases not detected previously. Of course there is a room for bugs too. If you have opportunity to check new validation please let us know if you think new validation errors are false-positives. |
@artem-lunarg can I download the preview sdk from somewhere or do I need to build from source? |
@nicebyte You can build the latest code (https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/BUILD.md). Also the new SDK should be publicly available in the first half of this week if you prefer this option. |
So I've had time to try out the latest VVL built from HEAD today, and found some interesting things:
so i think the original bug that i opened this for is already fixed, but we've established that something is up with gfxrecon (or VVL's interpretation of gfxrecon API usage) :) |
to be more precise, what i'm seeing is: my application has NO sync errors, but if I capture it with gfxrecon and replay - the replay DOES have errors. |
I'm investigating API dump from the capture, the first impression is that commands in the capture can cause this issue. I'll spend a bit more time to be sure and then will post here a structure of the commands/synchronization to confirm it's not something that the app does and is potentially caused by the capture tool. |
full-apidump.txt Attached full API dump and also mini version with commands related to synchronization and command buffers. |
Here is a problem description based on mini API dump. This describes all usages of the command buffer
These are the commands related to The second submit in frame 0 uses fence
Based on this the error reported by the capture looks like a valid error. @nicebyte If you can spot a difference here from what your program does please let me know. Otherwise I think we can close this issue and I can notify gfx reconstruct team. |
Yeah, that definitely seems suspicious. My application never calls |
Okay, it should be side effect of the capture tool. I'll let the team know. |
@nicebyte the team is looking into it, one workaround it to use |
Thanks for the issue report! It looks like we do have invalid usage for the "virtual swapchain" mode in replay, and will work that out. In the meantime, as @artem-lunarg says, the workaround is |
Environment:
Describe the Issue
To recap, the timeline looks like this:
I think that the read-after-write hazard report is erroneous.
What makes me think this is a bug in syncval
I have double and triple checked that the application emits the required
vkCommandPipelineBarrier2
command where appropriate (breakpoints in the debugger, looked at renderdoc captures, etc.). My stage and access masks look correct as well see screenshot:When there is no wait - i.e., the app uses the buffers within the same frame that the buffers are written to, there is no syncval error.
Finally: if, instead of only skipping drawing on frame 0, I skip drawing on frames 0, 1 and 2, the syncval error goes away! Skipping just 0 and 1 still has the syncval error.
The last two points together convince me this is a bug. If there genuinely was synchronization missing, I believe syncval should report it no matter how long has passed since the buffers were written.
I am attaching two gfxreconstruct captures:
Expected behavior
Syncval should not have flagged this workload.
The text was updated successfully, but these errors were encountered: