| 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. If the colors don't change... then don't update them.
Mike
On May 24, 2008, at 1:56 PM, Michael Paluszek wrote: You might look at this
and
Sincerely,
Mike On May 23, 2008, at 12:34 PM, Mike wrote: Hello,
I am learning OpenGL and building a simple particle demo with velocity, friction, forces, etc.
I started with immediate mode and drew each particle with glVertex() and it went up to 200k particles with about 50fps (2.4Ghz iMac & ati 2600 pro & no vsync).
Then I learned about VBO's and how much faster they're supposed to be. I modified my code to use VBO instead but the speed difference is only about 10% more compared to glBegin/end() with zillion individual glColor() glVertex() pairs ?!?
I am using 4 threads to calculate the math and timer to render the scene. Is there anything to speed up things or is GLSL -> FBO -> VBO only possible solution? (well, frankly that is my next goal and questions anyway).
But for now; Is it possible that there is something wrong in my VBO usage or can driver somehow optimize the glVertex() calls and thus no huge gains visible?
Thank You.
Here's how I do it:
// build VBO's once bool buildVBO(int vertexCount,float* pVerArray,float* pColArray ) { if (pVerArray && pColArray) { glGenBuffersARB( 1, &m_nVBOVertices ); glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_nVBOVertices ); glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertexCount * 3 * sizeof(GLfloat),pVerArray, GL_DYNAMIC_DRAW );
glGenBuffersARB( 1, &m_nVBOColors ); glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_nVBOColors ); glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertexCount * 3 * sizeof(GLfloat), pColArray, GL_DYNAMIC_DRAW ); if (m_nVBOVertices && m_nVBOColors) return true; }
return false; }
// update new vertex-data void refreshData(int vertexCount,float* pVerArray,float* pColArray ) { glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_nVBOVertices); 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 ); }
// draw VBO's void drawVbo(int vertexCount) { glEnableClientState( GL_VERTEX_ARRAY ); glEnableClientState( GL_COLOR_ARRAY );
glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_nVBOVertices ); glVertexPointer( 3, GL_FLOAT, 0, 0 ); glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_nVBOColors ); glColorPointer( 3, GL_FLOAT, 0, 0 );
// Render glDrawArrays( GL_POINTS, 0, vertexCount );
glDisableClientState( GL_COLOR_ARRAY ); glDisableClientState( GL_VERTEX_ARRAY ); }
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
------------------------------------------------------ Michael Paluszek Princeton Satellite Systems 33 Witherspoon Street Princeton, NJ 08542-3207 Phone (609) 279-9606 Fax (609) 279-9607
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
|
