Hello Guest

LWJGL native calls optimization?

  • 4 Replies
  • 6605 Views
LWJGL native calls optimization?
« on: December 11, 2010, 18:01:52 »
Hi all,
I'm looking for advises regarding the following remarks.

While profiling my game, I see (again) time spent in GLContext.getCapabilities and BufferChecks.checkFunctionAddress.

For example:
21,923 ms spent to invoke 1,748,992 times the method GL11.glVertex3f

And to perform this call, I have:
7,175 ms for GLContext.getCapabilities
2,796 ms for GL11.nglVertex3f <-- the native call
2,402 ms for BufferChecks.checkFunctionAddress

So I've questions:
- would it be possible to remove the 2 calls to GLContext.getCapabilities and BufferChecks.checkFunctionAddress?

Note that I've implemented something that does it perfectly but I would like to get from the creators for possible restrictions like several monitors?

My implementation performs about 10x faster for a call to GL11.glLoadIdentity bypassing these checks:
- 0,0014362558548009367681498829039813 ms per call (new impl)
- 0,012490314582364791569812490314582 ms per call (current impl)

Hoping JVM native compilation does not interfere here ;D

Waiting for your comments :)

WS
« Last Edit: December 11, 2010, 20:33:53 by wondersonic »
S.

Re: LWJGL native calls optimization?
« Reply #1 on: December 11, 2010, 18:19:20 »
It's much more likely that your profiling causes this high execution time for these methods - as they are very short and are normally inlined (except when you add the profiling to it).

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: LWJGL native calls optimization?
« Reply #2 on: December 11, 2010, 20:01:43 »
You can use -Dorg.lwjgl.util.NoChecks=true to disable the function address check. GLContext.getCapabilities cannot be disabled as it's needed to support multiple GL contexts. Unless you build your own LWJGL and do something hacky.

Re: LWJGL native calls optimization?
« Reply #3 on: December 11, 2010, 20:31:56 »
It's much more likely that your profiling causes this high execution time for these methods - as they are very short and are normally inlined (except when you add the profiling to it).

Maybe it produces this un-inlining, do you know a way to check it?

You can use -Dorg.lwjgl.util.NoChecks=true to disable the function address check. GLContext.getCapabilities cannot be disabled as it's needed to support multiple GL contexts. Unless you build your own LWJGL and do something hacky.


I was using this trick :)

Could you detail the "multiple GL contexts" part please? (by giving usecases) and an important question, are/can the capabilities of these multiple GL contexts different?

Thanks for your comments
« Last Edit: December 11, 2010, 20:47:05 by wondersonic »
S.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: [IDEA] LWJGL native calls optimization?
« Reply #4 on: December 11, 2010, 20:51:12 »
Then you're definitely measuring the wrong thing. See if your profiler supports polling/sampling instead of tracing. Tracing usually inserts extra bytecodes in every method and that skews the results a lot, especially for tiny methods like the ones in LWJGL. With NoChecks=true, you shouldn't be seeing checkFunctionAddress at all in your profiler, hotspot would remove it completely.

GLContext.getCapabilities basically returns the context that is current in the current thread (a ThreadLocal is used). All LWJGL methods are static and that means that when you have different threads doing rendering at the same time, you need a way to distinguish them. The main problem is that the OpenGL function addresses can be different for different threads.