glGetError() slow!

[RichardUK]

Ok, after some testing I had thought that the matrix upload was slow. But after some timing of functions I think I have found the culprit. glGetError!!!

It is taking from 250 to 3000 micro seconds! That is a lot when other GL functions, such as the draw and uniform uploads take around 10 microseconds. It seems to take longer if the number of calls to gl is larger before glGetError is called. That is if I call it after each matrix upload and draw pair it is around 200, if I call it after doing 100 matrix uploads and a 100 draw calls it is around 3000 mark.

Normally you would exclude it in release build but as there are no reported errors should it really be taking this long?

Can one of you guys time glGetError for me in your code and see if you get the same results.

I'm going to modify the supplied hello demos to see if I get the same results there.

[dom]

Read this:
http://www.raspberrypi.org/phpBB3/viewt ... ror#p52306

[jmacey]

I must say I alway limit my calls to glGet function as it seems to be a bottleneck in most drivers, at present I'm only calling it when I upload shaders and need to get locations of uniforms and when I debug (usually with a #ifdef GLDEBUG code block around it) I'm getting good GL performance at the moment, and have managed to port quite a large amount of my code to the pi. Even written my own Vertex Array object wrapper to make it easier to port from the desktop

[dom]

Yes, I'd recommend calling glGetError after every gl call, but with a macro that is only defined when you are debugging.

[RichardUK]

Yes, I'd recommend calling glGetError after every gl call, but with a macro that is only defined when you are debugging.

Yer, I think that is a given. But in my nieve thoughts if I wrote a driver the first line in that function would be

Code: Select all

if( noErrors )
{
    return;
}

Of cause if there was an outstanding error it would, maybe, be slow. But as it is currently slow when returning no errors, should it really be so expensive?

[jmacey]

I must say I don't call glGetError that often and rely on visual feedback first, when I do need it I use the following call from my lib

Code: Select all

 void NGLCheckGLError(const std::string  &_file,const int _line)
{
 int errNum = glGetError();

  while (errNum != GL_NO_ERROR)
  {
    std::string str;
    errNum = glGetError();
    switch(errNum)
    {
      case GL_INVALID_ENUM : str="GL_INVALID_ENUM error"; break;
      case GL_INVALID_VALUE : str="GL_INVALID_VALUE error"; break;
      case GL_INVALID_OPERATION : str="GL_INVALID_OPERATION error"; break;
      case GL_OUT_OF_MEMORY : str="GL_OUT_OF_MEMORY error"; break;
      // this should be in the spec but it's not on the mac! will check linux
      //case INVALID_FRAMEBUFFER_OPERATION : qDebug("INVALID_FRAMEBUFFER_OPERATION error"); break;
      default : break;
    }
    if(errNum !=GL_NO_ERROR)
    {
        std::cout<<"GL Error file "<<_file<<" line "<<_line<<"\n"<<str<<"\n";
    }
   }
}

Code: Select all

[dom]

Of cause if there was an outstanding error it would, maybe, be slow. But as it is currently slow when returning no errors, should it really be so expensive?

Remember that the 3D is running on a different processor. And everything is pipelined. At the point you call glGetError, the error hasn't occured. We have to flush all the pending operations queued up to the GPU to make sure the one at the back of the queue completes without an error.

Getting the error is cheap. Flushing the GPU pipeline is expensive.

[AndyEsser]

Just as a word of advice, be very careful about timing specific GL calls - it is entirely up to the driver to decide when to implement the tasks you've given it.

So you could easily have 5 calls saying only 1ms timing, but then have the 6th saying 20ms simply because that's when the driver decides to do all 6 functions work.

[RichardUK]

Just as a word of advice, be very careful about timing specific GL calls - it is entirely up to the driver to decide when to implement the tasks you've given it.

So you could easily have 5 calls saying only 1ms timing, but then have the 6th saying 20ms simply because that's when the driver decides to do all 6 functions work.

It is a good first point of testing to answer the age old "why is it so slow" question. For me it showed that glError should not be called in a release build. (kind of obvious I guess) I do tend to use the timing to give me a hint. Then try some changes based on this hint. If it makes no difference then it's time to get on the forum or send stuff to the driver guys to find out the reason.