4 replies to this topic

[Ender1618]

Im using OGL 4.0 core profile on Win7, with about 2gb of video card memory.

So my software is receiving an arbitrary amount of points over time that need to be visualized. The thing is i do not know in advance how many points there will be. My solution is to allocate empty VBOs of a fixed size, and copy the incoming points into the current VBO with calls to glBufferData. When a VBO fills up I allocate a new VBO and start filling it, and so on.

The problem I am having is when allocating an empty VBO, with a call like this:

glGenBuffers(1, &(entry.handle));
  glBindBuffer(GL_ARRAY_BUFFER, entry.handle);
  glBufferData(GL_ARRAY_BUFFER, entry.size, NULL, usage);
GLenum err = glCheckError();
  if(err != GL_NO_ERROR)
	return false;

I am using interleaved arrays with a vertex of size 28 bytes, I tried letting my max VBO size to be 50k vertices, which is 1.4 mb each. After about the 5th VBO allocated like this, glBufferData fails with an invalid parameter message (from glGetError). The odd thing is if I allow the VBO max size to be 500k vertices, everything is fine, glBufferData never fails and everything renders fine.

Has anyone ever come across anything like this?

I would have thought glBufferData would have failed with a out of memory message if anything.

[Ender1618]

Ugh the problem was that the error was happening before all that code, it was just being picked up when i called glGetError later.

So now my question becomes how does one use glGetError effectively? Do I actually need to call it after every gl call (that seems excessive), do I set it up to only get called in a debug build after every gl call? Is there a way to monitor any error that might be happening through piping them to the debug window (this is what DX does).

[Brother Bob]

You shouldn't have to call it at all unless you're trying to find an actual error in parameters or usage. Once the code base is working, you should not have to check for errors due to user input. The amount of code you need to check for actual errors in should be fairly limited, or you have speard your code out in too many places.

I believe the common OpenGL debuggers can monitor error states. However, I have never used them. The OpenGL code I use is typically very limited (only a very few selected places are actually responsible for communicating with OpenGL) and simply manually placing glGetError's in strategic places and narrowing it down in a binary search manner is quite fast.

[wolfscaptain]

I wrap all my GL calls with a macro that, if debugging is wanted, adds a call to a function that prints a GL error.
It's not automated, but it's as close to it without going and making bindings that do it.
I would have liked having a debug version of GLEW.

On another note - do not use glBufferData to edit buffers, use glBufferSubData.
The former forces the driver to reallocate the whole buffer.

[mhagain]

You can also use GLIntercept and configure it to log errors - that may be a better option for this kind of use case.