Resending... message was too long for list.On May 25, 2008, at 8:49 PM, Michael Larson wrote: I hate to say it, but it's entirely possible you are falling off the fast path for VBO. All sorts of GL state variations can cause this, I know we have spent hours preventing this. But GL_POINTS are GL_POINTS, the big gain for VBO is the overlap of execution while the GPU is off processing vertices or filling primitives. But for points there really isn't much to do, your point size could be wrong the GPU could be failing some vertex / shader program... and like most of this thread has noted if your spending 5% of your time in GL (I think that was the # quoted) spending 2% probably won't double your performance.
glBufferDataARB(GL_ARRAY_BUFFER_ARB, vertexCount * 3 * sizeof(GLfloat), pVerArray, GL_DYNAMIC_DRAW );
glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_nVBOColors); glBufferDataARB(GL_ARRAY_BUFFER_ARB, vertexCount * 3 * sizeof(GLfloat), pColArray, GL_DYNAMIC_DRAW ); }
Also from this sequence you are updating the data again and again, which can be painful because there is a memcpy of the data to the array here (the VBO spec requires this) and if the prior operation on the VBO isn't complete this can be an expensive operation inside the framework.
We have some new extensions that allow you to map the VBO as long as you control the flushing mechanism and are responsible for the data sync... much like vertex array range did. Also if the colors don't change... then don't update them.
Mike |
