Vertex Array performance question

OpenGL Development JOGL Development
#1

I’m busy replacing more of the direct rendering in my game with Vertex Arrays (it was getting too slow on complex scenes). My approach currently isn’t the most efficient since I have a couple hundred VA’s per scene which could probably be reduced to about 20 larger ones. However that’s not my question. I ran the game through YourKit profiler, just to see where the time is now being spent (see below).

I was interested to see quite a big chunk of time being spent in JOGL methods ‘checkArrayVBODisabled’ and ‘checkBufferObject’.

Is this becuase I’m doing something wrong in the way I configure my DirectBuffers? I’m generally doing something like:

FloatBuffer vertexFB = ByteBuffer.allocateDirect(vertexBBSize).order(ByteOrder.nativeOrder()).asFloatBuffer();

From the name it sounds like one of the methods is concened with VBO’s, which I’m specifically avoiding for now to reach more users. So is there some configuration options in JOGL that I can avoid these calls, or is JOGL trying to use VBO’s behind the scene?

I’m just interested if there is anyway to lower these overheads, besides the obvious way of using fewer VA’s :slight_smile:

Cheers
Peter

PS Is this still the best forum for JOGL questions like this? It seems very quiet here these days…

Here is the output of YourKit, hopefully formatted reasonably… method,total time in method inc sub calls, time as percent, invocation count

	 
         mycode.drawMapObjects(GL, GLU, boolean) 								40,943	78 %	111	
	 com.sun.opengl.impl.GLImpl.checkArrayVBODisabled() 						18,700	35 %	172,860	
	 com.sun.opengl.impl.GLImpl.checkBufferObject(boolean, boolean, boolean, boolean, int, String) 		14,646	28 %	177,077	
	 mycode.ModelTextureRenderer.render(GL) 								12,674	24 %	16,931	
	 com.sun.opengl.impl.GLBufferStateTracker.getBoundBufferObject(int, GL) 				12,397	23 %	177,077	
	 mycode.ModelWireRenderer.render(GL) 								9,665	18 %	16,931	
	 mycode.ModelSolidRenderer.render(GL) 								9,526	18 %	16,931	
	 com.sun.opengl.impl.GLImpl.glVertexPointer(int, int, int, Buffer) 					 8,986	17 %	51,903	
	 com.sun.opengl.impl.GLImpl.glNormalPointer(int, int, Buffer) 					 8,948	17 %	51,902	
	 com.sun.opengl.impl.GLImpl.glColorPointer(int, int, int, Buffer) 					 8,935	17 %	51,902	
	 java.util.HashMap.get(Object) 									7,931	15 %	177,580
#2

You could view the sourcecode of that method, and see whether it does something funny - maybe post it here, we are lazy, you know.

Besides that, keep in mind that a profiler changes the program it analyzes, so the bottlenecks you find while profiling might not be bottlenecks during normal execution.

#3

A couple of things:

  1. Rivens warning for profiling is big. I tried using JProfiler for awhile and it radically over estimated the profiling time for simple methods (probably because they couldn’t be inlined anymore).

  2. With the method calls being called, they are to make sure that vertex arrays AND vbos work together correctly. Buffers for vertex arrays have to be direct and native ordered (so the checkBufferObject() verifies that if I’m not mistaken). Vertex arrays can’t be used if a vbo is bound, and vbo’s can’t be used if there is no vbo bound. checkArrayVBODisabled() should just make sure that it’s okay to use vertex arrays, and fail in a nice java fashion instead of letting the driver handle it.

I’m not sure how expensive either of those two methods are, however, but JOGL shouldn’t be using VBOs behind the scenes when using just the GL interface.

#4

All those checks should be in the noise level performance wise.

That is, if you don’t query the GPU/driver for your data, but keep the state stored locally.

Further, you can get seriousl slowdowns if the exceptions you potentially throw, contains messages:


fast:
if(thisIsAlwaysFalse)
   throw new IllegalStateException();

slow:
if(thisIsAlwaysFalse)
   throw new IllegalStateException("what you did is not correct");
#5

Well I tried to drill down into this a bit more, and from what I could tell from the source it looks mostly like some boolean comparisons, once some extensions have been checked, and results cached. So I’m surprised the methods were showing up like that, and I’m going to ignore it for now :slight_smile: I was mostly concerned it was something with the way I was configuring the buffers.

thanks for the response!

Peter

#6

JOGL uses VBO or vertex arrays in TextRenderer. The problem is that when you use the current implementation of TextRenderer, if you detect VBOs are available whereas TextRenderer assumes that they are not, TextRenderer will use vertex arrays and you will use VBOs and the result is that it doesn’t work, checkArrayVBODisabled() is called. Disabling vertex arrays in TextRenderer decreases HUGELY the performance. Personally I prefer using the previous implementation of TextRenderer because I have had lots of problems with the current one. Be careful especially when using ARB VBOs.