[LibGdx/LWJGL] What does this do?

Newbie & Debugging Questions
#1

I’d honestly like clarification on exactly what that method does, since reading the lwjgl documentation doesn’t make it very clear. It explains it initializes a buffer object’s data store, but what does that really mean? Why does it eat so much cpu time? Am I doing something particularly wrong? (And if there’s a better way to profile, please do share, I’m out to learn a bit at the moment)

The code in question isn’t anything complex. Here’s the paste of it:
http://pastebin.java-gaming.org/b61e43e283d16

It was just something I wrote up in a programming class to pass time and show my friends how simple it is to get some basic stuff going.

#2

The LWJGL documentation probably won’t be of much help with respect to OpenGL functions, since LWJGL just provides a binding. For details, you’ll probably want to refer to an OpenGL-specific reference, such as this.

In short, glBufferData() allocates storage for an OpenGL buffer (releasing any previous storage), and optionally initializes the buffer with user-supplied data. Since the source of the call is presumably in LibGDX code, I’m not sure how much can be gleaned from the screenshot you posted. I will say though that the number of invocations (> 2000) is a bit suspicious. Because memory allocation/deallocation can be costly, it’s typical to create buffers and reuse them rather than create them repeatedly as seems to be happening here.

Here are some things you could check:

  • Do all those invocations happen early on? Or does the number of invocations increase steadily, more or less, the longer the program runs?
  • Can you isolate the part(s) of your rendering code that are responsible for the invocations?

Keep in mind that if your application is performing adequately, it’s not necessarily a problem for there to be hot spots. However, I do think it might be worth tracking down where those invocations are coming from.

#3

There are no clear invocations of the method, which is why I don’t know exactly what’s going on. I could do a lot of digging and find out where the issue is coming from, but I figured it’d be quicker to ask around the forum. I’ll run another test and check the time scale of the invocations though.

So, looking at it, it looks like it’s being called once per frame, which makes sense, since the data is changing on a frame by frame basis.

As is, I can get ~18000 individually drawn and collision checked bullets without dropping any frames anyway.
I think if anything, the slowdown past that point comes from poor handling of new objects.

Mostly I was just curious as to what was happening there. I figured based on the information I did have that it was just buffer allocation, but I haven’t used opengl in a very long time.

As for the amount of invocations to glbufferdata, that 2000~ was nothing compared to the ~1 million calls to a few other functions, luckily they’re incredibly cheap functions. (which I initially wanted to clean up for further optimization, but after profiling, clearly they aren’t an issue)

Basically, what I learned today is that buffers are expensive (no shit), what I’m doing is fine as long as I’m not throwing 20K+ bullets around, and collision is super cheap.

#4

It shouldn’t really be being called every frame. You should be reusing buffers, not reinitializing them every frame. I know LibGDX is managing this for you but perhaps you’re using the wrong rendering method for this use case. (If you’re interested)

#5

Then I’m missing something entirely. It’s definitely handled by libgdx, and I’m not doing anything particularly strange with the graphics. (So far as I can see)

I looked into it and it’s just how the shaperenderer works. Luckily, I don’t actually use the shaperenderer for anything except drawing in the stuff that has no textures, so I can just texture everything and get rid of literally all of the gl15 calls.