2 Replies Latest reply on Nov 16, 2011 4:34 AM by gex2k11

    OpenGL ES 2.0 native (Catalyst 11.10) vs. Imagination Performance

    gex2k11
      Performance comparison

      Hello everyone,

       

      I recently tried to exchange the  Imagination OpenGL ES implementation on Windows against the native implementation inside the Catalyst drivers, for which i expected performance enhancements.

      Therefore i wrote a statically linkable wrapper, which loads the functions and binds them to function pointers, which are called from an own OpenGL ES implementation.

      The results worked just fine, but when comparing fps counters I noticed that the Imagination SDK is still a bit faster.

      Does anyone know a reason why it is like that ? I'm using Windows XP with a Radeon HD 4350 and Catalyst 11.10 drivers.

      Kind regards,

      Georg

        • OpenGL ES 2.0 native (Catalyst 11.10) vs. Imagination Performance
          gex2k11

          Hi again,

          just came accross that when using wgl often the all the window configs etc. are set before loading the OpenGL adresses, because in these cases different OpenGL function adresses are loaded by wglGetProcAddress.

          Is that the same with eglGetProcAddress and OpenGL ES in the Catalyst drivers?

          If not, or if eglGetProcAddress shall not be used to retrieve the OpenGL ES core functions (as specified by Khronos), how else can it be done?

          Maybe here lies the performance issue.

          cheers

          Georg

          • OpenGL ES 2.0 native (Catalyst 11.10) vs. Imagination Performance
            gex2k11

            solved,

            but obviously driver bug found:

            The problem was that vertical sync was on, and with imagination a wrong value was measured. Catalyst OpenGL ES implementation is about 200% faster in my case. Nevertheless: i used eglSwapBuffers(0) and in CCC i turned Vsync to always off, and it didn't show any effect. But when I applied the setting with ATI Tray tools suddenly the desired effect was achieved.

            And another driver bug: When switching textures on a framebuffer with glFramebufferTexture2D it just showed an effect on the first texture, afterwards i always got a black texture, except when i switched back to the first one. But suddenly when querying the framebuffer status with glCheckFramebufferstatus every frame after binding the framebuffer, it worked.

            AMD please fix this.

            Cheers

            Georg