cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

retro_alt
Journeyman III

OpenGL Driver Bug: wglShareLists and Synchronization

This issue seems to affect all AMD GPUs and all driver versions. It involves using WGL Context Sharing.

This issue is with the OpenGL driver and is reproducible as follows:

1. Create two WGL Contexts on two separate Controls on two separate threads.

2. Make them shared with a call to wglShareLists (In our case we use a hub-and-spoke design, where all controls share with a single dummy context).

3. Call wglMakeCurrent() on the threads independently, and _ONLY ONCE_.

4. Create resources, ie. VBOs, TBOs, etc. on both contexts.

5. Call glFinish, glFlush, glClientWaitSync every frame; all of these are supposed to ensure resources are up to date between contexts.

6. Change/Replace/Update shared objects on both contexts frequently.

7. Objects are drawn in only one context at a time, with nothing or corruption drawn in the other window. No error is returned.

Apparently, the driver assumes that each context will sync not by glFinish, etc, but instead by making the contexts current/uncurrent. Our workaround was to, every frame, unmakecurrent and then makecurrent before drawing. This forces the synchronization of shared objects to happen.

We have a small demonstration program! It is quite large ~100 MB. Email me if you would like a copy (gmaddox@osii.com).


Thanks,

Gregory Maddox

Open Systems International Inc.

2 Replies
retro_alt
Journeyman III

So is this how bug reports work with AMD?!

They sit on a forum and mold, unacknowledged?

When I report a driver bug to Intel, I chat with a human being, I receive followups, and they fix the problem pronto.

After investing DAYS into figuring out AMD's bugs, I expect more.

Thanks for nothing.

0 Likes

Hey, I tried doing something similar a few weeks ago, but the corruption I was seeing was my own. Unfortunately GL does not fence for constant updates. So say you have a shared Program which I'm sure you must have, while you do a glUniform on one thread and you modify program state, the other thread does the same glUniform call, which value is the final one ? Completely up to chance. In order to have something like parallel rendering working right you'd have to make sure, in your code that you're never updating constants for the same program at the same time. Another problem is trying to render from 2 contexts to the same framebuffer (even backbuffer) the behavior is usually undefined so it's recommended that you don't do that.

0 Likes