Call overhead stats

[Nadro]

Hmmm... Yep, thats right. Handle it on application side is a better aproach.

[hendu]

Quest continues. Adding tracking for the matrix mode removed 765 redundant state calls.

https://sourceforge.net/tracker/?func=d ... tid=540678

[hendu]

Added similar tracking for the active texture, dropped 883 state calls. No patch because it would conflict with the previous patch, blame your choice of SVN for that

Hey - it's now less than half of where we started from! 9535 gl calls per frame now. 3714 us total overhead, 1797 us without drawcalls.

Look how nice the call count is now: http://pastebin.com/HG5wukwN

[ACE247]

Reading this thread almost makes me cry... We need some serious cleanup in Irrlicht!
Anyway what tool are you using to get the info?

[hendu]

Apitrace to gather the gl calls, then just basic unix tools to format it nicely (awk, sed, cut...).

I'm afraid that I'm now out of low-hanging fruit, but having dropped 51.5% of state calls in two days (20k -> 9k), I'd say I feel good about the work so far.
It saved 1.3ms of time per frame in my app, and this is on a Phenom II, so the effect should be greater on weaker cpus.

[ACE247]

Ah thanks, nice tool. Will see what sort of differences I can get and where I can fix stuff.
And to the admins, when will the patches be svn merged?

[hendu]

Probably not for 1.8, with it being close to release (*cough*) and these having chances of breaking some rare case.

[ACE247]

Wow just had a look with Demo example, upto 3080 calls/frame and a lot of repetition of calls.
Anyway I kinda gotta get used to the software a bit.

[hendu]

Now re-test with my irr branch

[hendu]

Eh, there *is* some more easy fruit: http://www.opengl.org/discussion_boards ... r-glTexEnv

There's some 250 calls to set the lod bias. According to the above, it's *per-unit* state, and so much cheaper to track than per-texture state. Perhaps I'll add that today, maybe not.

[hendu]

Added. It successfully removed all 253 calls that set the lod bias to 0 (the default).

[ACE247]

I wonder why that sort of stuff ever happened when the code was first written...
Probably a variation of RTFM, I guess.
Anyway, Will I have to apply all of the non-svn patches by curaga? Unfortunately I'll only get to testing with your patches tomorrow Afternoon.

[teto]

Nice work. Glad you did it since it was on my todo.

[hendu]

I wonder why that sort of stuff ever happened when the code was first written...
Probably a variation of RTFM, I guess.

Usually it's a "make it work" thing, efficiency comes later if at all.

Anyway, Will I have to apply all of the non-svn patches by curaga? Unfortunately I'll only get to testing with your patches tomorrow Afternoon.

All posted patches are svn? Or do you want to grab things from my git?

[christianclavet]

Wow! Guys you are really good! Ready at this I really feel like a cavemen! The only thing I understood is that it should optimize the way we use shaders and make them faster. Is there a good book on that or a site with training info?