Skip to content

Fix Clyde deadlock on nvidia/wayland - #6966

Open
DamianX wants to merge 1 commit into
space-wizards:masterfrom
DamianX:fix-secondary-window-blit-fence-flush
Open

Fix Clyde deadlock on nvidia/wayland#6966
DamianX wants to merge 1 commit into
space-wizards:masterfrom
DamianX:fix-secondary-window-blit-fence-flush

Conversation

@DamianX

@DamianX DamianX commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

I am not well-versed in OpenGL but I think this is correct.
According to the docs here:

If a sync object is associated with a fence command issued previously, but not yet flushed, ClientWaitSync may hang forever.

We use WaitSync instead of ClientWaitSync, so I'm not sure how relevant that is, however the docs also say:

Applications which block on a fence sync object must take additional steps to assure that the context from which the corresponding fence command was issued has flushed that command.

In our case, we do FenceSync here:

rt.LastGLSync = GL.FenceSync(SyncCondition.SyncGpuCommandsComplete, WaitSyncFlags.None);

and then we WaitSync on it here:

GL.WaitSync(sync, WaitSyncFlags.None, unchecked((long) 0xFFFFFFFFFFFFFFFFUL));

And we don't Flush() at any point.

Additionally, Issue 20 in the docs also indicates a Flush() after FenceSync() is needed in this situation, which is what my change adds. It does still mention ClientWaitSync instead of WaitSync, and I'm not sure if that matters.

This change does fix the issue on my end so it closes #6958

@DamianX
DamianX requested a review from DrSmugleaf as a code owner August 11, 2026 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clyde deadlocks on nvidia/wayland when multiple OSWindows are blitted

1 participant