Optimizing LuaGL

[aeonios]

I've been working on optimizing Global Build Command, which is steadily getting polished enough to where I feel like I can release it into the wild. I managed to get the main logic loop to run an order of magnitude or two faster wrt huge numbers of jobs, and now the GL code is showing up as consistently most expensive. My benchmark for this has been to do an area reclaim over the whole of Quicksilver, which draws command icons (and also has to do worker-cost calculations) for every tree on the map, of which there are 9001 or so. I would have expected the logic (ie GameFrame) to have been most expensive, but it shows that DrawWorld() is, even after I moved visibility checks into Update(). I'm seeing ~30% CPU usage from my widget under the aformentioned benchmark conditions, zoomed all the way out, and not much better when zoomed in all the way.

I'm not really sure how the whole gl.PushMatrix/gl.PopMatrix thing works, except in my tinkering I found that many things will not draw properly unless those are called for every item being drawn. I tried unswitching the drawing loops, switching to indexed array-tables instead of hash tables, and lifting some invariant code (mainly calls to gl.Color) but that doesn't seem to have improved anything by much. I'm not sure that it's actually possible to make this code any faster, but if it were I wouldn't really know what to even look for.

Here's the isolated drawing code: http://pastebin.com/SZkt3Stc

Knowledge is muchly appreciated.

[Silentwings]

It's dependent on what your gfx card actually does, which can vary between cards, but the first thing I usually try is to put what I can into a glList. Typically this helps in a situation where you want to redraw the same object in several places at several times - http://nehe.gamedev.net/tutorial/display_lists/15003/. Btw, you can nest glLists inside each other, if you want too (call one already built list inside another, but note that to subsequently change the "inner" list you have to recreate the whole list). Doing this can also be a neat way to modularize the horrible tangles that gl code can turn into otherwise.

Also worth checking how much load your widget takes under normal use conditions in a normal situation. When nothing else is running it might take up a big % of the perf, but it might be different in the midst of a game with a tonne of other stuff going on and many less drawframes per second. That said, widgets are in some sense the least important part of what goes on, and if perf is an issue then imo widgets are first in line to be cut back.

[zwzsg]

Yeah, use a display list, and suddendly it'll be super fast.
https://springrts.com/wiki/Lua_OpenGL_Api#Display_Lists

To sum it up, you do something:

Code: Select all

local function FuncWithAllYourGlCode()
...
end

local list=gl.CreateList(FuncWithAllYourGlCode) -- Just once, or at least as rarely as possible

gl.CallList(list) -- every frame

gl.DeleteList(list)-- to free it up when you quit the widget or need to redo it.

[aeonios]

Ah, most of the drawing was just billboards with a simple 2D icon spammed 9001 times. I suspected that gl.CreateList and gl.CallList was what I was looking for, but now I actually understand how they work. Also, I missed the part about gl.DeleteList the first time around but that explains why I was seeing weird space-leak-like behavior. We'll see how it goes when I actually do it properly. XD

[jK]

I'm not really sure how the whole gl.PushMatrix/gl.PopMatrix thing works

google it

tip #1: gl.texture is a very expensive call (doesn't matter if in dlist or not!). 99% of your calls of it can be removed by moving it in front of the loops
tip #2: common coding rule: "never have more than 3-4 indentation levels and ALWAYS use as less as possible levels" (a very very very important rule)

Code: Select all

function widget:DrawWorld()
    if not spIsGUIHidden() then
    ...
    end
end

becomes

Code: Select all

function widget:DrawWorld()
    if spIsGUIHidden() then
       return
    end
    ...
end

[aeonios]

tip #1: gl.texture is a very expensive call (doesn't matter if in dlist or not!). 99% of your calls of it can be removed by moving it in front of the loops

Ah, that was what I was originally trying to do, but I mistakenly thought that the call to gl.Texture had to be inside push/pop matrix. Fixed that.

tip #2: common coding rule: "never have more than 3-4 indentation levels and ALWAYS use as less as possible levels" (a very very very important rule)

Derp, fixed that, at least for the gl code. Now it looks like this: http://pastebin.com/Q7u0d7Gq

What's strange is that Update() is still apparently taking up 30-40% CPU when all of the reclaim symbols are visible on quicksilver, but it's reduced with restricted visibility. With almost none of the symbols visible it only takes ~10%.

(view full-size in new tab for detail)

[jK]

recreating dlist every frame doesn't give any speedup. On ATIs it's even a massive lag reason.

[aeonios]

The only thing it does is go over the list of jobs and sort out visibility. The actual list it goes through is only compiled twice per second.

EDIT: also, Update() only actually does anything every other frame.

[aeonios]

Eh, I guess it's good enough. Under normal circumstances performance isn't a problem, and even under extreme circumstances it's not bad enough to warrant more work changing it.