Spent few hours optimizing my code with Intel VTtune & found out that a lot of time is spent in nvoglnt.dll/DrvSetPixelFormat. I can only imagine that somthing is wrong with bpp conversion, but depth on my desktop is 32 as well as in app. I guess advanced forum is place where someone should know something about that.
BTW, I had a lot of advices from VTune about inlining HUGE FUNCTIONS, but as I know inlining should be used only for short functions like - inline int f{return x*=2}
Do I realy have to convert initgl() to inline and so on, they are 20+ lines long.
Is the function initgl a bottleneck? If it is as the name says, an init function, I see no point in trying to optimize it at all.
I guess it doesn’t hurt to put the inline keyword infront of some functions. If the compiler think your program will benefit from the function being inlined, the it will be inlined. If no, it won’t. Remember that the inline keyword is a hint, nothing more.
I mentioned intgl() as one of examples, there’s a lot of functions which are same size and being called frequently.
Inlined a whole bunch of functions, still no difference, something should be wrong with that pixelformat??
[This message has been edited by M/\dm/
(edited 01-22-2003).]
DrvSetPixelFormat() is only called once, right? It may take a lot of time, but there’s nothing you can do about that.
It sounds like your profile is being skewed by initialization functions that aren’t actually called at runtime. VTune has a feature that lets you delay the start of the profiling by a few seconds. That way you can start your app, initialize OpenGL, load data files if necessary, and only then start profiling. Try it out and see what happens to your results.
– Tom
There are no symbols for the OpenGL implementation, so VTune takes a guess based on exported functions. Typically, this guess will be far off. If the offset from the symbol in question is greater than about 0x1000, you know that the symbol name is irrelevant.
Instead, you should disassemble the hot spots you find, to figure out what the code is doing. Then think backwards: what am I doing that would make the implementation do that?