wglJoinSwapGroupNV

[d_a_heitbrink]

I am having a problem with wglJoinSwapGroupNV. When set my app to join a swap group (group 1), I get the application to hang. The application is hanging on the swap buffer. I do the join swap group after I have created the window, and have valid hdc. I have demo app that uses wglJoinSwapGroupNV, and it seems to run fine. Right now I am creating between 1-3 windows each with 1 OpenGL context, it does not seem to matter if I use 1 or 3 windows, same result.

I am using this on a machine with 2 Quadro K5000 and a sync board.

If any one has any ideas on what could cause the application to hang on the swap buffer, it would be appreciated.

[Skeysl]

I’m having the same issue running my opengl application with three K6000 cards + quadro sync. There are three fullscreen windows on three monitors, each with its own opengl context. Behavior is the same you have described. I’m using GLFW 3.0.4 to create windows, my system is Windows Server 2012 R2 (64bit), R380.84 driver.

Please, have you found solution for to this problem?

[rotoglup]

I revive this old thread as I came by the same issue in a naive GLFW test application.

I believe this NVidia presentation has the answer : Display for each window in a separate thread

If the swapBuffers calls are done in sequence, in the same thread, this will cause a deadlock.

When looking at the extension specification, we can see that

All of the following must be satisfied before a buffer swap for a window
can take place:

1. The window is ready.
2. If the window belongs to a group, the group is ready.

and

A window is ready when all of the following are true:

1. A buffer swap command has been issued for it.
2. Its swap interval has elapsed.

A group is ready when the following is true:

1. All windows in the group are ready.

So, if the code is, in a single thread, like the following :

glfwSwapBuffers(window1);
glfwSwapBuffers(window2);

then, the first glfwSwapBuffers will never return because the swap group is not ready, and will never be because “buffer swap command has not been issued” for window2.

[d_a_heitbrink]

The issue I ran into was related to timeBeginPeriod, basically we found the graphics driver was super sensitive to it. It would hang, and sometimes deadlock. Basically we figured out you just can’t set it all…maybe that has changed with the latest and greatest driver…

In our case we had the swapbuffers in separate processes, and actually separate machines too.

At the end of the day, we ended up not using this anyways…basically we had an application with a high level of optical flow, where having all 16 displays hang for 1 dropped frame was way worse than losing blending for 1 frame.
timeBeginPeriod