3 Replies Latest reply on Mar 26, 2013 1:29 PM by remnant

    Possible OpenGL bug : triple buffering + vsynch failure


      Hi folks,


      I've been pulling my hair out trying to solve a serious problem that I've encountered on AMD Radeon systems with my OpenGL application. After a lot of investigation I can distill the problem down to the following:


      Test Environment:


      *Windows 7 x64

      *AMD Radeon HD 6800 series(although my users report problems with various additional other lines -- I suspect all Catalyst driver products)

      *Catalyst version 13.1

      *MSVC 2010 C++ MFC Framework application

      *32 or 64bit applications

      *In the CCC, turn on:


      force vsynch

      triple buffering


      Without BOTH of these on, everything works fine. However, if both are turned on, the test application I've attached here cannot properly create a GL context; even though all the creation functions indicate success, wglMakeCurrent() returns false and the created context appears to be invalid when examined in GLDebugger. Again, with either turned off everything works just fine.


      FURTHER, it seems that MFC is at least partly to blame, or at least exposes the issue. I created two testbed projects that are simply default MSVC 2010 new C++ projects. One was MFC based and the other Win32 based. Both give the main window a CS_OWNDC style (although this doesn't matter to the problem) and then attempt to initialize opengl during OnCreate.


      In the straight Win32 testbed, there is no problem no matter what.. however the MFC testbed cannot initialize OpenGL in OnCreate when those two features above are active. OnCreate is the canonical place to initialize OpenGL so this is pretty concerning. However, I also found that if I delay created of the OpenGL resource context until the OnInitialUpdate, it will then work correctly.


      I emphasize again that the example code works fine without both of the above turned on, and also works fine on other video cards.


      I know I'm not the only one who has run into this, as I was googling for this issue and encountered multiple other devs scratching their heads on it. Anyone have any ideas, or know how to get a bug report to the driver team if it is indeed a bug? And of course, if anyone has an obvious dumb answer please shout

        • Re: Possible OpenGL bug : triple buffering + vsynch failure



          Thanks for the thorough explanation. We'll take a look at the sample and see what MFC might be doing that upsets things. Regardless of what's going on, crashing isn't what should happen.





          • Re: Possible OpenGL bug : triple buffering + vsynch failure



            We've root caused the problem. In your ::OnCreate function, the window is not fully constructed and has zero width and height. We fail to create the internal back buffer(s) with these dimensions and so fail to initialize the context. To work around the issue, add the following method to your application:


            BOOL CTestGLMFCView::PreCreateWindow(CREATESTRUCT& cs)
                  // TODO: Modify the Window class or styles here by modifying
                  //  the CREATESTRUCT cs
                  cs.style |= CS_OWNDC;
                  return CView::PreCreateWindow(cs);


            Then make cs.cx and cx.cy non-zero.


            Triple buffering only takes effect when vsync is also turned on (it would provide little benefit otherwise).


            Ideally, though, the application would directly control vsync using wglSwapIntervalEXT rather than relying on control panel options to force particular behavior.





              • Re: Possible OpenGL bug : triple buffering + vsynch failure

                Thanks for the prompt response!


                I've confirmed that giving non-zero width/height fixes the issue.


                re: wglSwapInterval, absolutely I agree- in my actual application I do so, the circumstances of my bug report here were with regards to what my customers were running under in some situations with those switches turned on, which caused the wglGetProcAddress to return NULL (because the context never became active) even though the driver reported extension capabilities -- which then led to my app crashing. I'm relieved to have a workaround!