-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Simplify synchronization in VulkanRenderManager #16090
Conversation
OK, had to reintroduce one frame-specific cond-var. Still, this actually provides a very small but measurable speedup (600 fps to 610 fps on a GoW title screen). Will test some more before merge. |
I think this is pretty much ready to go now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good but it's still breaking in the disassembly as it was before (note: not the GE debugger.)
Reproduction:
- Start a game.
- Open Disassembly.
- Hit Break.
- Hit Go.
Always crashes. Anyway, this doesn't make that any worse than before and seems better. I tried a couple runs and haven't gotten the readyForFences error or any other failures/deadlocks.
-[Unknown]
Found and added a fix/workaround for the crash here: #16092. -[Unknown] |
This simplifies thread synchronization in the Vulkan rendering backend, making it easier to reason about and debug, and very slightly faster. Tested the GE debugger, seems fine.
Now uses a queue where we tell the render thread what to do, instead of maintaining a separate frame counter.
Also there's an issue when stuffing the queue, it's not allowed to wait on a fence if the submission that is going to trigger it is currently happening on another thread, I missed that. And using a regular mutex easily deadlocks (working on it).